What is DevSecOps? (and DevOps)

Imagine you’re overseeing the construction of your dream mansion.
But at the last minute the planning officer comes round and says, “Nope, this doesn’t meet our planning standards. You’re going to have to rebuild the pool and the kitchen”. Suddenly, chaos and delays are the order of the day as you scramble to meet these last-minute requirements. You’re going to have to cancel your housewarming pool party!
Yet, this is the situation that many product owners find themselves in when it comes to security requirements: they oversee the construction of these beautiful code mansions (i.e. revenue-driving applications) that are then forced into sudden changes at the last minute by the enforcement of unforeseen security standards.
These eleventh-hour blocks prevent product owners from doing their jobs effectively in a number of ways:

• Delaying or cancelling releases – Security issues can stop products from ever being launched. In 2020, unsuccessful development projects in the US cost $260
• Spending resources fixing defects – Businesses must forego developing new features/products to fix security problems, which cost US businesses $607 billion in 2020.
• Lowering productivity – Poor security means the average developer spends 33% of their time addressing technical debt!

(Statistics according to the Consortium for Information & Software Quality).
Security is often overlooked in the product lifecycle, resulting in these wasted resources and missed opportunities. Yet, this doesn’t have to be the case. If product owners can build planning requirements into their dream mansion upfront, the ROI is significant. In one study by Forrester Research, shifting security left in the development process delivered an ROI of 205% over three years, with a real dollar return of almost $7 million on a $3.3 million investment.
In this blog, I’ll explore why security ends up being overlooked and how product owners can instead embed it in the product lifecycle to build better products that can be released reliably and are easier to maintain.
Why Product Security Is Different
The root issue is a conflation of two different kinds of security and—as a result—a cascade of mismatched incentives and accountability structures that force product owners to push security to the bottom of the priority list:

• The first kind is IT security, which involves securing email, devices and so on across your entire business.
• The second is product security, which involves making sure that the code engineers write is free of bugs and vulnerabilities.

These are typically lumped together, with the CISO and their security team having ultimate accountability for both. The problem is that, while the CISO and their team are accountable for product security, they have no direct control over what the fast-paced engineering teams are doing. At the same time, the product owner is the one who has the on-the-ground responsibility for the code that is being written, yet they are not held accountable for the security of said code.
So as the product owners are responsible for product security but not accountable it naturally slips to the bottom of the priority list. And the security team is accountable but not responsible, so they have no way of doing their job effectively!
You see the problem: the wrong people have been tasked with doing product security.
The CISO’s security team and the product owner’s engineers are working independently in separate siloes, with different incentives and goals. In this context, security becomes an ivory tower activity that runs parallel to software development, rather than something that is built into it.
As a result, the security team can only do their job by taking on the role of gatekeeper, enforcing standards when the product owners are ready to launch. Just like the planning officer stepping through the door of the dream mansion at the last minute.
So how can product owners ensure that their dream mansion doesn’t have to be rebuilt at the eleventh hour? And avoid racking up additional costs, delays and reputational risk?
Building Security Into Product Development
The most important thing to grasp is that product security is a software engineering problem
It can no longer be run in parallel to the engineering work, but must be embedded firmly in the product development processes themselves.
As a product owner, you are accountable for the security of the work you produce. And this is great news! Security is an important aspect of product quality, which can help you to build better products that can be reliably released and more easily maintained.
Here are three ways you can change how you work to move in this direction:
1. Build security where you have capacity
You need to build your security where you have capacity to do so: in your engineering team.
In an enterprise organisation there is, on average, only one security professional for every 100 software engineers. How can that one person possibly resolve the bugs those engineers produce? It’s simply not scalable.
Instead, your development teams need to know how to manage the security of their systems themselves and live and breathe that in everything that they do.
2. Align incentives, accountability and responsibility
In order to achieve the first point, you must deeply rethink how incentives, accountability and responsibility around security work in your organisation. Without this, there is no hope of delivering effective product security!
The high level security and governance standards need to be arranged in such a way that your engineering teams are responsible and accountable for product security—as well as given the tools and autonomy to make sure they can execute effectively.
3. Help your people to improve gradually over time
The key is to continuously improve product security, step by step. Ask yourself: how can we build our product in ways we know will make it secure?
Every bug or error that is found should kickstart a chain of activity that results in the next feature being built in such a way that it is impossible that that bug could be found again. View any security vulnerability you find as a failure of process, not of engineering. Then rework those processes so it can’t happen again.
In this way, you improve the foundation of your product development processes over time to make them more and more secure by default.
Final Thoughts
As a product owner, you don’t need to cancel your proverbial pool party.
By reorganising how you think about security and embedding it into your product development processes, you can avoid serious headaches and even deliver better products with greater ROI.

‍

‍