How do you transition to agile security from traditional security to agile security? Learn how to add security to your agile development process.
You can build security into your waterfall software development life cycle (SDLC) when you have days or weeks to dot your i’s and cross your t’s. Don’t have time for that? Well then, agile is the fastest way to add add security to your SDLC.
What do you do when you’re engineering at high speeds? How do you transform your processes into something that will fit your fancy new agile lifestyle? The following sections offer a glimpse into how to add security to your agile development process and how to determine the best way to add them.
What stays the same when transitioning to agile?
The security steps themselves.
An agile application security approach doesn’t change the touchpoints, because changing the speed of development doesn’t change the types of security bugs or flaws you introduce. Continue using the security fundamentals your business is accustomed to:
- Application security training for everyone involved with application building projects
- Security requirements during requirements gathering
- Architecture risk analysis during design
- Static application security testing or secure source code review during development
- Dynamic application security testing or penetration testing before production
If the security fundamentals remain the same, what changes?
The implementation of these security steps.
Agile processes aren’t special snowflakes. They just make process inefficiencies more obvious than their waterfall counterparts. Here are a few examples of how:
- Releasing every 14 days means a security assessment can’t take 5 days each time.
- Stopping or slowing down development for days or weeks may actually pose more risk to your business than getting code through without detailed analysis.
- Operating outside of the build cycle isn’t practical, since we are always in the build cycle with agile development.
How do I transition from a slower secure SDLC to a faster one?
Your secure SDLC needs to be as “incremental” as your SDLC. However fast you release, your software security risk indicators must fire at the same speed. You don’t need to do security testing every minute, but you need to know whether your code has changed enough each minute to merit a security test. Your risk indicators will set the threshold for when the codebase has changed enough to require software security activities. Some examples of risk indicators:
- Type of data being handled (e.g., personally identifiable information or other sensitive data)
- Change to security features (e.g., authentication, crypto, authorization)
The best kind of security is the kind that fits your business style. Here are a few ways you can start implementing agile security into your business:
- Create new and updated processes that match the culture and are realistic.
- Make incremental changes to the process. Revisit additions if they cause issues.
- Determine the risk threshold for stopping or slowing down. Not every minor change needs a full review, but maybe every major one does.
- Automate and add tools to catch low-hanging fruit. Options: a canned set of security requirements, a well-tuned security tool that only identifies a few findings but with high precision, and so on.
- Do things the old-fashioned way periodically to make sure the new and “improved” way is working properly.
- Create a process where compliance is guaranteed by virtue of following the right build process.
- Create passive reviews that sound alarms for deeper testing without stopping the production line entirely.
- Learn your technology well enough to know what tools will play nicely with what you have in place today.
Things to remember
When adding security steps to your agile process:
- Don’t reinvent the wheel. Your waterfall-secure SDLC has plenty of raw materials. Maybe today you’re doing things such as code review, penetration testing, and threat modeling. You can add the same steps to your agile process, but do them only when needed, based on your risk indicators.
- Think strategically. When you shine a light on your risks, your headlights should outpace your travel speed. In other words, make sure that if you change a function that handles PII in a one-day release, you’ll be notified of a change to something handling PII that day.
- Build incrementally. Agile is about incremental development. In the same way, your foray into agile security should take the form of manageable, bite-sized sprints.
As you start to shift the discussion from “what” to “how,” you can think about how to draw from your current security SDLC to add security steps to your people, process, and technology for agile development.