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.
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.
There are opportunities in a typical agile development effort that can be leveraged to inject software security at the appropriate place in the SDLC:
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:
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:
Those in quality assurance and testing roles should be offered a course on Risk-Based Security Testing Strategy. Objectives of this course are:
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:
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.
David Harvey, CISSP, is a former principal consultant with Synopsys. David evaluated agile practices, led code reviews, and trained developers on defensive coding and threat modeling. Before joining Synopsys, he worked for UnitedHealth Group, where he co-founded and led a developer-facing software security initiative. David has also worked as an architect and developer at Siemens, Boeing, and Unisys. He learned about software security when the “information superhighway” was just becoming a thing and Fortune 20 companies were starting to bear the brunt of unsanitary design and coding practices that had been de rigueur in the old, segregated, safe “client-server” or “feudal” deployment models.