Developer Velocity & Security

COMMENTARY

When it comes to making a difference to business performance, chief information officers (CIOs) are investing in application development and improvements to software. According to Gartner, 60% of companies plan to spend more on software, with 52% of companies increasing their spend on software to improve productivity. Analyst firm Omdia points to modernization and investment in applications as a critical goal, due to the cost of maintaining existing technology stacks over time. 

For chief information security officers (CISOs), these investments represent a significant challenge. How can you keep up with the relentless pace of change taking place, where new IT infrastructures are created, used, and torn down every minute, every day? One CISO I discussed this with described it as like trying to dam a river — impossible to achieve, a thankless task, and one that leaves you considerably more uncomfortable than when you started. Worse, trying to impose standards left them feeling like the “department of no,” and antagonistic to the business’s overall goals, affecting their internal standing and making them more likely to be ignored. 

So, we can’t go against this pace of change. Instead, how can we understand developer velocity and the goals that these teams have? How can we get ahead of these changes so we can apply security at the source, and what is in that approach for us? 

Starting at the Beginning

Understanding the software development process in your organization is a good place to begin looking at how you can insert security measures into the mix. How do those teams manage their requests, requirements, and changes over time, and how does their life cycle work? How do those teams work faster and more efficiently, and what steps are they taking to improve their performance?  

For CISOs, each phase in the software development process is a potential place to insert security into the conversation. Yet many developers are wary of security asks. The reason for this? Security often gives them huge volumes of change requests, with no guidance beyond “This needs to be fixed.” This can lead to resentment at the additional work, as the business is already asking them to deliver new functionality or services. 

To improve this situation, look at the overall goals that all the teams involved have to deliver on, and what information can directly benefit them. Developers want to build, and the business wants those results as fast as possible. For CISOs, the guidance here is to enable that pace of change, or at least get out of the way. To make this work in practice, security teams must look at what they can automate so that it delivers security results directly into the developer workflow. 

Developers themselves live in code. They don’t want any manual tasks in their processes, let alone in processes that are dictated to them by outside teams. To get over this hurdle, put your security approach into that code workflow so that it gets applied by default to any part of the development environment within those tools that are already in use. A security defect can then be flagged for fixing to that developer in the same way as a code component not compiling properly, or an API integration failing.  

Moving Up the Stack

The security sector has been keen to promote more secure development and design practices in software. The promise here is that fixing issues earlier in the process is cheaper in the long run than doing so later in the process, whether that is in production or in later test and deployment phases. The secure-by-design mantra is brilliant in theory. However, developers are moving so fast that this framework will be hard to apply and keep up on its own.

Instead, we must treat software security as a methodology. We can still support developers in making changes as fast as the business needs, let developers know about issues, and then try to fix those problems before they hit production. However, that is not enough on its own. One CISO in France let me know that he had successfully implemented security checks and controls for the company’s containerized applications only during the build phase. In theory, this would mean that any image developers deployed should be secure through into production without the requirement for checks in later stages. Yet his team members found that they still faced problems in production, and vulnerabilities and misconfigurations were still occurring. The issue was that those containers would drift over time, where they would then need to be remediated, or as sometimes happens, the risk is accepted and those images are in run time with known issues.  

This is where CISOs can come into their own — by providing context. Articulating risk in context to the business as a whole, or to specific platforms or departments, allows development teams to prioritize their activities. Additionally, it empowers teams to continuously improve their coding practices and build more secure applications faster. Security teams are then only providing guard rails versus slowing down developer velocity — security can then get out of the way, while still reducing risk and putting remediation efforts where they are needed. The end result? When the CISO really needs to communicate around risk, the rest of the business is more likely to pay attention.