How does agile application security differ from traditional application security, and what does it mean for your agile development practice?
Agile development 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 and 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 application security into perspective, we must first examine traditional security measures.
To integrate any application security activity into agile development practices effectively, it needs to be lightweight and delivered in bite-sized chunks that seamlessly fit into existing development processes.
In the traditional approach to application security, it takes a lot of time to perform security activities, set them up as deployment gates, and communicate results to application owners. Manual secure code review, for example, can take weeks depending on the size of the application. If this activity is a requirement for application deployment, and your average agile sprint duration is two weeks, fitting the two together seems infeasible.
And don’t forget about reporting and remediation. Using traditional security measures, not only does it take days to perform security activities take days to perform, but remediation takes even longer, with reports containing all the findings and hours-long knowledge transfer sessions to ensure that the developers understand the vulnerabilities. There’s a better solution to achieve application security when discussing time efficiency without sacrificing quality.
To achieve success with agile application security, we need to break down tradition and start treating security as an integrated piece within agile processes.
First, determine your organization’s appetite for risk. A risk-based approach to security will help guide decisions about how deep and broad security assessments go and what to look for. For example, common web vulnerabilities like cross-site scripting (XSS) and SQL injection are high priority for web applications, but maybe not for embedded applications. An agile application security practice should focus on the highest-risk findings in the highest-risk components of applications.
Are we saying that vulnerabilities could make it into production? Well, yes. But I’ve got some news for you: It’s likely that your production code already has vulnerabilities anyway. Catching everything before production is impossible. Building a large volume of successfully identified findings isn’t a solution in itself. It’s better to find the 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.
After streamlining your process to identify security bugs in code, what’s next? Fix. The. Bugs. It’s easy to say, but the devil is in the details. Here’s a good approach:
Use issue trackers to file tickets for security bugs just as you would any other bug. This approach integrates 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 (using test-driven development or behavior-driven development tools and practices).
During application design, as you build use cases, also build misuse cases (how could the application unintentionally expose security flaws?) and abuse cases (how could a malicious user intentionally expose security flaws?). You can do this with threat modeling. Threat modeling identifies a system’s major software components, threat agents, security controls, assets, and trust zones, which together describe the attack surface. The process details a foundation for developing a technology-specific security test plan for tracking threats and attack vectors through a traceability matrix.
Automating your security scanning should be an early focus. Don’t try to tackle everything right away. Instead, take an iterative approach to implementing security capabilities. Use checkpoints to analyze whether existing capabilities are working, and adjust as needed (identify opportunities for new capabilities, customize existing capabilities, replace failing capabilities). Repeat this process continually.
A robust agile security practice improves visibility and governance, uses automation to reduce time requirements for security analysis, and promotes the reuse of security components.