How to create an effective software security training program for agile teams

Agile is a great innovation in software development. The agile focus on stakeholder involvement end-to-end, transparency and short delivery cycles are changes for the better for our industry. However, just-in-time nature of requirements, bug and flaw triage in agile makes it all the more critical that everyone on the team has a certain level of security knowledge. The moving parts of the agile methodology make it even more important to properly “build security in” and this requires trained people and good supporting infrastructure. This is especially critical for development efforts that handle sensitive or confidential data.

The problem with software development and software security

Testing can prove the presence of bugs, but not their absence.

– E. Dijkstra, computer scientist and author

In order to support near-constant delivery or short delivery cycles, agile has a strong bias towards automatic processes. While in general that’s a good thing, many agile software development efforts delegate security checks to testing initiatives like automated unit test suites and dynamic analysis tools like penetration testing. These automated processes are usually executed in a waterfall way, which completely undermines the agile philosophy. You should definitely use these processes but you shouldn’t rely solely on them for security. The problem is that you cannot “test in” software security. Unit tests, regression test suites and dynamic testing only tell you how broken your software is—they don’t tell you how secure it is.

Although not unique to agile projects, there’s also the issue that the focus of information security has traditionally been at the network layer and not on the software itself. This can (and does) lead to an overreliance on perimeter security: firewalls, SIEMs, traffic fingerprint devices, etc. The problem is many recent software breaches have been affected at the application layer or data layer and have gone undetected, sometimes for months (!), by perimeter defenses. Software security is a distinct practice within the information security world. It is enough of an emerging concern that many in software development, testing and product owner roles are not aware of the need to build defenses into the code itself.

You should be solving as many security problems as possible early on, preferably before or as the code is written. As with all flaws and bugs, the earlier in the software development life cycle (SDLC) you find and fix a security problem, the cheaper easier it is to address. Proper training of all the people specifying, designing, developing and testing software can go a long way to building the expertise necessary to stop security problems early.

Why is agile special?

There are opportunities in a typical agile development effort that can be leveraged to inject software security at the appropriate place in the SDLC:

1. Release planning and user story development. Most documents describing agile best practices on writing effective user stories focus on capturing and stating functional requirements (e.g. ‘delivering value to the user’). Security requirements are generally non-functional requirements and as with all non-functional requirements it’s sometimes difficult to see the value add. Agile teams need to be skilled at capturing and documenting security, both functional and non-functional, requirements and developing test cases appropriately.
2. Sprint planning and backlog grooming. When a requirement, bug or flaw is considered, it is imperative that the individuals in the planning and grooming processes have appropriate security knowledge to do effective triage and estimation.
3. Iterations are short. As Neil Bahadur recently stated on security in agile processes: “Releasing every 14 days means a security assessment can’t take five days each time.” Knowledge of how the features being added in a current iteration impact security can help the team decide when the code base will change enough in appropriate areas to require additional software security activities.
4. User story acceptance. It is necessary that the product owner and other stakeholders recognize that the definition of “done” includes security and non-functional requirements.
5. Cross-cutting. Application of expertise in the security features inherent in the languages and frameworks used by the team.

Training for the agile team

For all members of the agile team, including product managers, product owners, scrum masters, developers and those in testing and quality assurance roles, a Foundations of Software Security class introduces the fundamentals of software security problems, risks and general approaches for producing better software. Objectives of the Foundations of Software Security course are:

• Recognize how best practices in the software security touch points can augment your development processes to improve the security of your software
• “Think like an attacker” when conceiving, building and testing your software
• Recognize common software coding errors
• Describe elements that are characterized as “good” software requirement
• Differentiate between normal software requirements and software security requirements—functional vs. non-functional requirements
• Identify security requirements and the issues they address

Developers should also be offered courses on Android security and Attack and Defense courses for the relevant development environment and framework (e.g. C# and .NET). Objectives of these courses are:

• Apply best practices when developing software to avoid common security coding errors
• Build more secure code by recognizing how your coding language can be exploited
• Identify common coding mistakes that impact application security
• Identify multiple secure alternatives for fixing common security bugs

Those in quality assurance and testing roles should be offered a course on Risk-Based Security Testing Strategy. Objectives of this course are:

• Develop a white-box testing strategy based on real-world risks to improve where and how testing resources can be focused to increase velocity
• Describe how to use architecture risk analysis and abuse case artifacts to enhance and focus test plans
• Use knowledge of common software errors for developing test cases to expose them

Architects and senior developers should be offered the developer training and training in Threat Modeling to ensure that security controls are applied in the design and architecture appropriately. Some objectives of the threat modeling course are:

• Understand different types of threat models (STRIDE, Synopsys, etc.)
• Understand how to model the software for each type of threat model
• Understand how to relate assets, security controls and threat agents to focus the application of controls where needed
• Produce a report describing potential attacks and mitigations

Other considerations

Consider developing or acquiring secure coding standards and other “official” reference material for the development effort to reduce questions and discussion that slows down development efforts when security issues come up.

An automated secure code review tool can automate the finding and fixing of software security issues without seriously impacting the velocity of the agile team. Security code reviews using a data-driven tool that provides reasonably intelligent contextual background with an analysis trace of how the finding may be an issue can be an excellent mentoring experience for developers new to software security. The IDE plugin Code Sight is an example of a secure code review tool.

There is nothing about using the agile methodology that makes you more or less likely to produce secure software. Conversely, there’s nothing about a functioning secure development practice that precludes the use of agile. With the proper training and knowledge, the development team, stakeholders, product owners and testers can produce secure software with all the benefits of agile: short iteration or continuous delivery, early stakeholder evaluation, and minimal friction.