As requirements for faster release cycles and applications packed with more features than ever keep organizations rushing to production, we can’t afford to skip a beat when it comes to security. Developers with all stages of security knowhow are being hired, and right beside giving developers a thorough education in secure coding is ensuring the code they write is secure well before it gets deployed.
This is where a strong security testing approach becomes an organization’s saving grace.
Security testing, Wikipedia says, is “a process intended to reveal flaws in the security mechanisms of an information system that protect data and maintain functionality as intended.” In other words, security testing is making sure all the security requirements you mapped out at the beginning stages of your application security program are being implemented – and implemented correctly.
Security testing is one of the most important aspects of any Secure SDLC approach.
Why? For one, security testing in the SDLC identifies security issues that need to be addressed. The sooner you can find them, the more money you save: fixing security issues, like any bugs, gets more expensive the later in the lifecycle you find them. Waiting until later stages of the SDLC to begin security testing leads to hasty fixes in order to stay on schedule will not bode well when customers complain – or worse.
And that’s not even considering the kinds of costs we’ve seen organizations pay when they don’t discover a vulnerability at all. Breaches are costly, and the ROI gained from proper implementation of security testing in the SDLC is proven by avoiding just one security breach.
Secondly, the various types of tests you’ll perform throughout the lifecycle will also let you know how closely the security architecture and design is being followed. In essence, security testing is a barometer of security quality within your SDLC, as well as the best way to develop and maintain applications efficiently and in line with organizational needs and risks.
Lastly, but perhaps most importantly, security testing gives an organization a strategic approach to improving security in their application portfolio, and is a business imperative for any business trying to minimize the potential risks – including compliance requirements – that application security vulnerabilities can pose.
Security testing can be done through much of the SDLC, as early as during the analysis and design phases, as well as throughout development and, of course, during the testing phase. And just because an application is released, doesn’t mean you can stop thinking about the application – but we’re focusing on testing done during the lifecycle for now.
The security testing strategy, as we discuss below, needs to be based on your individual organizational structure and what the established SDLC process allows for. Typically, however, security testing can be broken up into three areas during the SDLC:
During this phase, as security requirements are mapped out, testing plans can be created to better track the completion and success of the stated requirements.
As soon as code is being written, static application security testing can begin. Starting testing as soon as your SDLC allows facilitates the best way to stop vulnerabilities from making their way to the finished product. With partial code scanning, source code can be scanned at any point in time during the build, making vulnerability discovery that much faster and more effective.
Finally, once development is finished, a final secure code review along with manual testing can help detect logical code flaws and ensure that issues found during the development phase have been fixed correctly and new vulnerabilities have not been introduced.
Defense in depth is a key aspect to a successful application security program – and the same goes for security testing in the SDLC.
1. Make it measurable
As the OWASP Testing Guide so rightly says in the introduction, “you can’t control what you can’t measure.” Security testing is no different – especially when first implementing it within the SDLC. Being able to look through your testing history and comparing it over time is essential in seeing (and reporting up) on improvement. In order to do so, begin by establishing goals and metrics from the get-go, working with stakeholders – from the board to developers – to set expectations and gather feedback on the processes themselves.
2. Ensure testing tools are easy to adopt
Making sure the tools you choose are chosen in terms of learning curve and adoption rate by developers are important factors in whether or not your security testing program will be successful or not. Many developers haven’t dealt with needing to test for security before, so if a tool is difficult to use or well-integrated into the developer’s current toolset, chances are it’s not going to get used.
Don’t spend a fortune on the “best tool in the business” if it’s not likely to be used by those that would be in the business of using it.
3. Automate wherever possible
If you’re doing a good job of training your developers, you want to make sure they’re spending the most time doing what they were hired and trained to do – code securely.
Instead of burdening them with long hours of code review or manual security testing at each milestone, you can automate at least parts of that process with source code analysis tools, implemented into their IDE. At check-in, developers can simply scan their code and get quick results back instantly, allowing them to fix the code while it’s still fresh in their minds.
4. Align security testing activities to your current SDLC process
The phases you’ll be able to integrate security testing into and how quickly security testing can be introduced largely depends on the existing SDLC process in place in your organization. In agile environments, for instance, security testing can and should be integrated as early as possible, while in waterfall environments, security testing may not be possible until development is well-underway.
While security testing should always be integrated as early as possible, it’s more important to make sure security is a business enabler by working with the current processes – not against them.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.