Introducing Security Flaws at Agile Speed
An article from DZone's upcoming Guide to Application Security, looking at how to deal with security defects in the SDLC.
Join the DZone community and get the full member experience.Join For Free
As organizations adopt agile software development patterns, many continue with the same waterfall-oriented testing strategy they’ve used for years. This not only misses opportunities to improve software quality; it risks losing any speed and efficiency to market by also increasing the speed at which you introduce security vulnerabilities.
These security defects are technical debt, the consequences of insufficient architecture and/or insecure coding practices. Defects are a fact of life, but if you don’t look for them, you won’t find them. If you look for them too late in the process, the mountain of technical debt unknowingly created along the way may be too tall to climb for the business.
That debt will have to be paid at some point. Unlike defects that impact functionality and are likely to be found relatively quickly by customers, security vulnerabilities may lie dormant, waiting to be exploited by a hacker and impact your organization much later.
Security defects are introduced at all phases of the software delivery lifecycle and are less expensive to correct the more quickly they are found.
Application security professionals have long struggled to engage developers and management in good security practices. Security takes time and money, which forces it to the bottom of the priority list in many organizations. Managers assume good developers also observe good security practices. However, even good developers focus where they are most rewarded: delivery speed. Even so-called agile software development projects continue to take a waterfall approach to assessing security. Putting off security until late in the lifecycle is a recipe for missing delivery dates (if these vulnerabilities are found at all), and it encourages these defects to be ignored. The good news is, even if your organization doesn’t have a dedicated team of InfoSec specialists overseeing application security, automation efforts you are already making to speed your software to market can be leveraged to improve the security posture of that software as it’s developed.
Hire Robots to Secure Your DevOps
The same processes and toolchain that enable high delivery speed can inject a security focus into application development by assessing the security posture early and often.
Many organizations are somewhere in the process of adopting Continuous Delivery methodology. Some think they’ve achieved Continuous Delivery, when in reality they’re stuck at Continuous Integration. If you’re automating up to the point of builds and integration testing but reluctant to take that next step and deploy into production, adding security assessment to those automations can help push into the next evolutionary phase of true Continuous Delivery while reducing risks that may otherwise be involved.
Hiring robots, introducing automation into the software development lifecycle to help secure your applications early and often is that next evolutionary step. Disruption to the development process can be minimized by incrementally embedding security into the DevOps toolchain.
Get Your Development House in Order
Before you can automate security assessments into your DevOps chain, you must have an existing toolchain where security tools can be integrated. If your organization isn’t using source control, stop reading and go install a source code management (SCM) system right now. There are many open-source options like Git and Subversion (with DZone Refcardz to get you started).
A continuous integration tool that supports your SCM system is the next step. Open-source options—such as Jenkins, TravisCI, or BuildBot—or a number of proprietary options can ensure that code is evaluated on every commit, not just during nightly builds. Defects, be they build breaks or security vulnerabilities, need to be returned to developers at the same speed they are being introduced.
Assess Early, Assess Often
Assessing the security posture of source code through automation as the code is checked in enables developers to be notified of vulnerabilities that have been introduced before they have mentally moved on to their next task. It also reduces the workload to one or two (hopefully) rather than several hundred or more vulnerabilities facing developers at the end of the coding cycle when they just want to deploy their creation into the market.
Automated scanning for application security issues may be incorporated into your continuous integration tool—usually after a successful build in the build pipeline—to evaluate each check-in. There are two types of automated application scanners; each has its strengths and weaknesses in uncovering vulnerabilities. Both should be used to ensure the most complete coverage possible.
Static code analysis works in a non-runtime environment and looks for patterns in source code and compiled binaries that indicate security flaws. These tools are cost effective, don’t have many moving parts, and scale well. They can be incorporated into the DevOps toolchain without a major infrastructure investment, reusing the same build infrastructure. Static analysis can be run early and often, returning results within just a few orders of magnitude of the application’s build time.
Static analysis is best at identifying security-relevant portions of code and ensuring secure coding practices are adhered to. They are particularly good at finding common vulnerabilities such as buffer overflow—which can turn control of an application over to an attacker—and SQL injection, which can open your database to complete destruction.
Static analysis tools are limited by the context in which they work. While these are white-box tests, only the source code, bytecode, and/or application binaries are available to the scanner. The tool cannot ensure the integrity of data as it passes through the application. For this reason, static analysis tools can’t find each and every vulnerability. They are known to produce more false positives than their dynamic counterparts.
The Open Web Application Security Project (OWASP) hosts a number of open-source static scanners (primarily for Java).
Dynamic analysis tools work in a runtime environment. They automate much of what a penetration tester would do manually—probing your application to try to find a way in—but at a much more affordable price. Dynamic tools also test not only your application’s code but the environment in which it runs, as well. Unlike static tests, which explore all code, dynamic tests probe only the code that is actually executed.
Dynamic tools are slower, by several hours, than static tests, making them more of a challenge to embed into your DevOps pipeline. Still, while you may not be able to test each change as it is introduced by a developer, dynamic tests can be run on similar schedules to longer running tests, such as functional and acceptance testing.
Automation Isn’t Enough
If you can’t rely on the assumption that developers already have enough application security knowledge not to introduce vulnerabilities in the first place, why would you assume that they will know what do with the reports produced by these tools? The feedback loop to developers falls apart when there is a lack of training and guidance to know what to do next. A good automated solution provides recommended remediation for vulnerabilities found, as well as a good explanation of the vulnerability itself and how it might be exploited if it is not fixed.
To be successful, security automation must contribute to the development process. If it serves as an obstacle, developers will naturally find away around it. A tight feedback loop with developers—one that provides not only security risk introduction notifications, but also guides the developer to the right fix—may be your best security education program.
While embedding automated security assessments into the DevOps pipeline helps push the discovery of vulnerabilities to the left side of the software development lifecycle, there is still opportunity to push even further left. More security defects are introduced during the requirements definition and design phases compared to coding phases. Requirements and architectures must be drawn up to be secure from the start with a focus on the OWASP core pillars of information security: confidentiality, integrity, and availability.
Opinions expressed by DZone contributors are their own.