How to repair the painful disconnect between security and product teams
There has always been a monumental disconnect between security and product teams.
For most aspects of product quality (functionality, reliability, scalability and so on) there is very little separation between those who are responsible for fulfilling each aspect (developers) and those who are accountable for it (product owners).
Yet, despite being a core aspect of product quality, security has always existed as this separate, siloed function, estranged from the rest of the product delivery process.
And this fundamental separation creates a lot of costly dysfunction for the business and headaches for both sides.
In this blog, I will be exploring how we can repair this painful disconnect and create a strong, efficient and successful relationship between them!
I’ll be covering the following issues:
- The ways in which security and product are disconnected
- The business consequences of that disconnection
- What a healthy relationship would look like
- 3 steps to repairing the relationship
- The business impact of connected product and security functions
How are security and product disconnected?
There are a few major ways in which this disconnect manifests.
- Boundaries: there is a misalignment between responsibility and accountability
The security team is accountable for product security, i.e. their success is judged by the (in)security of a product. But because they are isolated from the product developers, disconnected from the context of the code and often not skilled developers themselves, they can’t take any responsibility for it. They can only point out problems from afar.
The developers are responsible for writing the code, and so in effect are responsible for the quality of that code but, while the product owners are accountable for the developers who should be writing secure code, they’re not actually accountable for the security of that code (the security team is!)...so naturally it falls to the bottom of their priority list.
The result is that security is often begrudgingly shoe-horned into the product as a last-minute requirement to get it out the door.
- Communication: they don’t speak each other’s language
Security and product teams speak different languages.
Developers live and breathe code, while the security team communicates in the abstract language of security standards. Neither knows how to translate the one into the other effectively.
So when the security team produces a giant PDF of security requirements that must be met before the product can go live…the devs have no idea what all the ‘security speak’ means in terms of their actual code.
The same is true of most security scanning tools which produce reports made of a mish-mash of product and security speak, including security jargon the devs don’t understand and some code snippets the security team can’t decipher.
- Metrics: they can’t agree on what ‘good’ looks like (or how to measure it)
The communication disconnect also makes it incredibly difficult for anyone to agree on—or measure—what ‘good’ security looks like!
If the developers go back to the security team and ask “what do I need to do to meet your requirements?”, the security team just don’t know what needs to be changed in the code.
- Expectations: they have different goals.
When responsibility and accountability are misaligned, the teams end up working towards different goals!
The developers will prioritise getting things into production faster, while security is slowing things down by trying to ensure there aren’t any vulnerabilities.
The business cost of disconnection
Essentially, product and security teams are pitted against each other. They are working in separate functions, towards different goals and timelines, with different priorities, using different metrics, while speaking different languages.
The result is that product security is left stranded in no man’s land.
The product teams aren’t accountable (and are busy enough as it is!), so they will leave it to the bottom of the priority pile. And the security teams can only find problems and dump a big list of incomprehensible security requirements at the developer’s door.
In practice, what ends up happening is that developers—uncertain how to turn those security requirements into actual secure code—end up Googling a bunch of last-minute hacks to get their product through the door.
They aren’t writing high-quality, secure-by-default code.
Which means product quality suffers, with the resultant business costs: delays to product launches, fines from regulators, customers ditching your low-quality product in disgust!
What would a healthy relationship look like?
The disconnect can really be seen when we contrast the product/security relationship with the Site Reliability Engineering (SRE) model.
An SRE function supports the product team by acting as a dedicated ‘run’ team. The devs can build/upgrade the software, while the SRE team keeps it ticking over.
The relationship works because, in this setup:
- Boundaries: there are clear boundaries in terms of who is accountable for what
- Communication: they are speaking the same language (code!)
- Metrics: there is an understanding of what ‘good’ looks like (SLOs) and common metrics for measuring it (SLIs!)
- Expectations: there is a prearranged contract that sets out expectations and goals.
They are fundamentally connected and, as a result, the SRE team is a really helpful support for the product teams.
However, the security function as it currently exists does not support developers in this way. It’s more of a last-minute checkbox-enforcement squad, which hinders developers from doing their job!
How do you repair the disconnect?
At the highest level, your company as a whole must grasp that security is not separate from product development.
Security is an intrinsic part of how you build a high-quality product and must be embedded in your product delivery process.
Here are three steps you can take towards making this a reality in your business.
- Product owners and teams must become more security-oriented
Product owners must take full accountability for product security.
That will mean educating themselves so that they know the level of security required for their product. What does secure enough look like?
Their task is then to ensure their developers know that they are responsible for attaining that level of security. At the same time, POs must give development teams the extra space to take on that responsibility. They cannot demand extra work while expecting the same output.
- The security team must become more developer-focused
The security team must learn to live in the world of the developer, taking on their language and customs!
They must radically upskill themselves so they can understand app security in the context of code, set clear (and actionable) requirements and help developers write and test secure code.
This involves a shift from an ownership mindset to a mentorship mindset. Rather than pointing out problems from afar, security professionals need to roll up their sleeves and get stuck into the code alongside the devs!
- Create a ‘Product Security Engineering’ team
The relationship between product and security should be analogous to that between dev and SRE.
The kinds of conversations that SREs have with devs must be mirrored with security: setting clear requirements, planning product requirements with security in mind, bridging skill gaps, putting clear metrics in place, embedding security requirements into automated testing and so on.
For example, where your SRE team has Service Level Objectives/Indicators, you can put in place Security Level Objectives/Indicators.
Your Product Security Engineering (PSE) team could function either as a cross-functional team (i.e. product security gurus embedded in development teams), as a separate function as in the SRE model, or it could even be the SRE team, just taking on the security mentoring roles too.
The business benefits of connection
When product owners take full ownership and accountability for the security of their product, security teams are more like AppSec gurus and they relate to each other within a clear, boundaried context (the PSE function), there is a massive improvement in the relationship.
Security is returned from its exile and the two sides are supporting each other in a virtuous circle, rather than being fundamentally at loggerheads.
Suddenly, the security professionals are speaking the language of the developers, giving them clear, actionable requirements and helping them to make those changes to the application.
At the same time, those developers have the support from their product owners to dedicate time to write high-quality, secure-by-default code!
The business impact of healing this relationship is substantial:
- Improvement in DORA metrics:
The PSE team can define and measure what ‘good’ looks like, identifying security threats to rapid delivery and dealing with them early
- Higher-quality products:
By embedding security into the development process, product quality goes up, resulting in fewer delays, fines and compliance issues - Happier product/security teams:
Developers that are being supported to deliver security are happier than those that are having it foisted on them as a last-minute burden and security have more fun when they’re not the ‘department of ‘no’’
- Greater developer productivity:
When there’s less conflict in the delivery cycle, products get delivered better and faster!
