The big development project is almost ready to go live, inside the deadline. Just your security review to go. The development team swears they did what you recommended at the start of the project, so it should just be a formality.
But then your report comes back with pages of issues. The development team reviews them, and determines that there’s six months of work required to address them. The project budget is blown. The business doesn’t get to market in time. There’s fighting about who’s responsible between you, the development team, the project manager; no-one wins.
Finding a better way
First, we need to understand the problem. Security decisions are made by the development team as they build. Every choice they make has security implications. But a developer rarely has the security knowledge to make a good decision, and they can’t call for a security review every five minutes because there aren’t enough security resources. The only way forward is for them to make a possibly incorrect call and rely on it being caught at a later stage.
But with experience, we know that fixing an issue in the future is significantly more expensive than fixing it now.
A common example is database encryption. The developer who set up the database failed to set it up with storage encryption, so months down the track when you notice that, remediation is urgent. It’s a simple migration, but it requires a significant unplanned outage and now the database is slower, so the app—which was tuned for a fast database—needs weeks of re-engineering to meet the performance requirements.
If that had been caught at the time the original decision was made, when the app was still in development, it would have been literally a five-minute fix. Caught by audit when in production, it can cost hundreds of thousands of dollars. Aside from cost, the app was actually less secure, because of the unplanned risk exposure. Security bolted on is much less effective than security built in.
DevSecOps – more than just a buzzword?
But there is a solution - take inspiration from DevOps, build the right culture, and use the right tools.
The point of DevOps is to stop developers from throwing applications over the fence to operations, where they live or die by metrics the developers have no visibility or knowledge of.
The fix is to embed operations into development teams, whether by incorporating operations people, or by giving developers visibility into and capability with operations.
DevSecOps is the obvious next step. The cheapest, most effective security is achieved when it’s baked into the development process.
One way to achieve this is to embed a security person into each development team. This is good because it gives developers direct exposure to security considerations and thinking. But the problems here are:
Automating the process
A more effective way is to use a tool to add automated checks and boundaries which monitor changes to infrastructure and applications through the development process. These tools are known as Guardrails.
When developers strays from the secure path, they bump into the guardrail. While it doesn’t stop them from taking every little problematic action, slow down their daily work or frustrate them, it does stay at a higher level, periodically notifying them of issues that have arisen in their work. Once developers knows they’ve slipped outside best practice, they can fix it, and do so soon enough that the entire process is efficient.
More importantly, developers can also understand what they did wrong as a guardrail comes with targeted, real-time feedback. It’s a very effective way to build awareness and capability throughout the development teams, without needing hours of explanation from your security team.
You just need to invest some time in setting up and maintaining the guardrails so this process allows the efficiency of centralised security expertise with localised communication. This makes you more secure and more agile for less money.
Article by Dave Slutzkin, General Manager, Stax.