"We're practicing agile, so that means we don't do any architecture or security planning"

Agile is sometimes used as an excuse to bypass controls in large organizations. Fortunately, agile methodologies and security methodologies work really well together!

In this article, I will cover the contents of a talk I gave on including security in the agile life-cycle, and how both development and security teams can benefit from adopting agile principles and working together.

Security in the Traditional Waterfall Development Model

"Will these security findings prevent us from going live next week? Can we wait to work on them until next quarter?"

Traditionally, security has worked with project teams during two phases of execution: technical requirements design and right before go-live.

After a team has gathered their business requirements and sorted out a target architecture, they may go to a security review, run through a threat modeling and data flow exercise, then take a stack of security requirements and put them into a design document. This document gets handed over to development when all the requirements are reasonably stable, and development goes off to build it for the next several months (or quarters).

After they have a working program and users have signed off, the team comes back to security for sign off. At this point, security runs tools and penetration tests, and comes back with a stack of vulnerabilities.

Unfortunately for everyone involved, this is often one of the last things before a production go-live is scheduled, and fixing security issues certainly jeopardizes the project schedule.

Further compounding the problem, developers who unknowingly created the security bugs may have done so months before, and so no longer have an intimate knowledge of the particular piece of code containing the vulnerability. They also may have been using an insecure programming pattern that replicated itself across the code base, resulting in a large number of similar vulnerabilities scattered around the program.

The end result is that everyone is unhappy! security is unhappy because open issues will make it into production (the schedule usually wins). Product is unhappy because they worked overtime fixing some of the issues, and have more unexpected work scheduled. Leadership is unhappy because it looks like security and development didn't work well together.

There is, of course, a better way.

Integrating & Automating Security for Agile Development

If we are able to automate security tooling, we can incorporate it at every stage of the agile cycle, and improve outcomes for both security and the development teams.

Security in Sprint Planning

When sprint planning, I ask teams to do a few things:

• Include security stories in the backlog, and prioritize them alongside business features. These may come about as a result of threat modeling or outputs from security audits / pentests / scanners.
• For each story selected for the current sprint, review a secure development checklist. Essentially this is a repository of guidelines on preventing common issues tied to functionality - using parameterized queries for DB interactions, filtering dynamic data before displaying on a web template, etc.
• Determine if any security specific training might be needed. This is similar to any other technical training that might be needed by the engineer assigned the story.

Security During Design

As stories are selected, teams then move on to formal or informal design as they determine if any infrastructure changes are needed, what software architectures and integrations will be used, etc. During this phase, I ask teams to consider three questions which shouldn't add significantly to the workload:

1. Does this story change where we are ingesting or outputting data? If so, update the data flow diagram.
2. Does this story change our potential risk profile, or create new threats? Take some time to update and review the threat model.
3. Is there anything in this story that we might want to review formally or informally with a security expert?

Security During Development & Test

As we move into development, automation becomes critical. Security continues to be a blocker instead of an enabler until the tools at this stage can be automated and integrated into the development cycle. To this end, I generally recommend striving for the following:

• Integrate a static analysis tool into the IDE whenever possible. SonarQube can be configured this way, along with many vendor SAST tools. This allows developers to see security bugs in near real time, minimizing re-work and maximizing learning.
• Integrate Dependency / Open source security checks into local build processes whenever possible. This will catch vulnerable dependency versions as soon as they are added to projects in one team members machine.
• Integrate both of the above into a CI/CD pipeline, and break the build on issue thresholds. This way, if someone on the team isn't running the tools locally, you can at least enforce security prior to any deployments.
• Configure dynamic test tools into the CI/CD pipeline on deploys. This one can be a little trickier to setup. To get started with this, I usually recommend configuring a ZAP baseline scan integration, or using your DAST vendor tools. Additional dynamic tests can be added over time.

Security During Deployment

In the deployment phase, we need to make sure we are doing a few things:

• Updating any out of date application components (for instance, rolling patches into a docker container before deploying the latest changes)
• Considering if any changes being deployed require changes to our alerting / monitoring / logging / prevention infrastructure.

A Security Automation Roadmap

If you are interested in starting this journey, you don't have to do it all at once. Here is an ordering that I have found works well in rolling out security automation.

1. Have security professionals join some sprint planning meetings to get a feel for the functionality of the application. Work with the team to develop an up to date threat model and data flow diagram. The security professional can take the outputs and create new user stories with the findings.
2. Teach the whole team basic threat modeling and try to get them thinking about it each sprint cycle. No one has to be an expert - just spending a few minutes thinking about threats will yield benefits.
3. Determine if applications teams are using CI/CD. If they are, work with the build engineers to integrate static analysis into them, in a non-build-breaking manner. Start with SonarQube & DependencyCheck if your organization doesn't have a SAST vendor. This way, the team can start seeing results and remediating them, without interrupting their flow. Plan a timeline to start breaking the build on issues. If CI/CD is not implemented, setup some regular automated SAST scan (weekly or monthly).
4. Work with one or two engineers to integrate SAST into their IDE. Based on the outcome, consider attempting to get all team members to adopt this flow.
5. Setup CI/CD integrated dynamic scans. Start with the ZAP baseline scan or your own preferred DAST vendor tooling. If CI/CD is not setup for the team yet, try to configure a regularly scheduled scan.

From there, add scans and tools as needed, and slowly build up documentation around how each item is configured, issues remediated, and best practices for new engineers to follow. Each team will have a slightly different toolset and needs based on culture, languages, frameworks, preferences, etc.

The idea is be flexible, have fun, and work together to improve the security and quality of the overall code base. Everyone should benefit from this setup.

What Has Worked for You?

I always like to hear what has worked well in other organiztions integrating security and agile. I would love to hear your stories in the comments!