If you are a developer reading this series, you probably have a feel for what Agile development means. For those of you who don’t live it every day, or have read the exceedingly poor Wikipedia page on Agile software development, you are probably wondering what this is all about.

In the simplest terms, Agile software development is a set of techniques for building the intended software with fewer errors and better predictability. Each technique is intended to address common failures in ‘waterfall’ development: complexity, poor communication, and infrequent code validation. So Agile approaches embrace simplicity of task, fast turnaround for smaller pieces of working code, and a preference for human interaction over email/document/process oriented interaction. Simpler tasks make it harder for developers to misunderstand what the code is meant to do. Faster iteration produces working code more often, with three distinct benefits: early confirmation that you are building the correct solution, quicker detection of breakage, and more accurate project completion estimates. Face-to-face human interaction helps clarify what everyone on the team is building, and greatly reduces communication errors – which are far too common with ambiguous documentation and code specifications. Smaller, simpler, and faster.

The most popular flavor of Agile today, by a large margin, is Agile with Scrum. Each characteristic of this approach has been selected to support agility. For example short development ‘sprints’, typically 1-4 weeks, are used rather than the 18-month cycles common to traditional waterfall development. Agile with Scrum relies on daily ‘scrum’ meetings, where all the developers meet face-to-face to discuss what they will be working on that day. Developers receive their tasks on 3×5 cards, which quite effectively limits task complexity. Each sprint focuses on iterative improvements rather than complete feature delivery. This ensures that only functional code modules are checked in – unlike waterfall where every feature is typically crammed in on deadline. If you need more information, Ken Schwaber’s book Agile Project Management with Scrum is the best reference we have found, so pick up a copy if you want detailed information.

So why do security professionals care? Because development has shifted focus to smaller, simpler, and faster – effectively excluding slow, indeterminate, and complex security tasks.

Over the past 15 years development processes have evolved from waterfall, to rapid development, to extreme programing, to Agile, to Agile with Scrum, to the current darling: DevOps. Each evolutionary step was taken to build better software by improving the process of building software. And each step embraced changes in tools, languages, and systems to encourage Agile processes while discouraging slower and cumbersome processes. The fast flux of development evolution deprecated everything that did not mesh well with the new Agile model – including security. Agile got a bad rap with security because the aspects that promoted better software development (in most ways) broke conventional approaches to building security into code. There are several areas of conflict.

  1. Tests that do not fit the Agile process: The classic example is development teams moving to a 2-week Agile ‘sprint’, when security relied on 2 months of automated fuzz testing.
  2. Security data that does not integrate with development systems: The classic example is external penetration testers who identify thousands of instances of hundreds of vulnerabilities, then dump unexplained findings onto development teams, who have no idea what to do with the results.
  3. Security tools that do not integrate with development realities: The classic illustration is testing tools which required 100% of code, with all supporting libraries, to be fully built before tests can be conducted. This prerequisite breaks small iterative code changes, delivered weekly or daily.
  4. Insufficient knowledge: Just a few years ago most developers did not understand XSS or CSRF, and when they did, it was unclear how these issues should be addressed across the code base. Understanding threats and remediation were not common skills.
  5. Getting security into the work queue: The move from waterfall to Agile meant the removal of specific security testing phases, or ‘gates’ in the waterfall process. For security features or fixes to be integrated, they must now be documented as tasks, and then prioritized over other features – otherwise security gets ‘starved’ off the development queue.
  6. Policies: A big book of security policies, vulnerabilities, and requirements is extremely un-Agile. One of waterfall development’s most serious issues is large complex specifications that confuse developers. Agile development is an effort to protect developers from such confusing and unwieldy presentation of essential information.

During this amazing period of advancement in software development, we have seen an equally amazing evolution among hackers and attacks against applications of all sorts. Security has largely remained static, but there are plenty of ways to integrate security into software development, provided you are willing to make the necessary adjustments. Our next post will help you do so.