Agile and application security: A promising pair

The traditional approach to application security

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.

How is the agile approach different?

To achieve success with agile application security, we need to break down tradition and start treating security as an integrated piece within agile processes.

Adopt a risk-based approach

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:

• Stop the show.
• Fix the bug.
• Try again.

Agile application security and automation

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, keep the focus on the most critical findings. But also consider how confident you are that your automated tools can 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. Creating an unnecessary workload for development reduces their confidence in the security practice and decreases productivity.
• Once the critical findings start to dwindle, tune the scanning machine to include lower-risk findings. That’s how to make your agile security approach as iterative as your agile development approach.

Translate findings into solutions

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:

• Treat application security bugs just like any other bug identified in agile development.
• Treat security considerations as nonfunctional requirements.
• Build automated tests to check for security bugs much like your typical bug regression tests.

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.