The research is being conducted by Securosis, a small, well-respected analyst firm with strong ties to the security community. It will initially be published as a series of blog posts on which anyone can comment, following the firm’s Totally Transparent Research process which aims to maintain the firm’s objectivity while producing licensed research.
The content is being written by Adrian Lane, who specializes in application/data security and software development topics (having spent many years as a CTO and VP/Development at various software companies). Rich Mogull, CEO of the firm, was previously a Gartner VP specializing in security.
Rich and Adrian initiated the series by interviewing Veracode’s development team about how we build security into our own agile SDLC. Here’s a quick synopsis of each of the blog posts that have been published since the series began last week:
How to incorporate security into software development organizations – and most acutely into Agile development – remains a constant problem for clients. Knowing what tool to use and where does not address the fundamental issues of culture, goals, and process that make secure code development such a challenge.
Embedding security into development processes is hard. Not because developers don’t care about security – the majority of developers we speak with are both interested in security and would like to address security issues. But developers are focused on delivery of code, and spend a good deal of time trying to get better at that core goal. Secure development practices, just like every other facet of development, must fit within the Agile framework – not the other way around.
2. Agile Trends
In the simplest terms, Agile software development is a set of techniques for building the intended software with fewer errors and better predictability. 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.
So why do security professionals care? Because development has shifted focus to smaller, simpler, and faster – effectively excluding slow, indeterminate, and complex security tasks.
Why can’t we all get along? There is no point ignoring the elephant in the room – it won’t shock anyone that there has historically been friction between security professionals and development teams. This isn’t because of inherent animosity but due to conflicting priorities. Development needs to ship functioning code on time and within budget. Security needs to manage risks to the organization, which includes risks introduced by new technologies including code. One needs to go as fast as possible: the other needs to keep from smashing through the guardrails and flying off the road.
Recommendations: Mostly it comes down integrating security as seamlessly into their processes as possible, without sacrificing your security objectives. For example:
- Tell your story: A story is Agile’s fundamental unit for communicating project requirements. You may need to get your hands dirty, write security ‘stories’, and help develop task cards to describe the security work to be done. Face it – product managers don’t know security all that well, and if you really want the development team to understand what you need built, you will need to help write the stories.
The common waterfall development process has cleanly delineated phases, each of which provides an opportunity for security integration, and each security activity must be completed before moving on to the next phase. Agile includes whatever work gets done in the sprint – it does not bend to security so you need to bend security to fit Agile.
Here are recommendations for how to integrate security tasks into Agile:
Architecture and Design:
Many include threat modeling as a task within user stories, so it is just another development operation for a development team member. Others choose to model threats as the stories are written, by product managers or senior developers, baking the results into design changes that affect task cards. Rather than a long list of requirements try a simple state machine diagram to get the idea across. Clear examples of what you want and what to avoid are best.
Product Management and Task Prioritization:
The Product Manager or Product Owner assigns tasks. Their responsibility is to manage incoming features or Stories, break work down into manageable tasks, and prioritize them. They often have the least security knowledge on the team. We recommend working with Product Management to assign tags/labels to security tasks and vulnerabilities so they can be tracked like any other feature or bug. Balance security against other development tasks.
Development and Debugging:
In the waterfall days Quality Assurance teams were often handed completely untested code. In comparison, Agile requires verification that code performs its basic function before QA even accepts it. Select small items that quickly help identify whether code passes or fails to meet requirements. 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.
Quality Assurance and Release Management:
Did we mention that Agile with scrum does not have a QA phase? Instead development checks in small pieces of code and demonstrates functionality to the team, a lot more testing occurs earlier in the process. The good news is that you will be moving more security tests than ever before into automated development tests.
Future posts in the series:
- Tools and Testing in Detail
- The New Agile – DevOps in Action
We hope you’ll enjoy this awesome content and learn from it to enhance your own secure agile processes. Happy reading!