Resolving who actually owns security in agile development

Register now

For any company that is developing software, there is a constant race to meet tight deadlines for new releases. The advent of the Agile development model, with its emphasis on speed, has only added to this sense of rushing through the process — at times to the detriment of the product.

In order to keep up with demand, developers scramble to write code by pulling together the pieces from their own proprietary written work and a host of third-party software including open source components. From their standpoint, they could throw together a product made out of Popsicle sticks and Elmer’s glue so long as it works. Security is someone else’s problem, right?

On the other side of the divide, security teams are often made to feel feel like wet blanket bureaucrats who are viewed as bottlenecking releases with security reviews and changes before the product can make it out the door. All of the responsibility is thrown on them, usually with frustrating results that lead to significant and downright unnecessary friction in the Age of Agile.

In the old days of the Waterfall methodology, the linear structure acted as more of a funnel where all of the code would only arrive at the testing stage at the second to last stage before release and maintenance. Most folks now agree that this approach is fairly short sighted, and they prefer the Agile development style that is more cyclical and comprehensive.

One of the key issues that comes up in the discussion of how to add security in Agile development is concerns over the friction that can arise from confrontations with the developers. To understand how this friction occurs and how to prevent it from turning into a blazing fire when the two side rub up against each other, it is important to understand the dynamic of how resources and personnel are allocated, as well as where responsibility for the product is placed throughout the SDLC.

Allocation of resources: overcoming impossible odds

Think first about the ratio of developers to DevOps to security personnel working on a given project.

Traditionally, we think about this as the 1:10:100 problem, wherein there is one security person working with ten DevOps team members, who themselves are managing the code that is written by a hundred developers. Whether or not these numbers are an exact fit for your organization, the basic fact that a small number of people bear the brunt of getting the high-quality and secure product out the door remains true across the board.

As we know, the developers’ main focus is getting a working product out the door as fast as possible, while the security folks want to reduce the chances that the product will contain vulnerabilities.

Ideally, the developers would be able to code without any interruption or inference from the security folks. However, since developers are only human, there will always be flaws in the code that they write themselves, as well as issues in the code that they take from third-parties like open source repositories from sources like GitHub.

We know that it is cheaper in terms of time and money to catch and fix vulnerabilities early in the process rather than later, especially when your developers have built more features on top of imperfect code. Moreover, we see a bottleneck occurring when security issues are left unaddressed until a short while before release (when stress levels are particularly high).

So how do you actually catch these issues at an earlier stage when the security team, with their more limited human resources, is only designated to step in at the end to review the code?

Sharing the load: using the right tools for the job

The answer here would appear to be twofold: focusing on shared responsibility and automated tools to help alleviate the pain of enforcing strong security policies and practices throughout the SDLC.

The responsibility for securing the product should not fall only on the security professionals. Instead, it should be a shared effort across the teams, starting with the developers who write the code, the DevOps ninjas who kick production into high gear, and all the others who have a hand in getting the product out the door.

Taking into account our distribution of resources, with the security team having the largest load to smallest team ratio (remember our 1:10:100 arrangement), the only way that they can actually be successful is by using automated solutions that shift left security from the earliest stages of development, allowing for comprehensive security from start to finish.

Application security testing tools like Static Application Security Testing (SAST), Dynamic Security Testing (DAST), and others are essential for checking the proprietary code that is written in-house, using a set of rules to find flaws. However, for the open source components, which can make up to 80 percent of your product according to Gartner, you need a different kind of solution.

The biggest threat to open source components are known vulnerabilities, which are found by members of the open source community and posted to public databases like the National Vulnerability Database (NVD). From here, security teams can see which of their components are at risk of being exploited.

The problem is that hackers can also follow this list and know which components are vulnerable and how to carry out the exploit. This saves them the work of having to find the flaws on their own. They will not even bother looking for vulnerabilities in this code, already having enough material to get them to an impressive payday. All that’s left is for them to try and find those organizations that have been too slow to patch on their own.

This is where an automated Software Composition Analysis (SCA) tool can play a crucial role in your security. These tools detect all of the open source components in your inventory and products, providing you information on important points like whether they are vulnerable, which license they are listed under, and even notes on their quality. This empowers the developers to write more secure code, giving them a sense of ownership over their product’s security without the security team looking over their shoulder.

Running continuously, SCA tools can alert you not only when a new vulnerability is discovered in one of the components in your products, but also even before it is committed to the build. Policies can even be set by the organization to fail a build if a developer attempts to incorporate an open source component whose security severity violates company policy.

Having an SCA tool can implement security from the very beginning of our SDLC, all without involving direct intervention from the security team or shouting matches in the lead up to a release.

For reprint and licensing requests for this article, click here.