In my recent blog post I discussed some of the fundamental tenets of the agile methodology of software development – one of which is keeping developers working efficiently within their tool chain. Having held the role of Scrum Master myself, I’ve had the responsibility to ensure that members of my development team have the tools they need to finish their tasks at hand before they move on to the next story within a sprint. This begs the question of how to embed security into an actual sprint – increasing effectiveness and reducing time spent on the security assessment process.
Too often, security assessment is done only as a pre-deployment gateway or checkpoint. When using agile methods, development teams often handle these requirements by scheduling a security hardening sprint after they have a functionally complete release candidate. This means that the security assessment forces a hybrid waterfall-agile development process instead of truly enabling the best practice of agile — complete the work in the sprint. Frequent assessments allow the team to identify and remediate release blockers early in the cycle — when they are easier and less expensive to fix. This reduces the overall risk to the team for successful delivery of their payload. Equally important is that the majority of Veracode service scans finish quickly — within hours or overnight (in fact, 80% of assessments for Java and .NET applications are turned around in less than 4 hours). That means that security assessments can fit into a one to two week sprint that is typical in most development organizations.
Independent security analyst group Securosis echoes these sentiments and specifically recommends making security requirements and tests part of the story by selecting small items that quickly help identify whether code passes or fails to meet requirements. With regards to new features, the key is to have the developer understand the core security requirement by having them construct acceptance tests to get an early idea of whether or not they are on track. For vulnerabilities and flaws, managers should ask for security regression tests to be included with the fix to ensure that mistakes are not repeated. If your organization automates static testing during the development phase you will need to integrate results into tracking tools so developers can leverage them while the code changes are fresh in their minds.
Stay tuned for my next post on how to use multiple techniques for security assessments. In the meantime, I welcome any thoughts or experiences you can share on securing code early in the agile development process.
- Google Hangout Recording: Building Security into the Agile SDLC: Two Sides to the Coin
- SANS Survey on Application Security Programs and Practices
- Webinar: Building Security Into the Agile SDLC: View from the Trenches