For an enterprise application, assuming we do lots of little changes (2 week – 3 week iterations), how frequently should we do a comprehensive security examination?
Implementing security in Agile projects can be a challenge. Leveraging existing Agile practices such as automated testing and user story development helps development teams successfully address Agile security concerns.
Teams should strive to automate as much testing as possible.
First, look toward automation to handle testing for certain types of technical vulnerabilities in software like SQL injection and cross-site scripting, which are often easily detected by automated tools. Leveraging software developers' continuous integration infrastructure can help you run these tests along with other quality testing activities. This way, you can configure testing tools once and then run them with every new build.
There are freely available tools that can help with automated security testing. Static analysis tools such as FindBugs and PMD can offer some value, but most freely available static analysis tools do not have the powerful dataflow and control flow capabilities needed to provide sufficient coverage. However, some free dynamic analysis tools such as OWASP ZAP do provide solid detection and can be sufficiently automated to include in a build.
These measures won't give you "comprehensive" security evaluations. They will help identify certain coding bugs very soon after they are introduced to the code. At which point, they will hopefully be easy and inexpensive to address.
Comprehensive security examinations
With regard to performing more comprehensive security examinations including manual testing and code review, this will depend on several factors such as the available budget and the criticality of the application in question. It also depends on the types of changes in an iteration.
- Budget -- If security testing was free, there would probably be a lot more of it getting done. As mentioned above, automation can greatly reduce or eliminate the cost of incremental testing for certain types of vulnerabilities. For other issues, manual testing -- or at least manual-guided testing -- must be included for more comprehensive coverage.
Getting better leverage out of your investments in this area can be more challenging than with automated analysis. The important thing is to understand the limits of the resources and apply them deliberately.
- Application criticality -- Not all applications are created equal. Those that manage less critical data or are less valuable to an organization will usually go longer between deeper security inspections. This does not mean that lower-value applications should never be subject to review, but the reviews will often be less thorough and performed less frequently versus high-value applications or those considered to be high-risk because of the data they manage or other factors.
- Types of changes -- Not all changes are created equal. Even iterative projects roll out major new features, and when these features represent significant increased attack surface for an application or when the features expose new sensitive data and functionality, it might be time for a deeper dive. Many Agile projects use "user stories" or "use cases" to capture user requirements.
A great way to get Agile security involved in the process is to concurrently create "abuse cases" for new requirements investigating how they might be misused or attacked. That way, developers can pre-harden new features while they develop them, and manual testers can target their efforts on new, risky parts of the code.
Ultimately teams should strive to automate as much testing as possible and then make targeted decisions about when and how to apply manual testing on top of that.
Dig Deeper on Topics Archive
Related Q&A from Dan Cornell
Is it safe to move from on-premises application lifecycle management tools to cloud-based tools? Read this expert answer to find out. Continue Reading
Can security impact application performance? What security vulnerabilities might be slowing us down? Continue Reading
As our developers incorporate more and more third-party software components and partner APIs that we don't have direct control over, how do we test ... Continue Reading