As you lead your organization in securing software development and delivery, you will come across several challenges – despite the recent growth and increased adoption of the agile methodology. Application vulnerabilities and coding issues are typically time-consuming to find, document, and fix with traditional testing tools. Short agile sprints don’t lend themselves to these long processes; however, there are ways to effectively integrate secure development with agile methods. The very nature of agile development lends itself to keeping developers working efficiently within their toolchain by giving them the tools to finish the job before they move on to the next feature.
The classic waterfall methodologies related to development cycle is typically top-down in nature and lacks visibility into the day-to-day workings of developing software. While high-level objectives around timing and meeting roadmap deadlines take precedence, the quality and often the security of the product can be comprised. The subsequent disconnect between Security and Development teams further delays both the implementation of compliance requirements as well as the delivery of secure software.
In an agile environment, developers write code based on work committed in the current sprint. At various points in the process they use their Integrated Development Environment (IDE) to upload code to Veracode’s cloud-based service for static application security testing (SAST). Once assessment is complete, the results are downloaded to their development environment. Developers can now address any vulnerabilities introduced before check in. By finding vulnerabilities during the coding phase instead of during a separate security hardening sprint, developers need not switch context to work on code written long ago. This saves time and increases velocity – while at the same time ensuring the security of the software being developed, tested and shipped.
As a result, the agile methodology will enable those leading Development teams to have first-hand insight into security of the code being built -and be able to reconcile these assessments with timelines around product testing and release dates. This ability begins to reduce the gap between the goals of the Security side of an organization and those of the Development teams. Neither innovation nor security is sacrificed.
Stay tuned for my next post on how to embed security into an actual sprint – increasing effectiveness and reducing time spent on the security assessment process. In the meantime, I welcome any thoughts or experiences you are able to share on agile methodologies for secure software.
- 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