Successfully Integrating Security into the Software Development Life Cycle

It is vital that security measures, including web application security scanning, play an early role in the software development life cycle. This article summarizes a podcast discussion in which Netsparker CEO Ferruh Mavituna talks about the place of security testing in the SDLC and how companies can achieve this integration with maximum success.

Successfully Integrating Security into the Software Development Life Cycle

Netsparker founder and CEO Ferruh Mavituna was interviewed by Edward Haletky on a podcast called Virtualization & Cloud Security Podcast Ep 17: Security Testing as Part of DevOps. They discussed how security testing fits into the Agile software development life cycle, DevOps, and Agile Cloud Development.

At the time, we published a brief summary blog post called Web Application Security and the SDLC Discussed on the Virtualization and Cloud Security Podcast. But, the content is of such relevance and interest that we’ve compiled another blog post to give you a chance to enjoy their exchange of ideas on the task of integrating security into the SDLC and how to do it successfully.

Successfully Integrating Security into the Software Development Life Cycle

Security as an Afterthought

Both Ferruh and Edward noted that the traditional view of security within the software development life cycle treats it as an afterthought to the process (an “endpoint security centric culture”). At a significant deadline in development, or even just before they go live, a company will hire consultants and penetration testers to check for security issues. Since this is a late stage activity, detected vulnerabilities may have existed all the way along. Consequently, they may need to be fixed many times over. The entire structure of the web application may have to change depending on severity.

Instead, Netsparker needs to be used from the earliest stages of the software development life cycle, straight after the build, as part of a continuous integration practice. Vulnerabilities uncovered at this stage are not yet dangerous. They can be fixed almost as soon as they’re introduced. Even then, a single test is insufficient. Secure application development needs continuous testing. Only this will stop a serious vulnerability from going live. There should never be building without testing because you simply don’t know what vulnerabilities are there already.

Fostering a Security Mindset

Developers focus on deadlines and code. Having a security focus is very different. But it is not feasible to expect the average developer to keep up with every web application security risk. They don't necessarily possess a security interest or mindset. Employers must find developers with a security interest and empower them. They should not be pushed into the security team, but used instead as a bridge between that and development.

Ferruh put it like this:

The security mind is something you need to train. If you don’t train your developers in basic security concepts, you will never run out of security issues. You’ll keep getting them. You will never solve the problem.

Edward used the term "security developers" to describe developers with a security mindset. They’re not part of and don't want to be part of a security team, as most security teams are all about compliance and checkboxes. Since vulnerabilities are introduced at the code level, not the infrastructure level, no web application firewall alone is sufficient to protect against attacks. Developers with the right training and mindset are quite simply the best weapon against such issues. Companies should be getting developers on board to transition from part of the problem to part of the process.

The Security Testing Triangle

Edward asked Ferruh about what he called the "three sides" of what a scanning tool such as Netsparker can do for you. These are three reasons why you need a security testing tool.


Can a tool like Netsparker replace a penetration test? A former pen tester, Ferruh pointed out that testing consultants and companies use Netsparker because:

Netsparker automates what can be automated so you can spend your time doing what can’t be automated.

So if pen testers are not using automation, they are wasting customers’ time, their own time, and are not doing their job productively. Companies can run security scans and provide pen testers with the results. But, there are issues that can only be found by an informed, human mind. If testers know what hasn't been tested (thanks to a report) and what can’t be automated, then they can spend their time on the important issues.

Automation is vital for developers too. When they have automation that they trust, developers are freer to develop code. Ferruh said:

You can write code, and all you think about is the code you are writing, not the pieces that you might be breaking right now. Because if you break something, you can immediately, or at least very quickly, get that feedback. But if you don't have the trust, then writing code becomes much more complicated because you've now got so many pieces in your head, you can’t solve what you’re trying to solve.


The need for developers to learn about security is part of developing the much needed security mindset. Developers need training in basic security concepts. Then, as they use Netsparker to detect issues, they start to learn how to avoid introducing more, and how to fix them when they do occur. Ferruh made this argument:

If [developers] learn the mistake, and fix it, they won’t repeat it. You learn as you develop and you get that feedback immediately – not after deployment.


Thanks to Netsparker, companies can now provide auditors with a list of all the tests they have performed (for example, OWASP Top 10 and PCI). This makes web application scanning tools highly valuable to auditing teams for compliance purposes. Companies can hand off results to the auditors, as with penetration testers, to show what they already check. Testing teams can then start somewhere new, with issues that offer companies the maximum return value. In fact, testers can inform you which scan settings to change, and how to run parallel tests to produce more relevant data for them, developers and auditors.

Optimization is the Answer

In the podcast, Edward asked Ferruh what Netsparker recommends for those companies who need their scanning completed quickly. Scanning speed is in part determined by the size of the web application. Also, companies can schedule nightly scans, when servers are less busy. But does Netsparker have the ability to focus on issues that are most likely for a particular category of product?

Ferruh replied that optimization is the answer to time demands. Netsparker allows users to remove from scan settings those security checks that aren't relevant or that you need to avoid. What is the application? What are the most common vulnerabilities in your country right now, in your sector at this time, and in the history of the application? What are the most common, or serious, vulnerabilities? Once you have answers to these questions, you can then optimize your scans for maximum efficiency. Finally, Netsparker can run several parallel types of test, with different configurations and parameters.

Further Reading

Application Security is Vital Throughout SDLC

Building a Strong & Secure SDLC

Integrating Netsparker Enterprise into Your Existing SDLC