close search bar

Sorry, not available in this language yet

close language selection

Agile and application security: A promising pair

Synopsys Editorial Team

Sep 22, 2015 / 4 min read

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.


Agile security manifesto eBook

The Agile Security Manifesto

Explore the four principles of the Agile Manifesto  and how to apply them to build secure software.

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.

Creating a robust agile application security practice

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.

Agile security manifesto eBook

The Agile Security Manifesto

Explore the four principles of the Agile Manifesto  and how to apply them to build secure software.

Continue Reading

Explore Topics