Posted by Synopsys Editorial Team on September 22, 2015
Agile and application security are often spoken of together as oil and water, but are they really?
Agile software development happens fast. The high frequency of iterations and releases often translates to wildly dynamic application build structures, with new components/modules added regularly throughout the software development life cycle (SDLC). This iterative approach enables teams to adjust course early and often, addressing problems as they arise. Addressing problems with the application early and often sounds like a great approach to security. So, what’s the problem?
To put the Agile and application security relationship into perspective, we must first examine traditional security measures.
For any security activity to be effectively integrated into Agile development practices, it needs to be light-weight and delivered in bite-sized chunks that seamlessly fit into existing development processes.
Traditionally, security activities have taken an approach requiring significant time to perform analysis, to parse and communicate the results to application owners and to act as gates to deployment. Activities like manual secure code review can take weeks depending on the size of the application being assessed. If this potentially time consuming activity is a requirement for application deployment, and your average agile sprint duration is two weeks, fitting the two together seems infeasible.
One solution may be moving from manual code reviews to a more tool-oriented approach using static application security testing (SAST or static analysis) tools. Static analysis engines are built to scan applications in their entirety. The notion of incremental scanning is a non-starter with present-day static analysis tools. Modern static analysis tools are engineered to compile all application components together to construct intermediate models for further analysis. This means that scanning individual modules (as they are being built out in agile projects) is not only a tough task for such tools to accomplish; but, would also yield sub-optimal results. The same is true for manual and automated ethical hacks, sometimes referred to as penetration testing and dynamic application security testing (DAST or dynamic analysis) respectively.
Using traditional security measures, you’ll find days of a sprint consumed by security activities to find vulnerabilities in the application. Following that, these measures then require reports of the assessment activities and findings to be provided to the development team for remediation.
How have those findings traditionally been reported to developers? Well, with reports containing all of the findings and hours-long knowledge transfer sessions to ensure that the developers understand the security vulnerabilities, of course! There’s a better solution to achieve application security when discussing time efficiency without sacrificing quality.
To achieve security success in Agile environments, we need to break down tradition and start treating security as an integrated piece within agile processes.
One of the first considerations is determining your organization’s appetite for risk. A risk-based approach to security will help guide the decision-making process around how deep and broad security assessments go, as well as what to look for. Common web vulnerabilities like cross-site scripting (XSS) and SQL injection will likely end up quite high on the list of things to be concerned about finding in web applications. However, they might not make much sense in largely embedded applications (Internet of Things aside).
The focus of an Agile security practice should be on the highest risk findings, in the highest risk components of applications. One question that we often hear when making this point is, “so you’re telling me that vulnerabilities could make it into production?” Well…yes. But I’ve got some news for you; vulnerabilities are already very likely in your production code today.
Catching everything before production is a virtual impossibility. Building a large volume of successfully identified findings doesn’t solve the problem so much as it builds a large volume of successfully identified findings. The point here is to find the security vulnerabilities that would keep you up at night and create a plan to fix them in an upcoming sprint. If the finding is critical enough to be a showstopper:
No discussion of Agile would be complete without addressing automation. Automation is royalty when it comes to speed and consistency in identifying findings, but does come with some caveats. During automated scanning, the focus should still remain squarely on the most critical of findings, but should also take into consideration the confidence in the automated tools that have been selected in their ability to accurately identify categories of findings. If a particular tool or testing strategy is prone to false positives with a particular vulnerability type, don’t automatically report those findings to development teams. Automatic reporting of false positives will create an unnecessary workload on the already time-crunched development teams, reducing their confidence in the security practice and decreasing productivity. Once the critical findings numbers start to dwindle, the scanning machine can be tuned to include lower risk findings; beginning to make the approach to security as iterative as Agile is when developing the code.
After building a more streamlined means of identifying security bugs in code, what’s next? Fix. The. Bugs. It’s easy to say, but the devil is in the details. A good approach includes:
Leverage issue trackers to file security bugs in an application as tickets just like you would any other bug in the system. This approach integrates very tightly with the developers’ day-to-day operations and keeps secure development in the forefront. Don’t stop there! Fix the bug first and foremost, but also create a test case to ensure that the bug doesn’t rear its ugly head again (leveraging Test-Driven Development or Behavior-Driven Development tools and practices).
During the design of an application, build use cases, in addition to misuse cases (how could our application unintentionally expose security flaws) and abuse cases (how could a malicious user intentionally expose security flaws) cases. This can be accomplished through threat modeling. Threat modeling identifies a system’s major software components, threat agents, security controls, assets and trust zones, which together describes the attack surface. Like performance engineering’s capacity planning, threat modeling details a foundation for developing a technology-specific security test plan for tracking threats and attack vectors through a traceability matrix.
Building automated security scanning facilities should be an early focus. Don’t try to tackle everything right away. Just like developing Agile software, take an iterative approach to implementing security capabilities using checkpoints to analyze the efficacy of existing capabilities and adjusting as needed (identify opportunities for new capabilities, customize existing capabilities, replace failing capabilities). Continually repeat this process.
A robust Agile security practice will improve visibility and governance, leverage automation to reduce time requirements for security analysis and promote the reuse of security components.