Securing software applications has not exactly become easier with the advent of agile software development methodologies such as scrum. In this post, I review the book Agile Application Security (by Laura Bell, Michael Brunton-Spall, Rich Smith, and Jim Bird), introduce some of its key ideas, and summarize why I found it so insightful.

This book guides software development teams on how to practically integrate security into their agile processes. I recommend it to two groups of readers: (1) information security professionals who want to learn how to more effectively deal with security issues in agile software development processes and (2) members of such agile teams who struggle with keeping their applications more secure.

Whether as a developer, an architect, a scrum master, a product owner, or an information security specialist – the book provides useful strategies and patterns for integrating security into DevOps.

Five of the Book’s Key Insights

While a broad range of topics is covered, here are five of the book’s insights that most resonated with me.

Most Security Processes were Built for Waterfall Projects

Why do we need another book on software security for software developers? Agile is not just a buzzword, it has completely transformed the way most organizations develop software. However, traditional security practices were built for projects following the waterfall model with up-front requirements.

Since requirements change rapidly in agile projects, security specialists can no longer plan and make decisions at the beginning of the project but rather need to continuously work together with the scrum team.

Their job is no longer to inhibit changing requirements (to reduce the risk of failing to notice security issues) but rather to become enablers (similarly to traditional operations departments in DevOps teams) by providing guidance, tools, and infrastructure to the application developers.

On the other hand, the transition to agile also means that each developer needs to take secure practices into account and the team shares full responsibility for the security of their application.

Test-Driven Security

Whenever a patch for a known vulnerability is applied (either by updating an external library or by fixing the own application code), most companies have no process to guarantee the vulnerability is fixed properly and won’t come back in future revisions. Here the authors present the concept of test-driven security (TDS): Similarly to test-driven development (TDD), TDS suggests that developers write (security) tests before fixing a vulnerability. This both ensures that the vulnerability is actually fixed (i.e., the patch or the source code change worked) and that the fix is permanent (since the tests are executed in each build pipeline).

Another benefit of TDS is that the security tests automatically document the expected behavior (e.g., “Verify that root login is disabled for SSH”) and can be reused in different projects. Mozilla uses TDS as part of their security processes and has published a very informative wiki article about it.

Pick Your Supply Chain Carefully

As is widely known, one major benefit of a microservice architecture is being able to pick the best tool for the job: each team should be free to choose the programming language, framework, and library they want to maximize productivity. However, from a security standpoint, this is problematic. As the authors point out, the attack surface of a software application increases with an increasing number of used libraries. While this can be handled to a certain degree by setting up automatic vulnerability scans in build pipelines (such as the OWASP dependency check or commercial alternatives), they still recommend reducing the number of external dependencies.

Finding a balance between the freedom to choose the best tool for the job and reducing the number of suppliers remains a difficult endeavor and was also part of a highly recommended recent talk by SBA research.

Get Security Into Requirements

“[…] no user is ever going to know that they need secure tokens at the session layer for CSRF protection – nor should they be expected to” – Agile Application Security, Chapter 5

This quote from the book perfectly sums up an important principle: It is our job as professional software developers – not the job of our customers or employers – to keep security requirements in mind and make them visible when designing software. The book suggests trying to convert the security requirements into user stories (“security stories” or “attacker stories”) to increase their visibility and to involve the whole team early on.

One specific resource that is recommended by the authors is the OWASP Application Security Verification Standard (ASVS) project. It lists common security stories for web and mobile software projects and can be used as a checklist (e.g., 33 items to verify when implementing a user login such as ‘Verify that all authentication challenges, whether successful or failed, should respond in the same average response time’). If you only take away one piece of advice from this book, let it be this: Skim through this 70 page PDF checklist and I almost guarantee you will find at least one thing to fix in your current project.

Security Tests – Manual versus Automatic

Since agile teams move very fast and embrace changing requirements, they heavily rely on automatic tests (preferably executed as part of the build pipeline). The authors argue that unit tests alone are usually not sufficient to detect mistakes impacting security because most such mistakes are caused by missing control or inaccurate assumptions.

Exploratory, manual testing is still one of the most effective techniques to catch security problems in your code. This can be organized in-house as part of the scrum team (where one or more developers are assigned the role of a penetration tester) or as part of an external penetration test – the important thing is that the code is regularly checked for security weaknesses.

However, security testing does have its place in CI/CD pipelines:

• Security-focused static code analysis
• Pre-commit scanning for secrets (e.g., https://github.com/awslabs/git-secrets)
• Scans for known vulnerabilities in libraries and container images
• Automated application scanning using tools such as OWASP ZAP

Summary

As someone recently tasked with improving the security practices in a scrum team, I found this book very useful as a starting point to dig deeper into the presented topics. It contains lots of actionable advice and links to other material and does a very good job of presenting the big picture of how a secure software development lifecycle may look like in 2020.