Software makes the world go round today. A decade since Marc Andreesen famously stated that ‘software is eating the world,’ the demand for code to deliver services and automate processes is only increasing. The advent of the COVID-19 pandemic forced companies that had not ‘gone digital’ to invest, while those that already ran online doubled down.
As part of this, approaches like agile development and DevOps helped. From focusing on shorter timeframes and smaller amounts of development to keep up with business demands, through to developers taking on responsibility for IT operations and running what they build, the software development team has increased the amount of the development process that it owns. In effect: “You build it, you support it.”
However, security is often an afterthought in this process. In a rush to get more done, security can fall down the list of priorities. Despite the availability of best practice guides for secure software development from the National Cyber Security Centre and OWASP, getting security considered during the development pipeline can be difficult. To solve this problem involves looking at data, responsibility and changes to processes.
The first area for change is data. Today, software developers are involved in projects that rely on data to solve customer problems, yet how many of them use this information in their own workflows? There has been a massive increase in observability projects, where developers use application logs, metrics and tracing data to understand performance, but this data can be used for security as well. Done in the right way, this can actually help consolidate tools and data captured, so the organization does not have to pay twice for each team to capture data and analyze it.
This approach to data can go further, too. Just like software developers create systems that build on and use data to improve customer experience, they can take information from their own software pipelines to improve their processes around both development and security. As software projects move from coding to test, deployment and production, they generate data that can be captured and used over time. The problem previously was that processes did not put that data to work.
"Alongside the data, IT teams at organizations have to look at how they think about security from beginning to end"
For some teams, this is the problem of the cobbler’s shoes, in that they spend so much time working on other teams’ requirements around data that they don’t have time to prioritize their own needs. The other problem is that there are so many different pipelines to track – software development teams can have a lot of freedom to choose the tools, services and cloud platforms they use, so there is less standardization in place for what is deployed over time. It is therefore essential to get all that data into one place, so it can provide insight into what is going on across all the pipelines that are running concurrently.
Alongside the data, IT teams at organizations have to look at how they think about security from beginning to end. Security has to shift left and take place earlier in the process, but this requires the right mindset across all the teams involved. For example, are you incentivizing security in your process from the start, and how do you measure this? The right metric can be enormously effective in promoting good quality secure code at the beginning, while the wrong metric can lead to more problems over time. As anthropologist Marilyn Strathern observed, “When a measure becomes a target, it ceases to be a good measure.”
Instead, security and development teams can collaborate on improving the process, from thinking about security as part of process design and code development to preventing issues like misconfiguration in deployment. This includes allowing more time for code review, using code analysis tools, and mandating that rules on secure coding are followed. For example, this could be by tracking code developed over time and – rather than measuring by lines of code generated – looking at numbers of security issues prevented and solved.
Developers and security teams already use data to meet their goals. However, looking at this in context can help every team improve their results, consolidate their tooling and collaborate more effectively. By looking at security, development and DevOps as a whole, then setting up the right goals and metrics, teams can incentivize the right kinds of behavior rather than concentrating on specific targets. In effect: “You build it securely; you all support it effectively.”