Organizations today are taking great strides when it comes to innovation, but unfortunately security and governance continue to lag behind. One recent study revealed that, although the DevOps ratio is now 10:1, the DevSec ratio is still 100:1. We need to understand what’s causing this gap and what actions we can take to bridge it.
Earlier this year, Sonatype put together an article looking at what enterprises can do to bridge the gap between software developers, IT operations, and security. We’ve summarized their thoughts here, but we encourage you to read the full article if you would like to learn more.
Understanding the Gaps in Dev(Sec)Ops
It’s important to reinforce that day-to-day security measures like checking for third-party vulnerabilities and responding to incidents aren’t the cause for concern. Instead, where voids tend to appear is with things such as hacker mindsets (proactively searching for new possible attack vectors) and in performing tasks like in-depth risk analyses and threat models, all of which play key roles in enabling enterprises to create robust, holistic security architectures.
Two Models for Addressing the Problem
1. Fully Shared Responsibilities
This framework calls for each development team to integrate at least one T-shaped individual (someone capable of many things and an expert in one) who specializes in security. This person needs to be able to translate security threats into actionable items that their team can implement and communicate concerns in ways business owners and leaders will understand.
Keep in mind that the security-focused person shouldn’t be allocated all of the security work otherwise the silo will simply be transformed from a macro one (where there’s a distinct security team) to a micro one (where there is an isolated team member). Over time, the job of doing security analyses should be spread throughout the team so that the T-shaped person can stay on top of best practices, find new tools and methods, facilitate workshops, and ultimately lead security strategy.
Pros |
Cons |
|
|
The Final Word
A fully shared responsibilities model is often ideal for companies with cross-functional, autonomous teams that each work on products or services with very different risk profiles. Spotify is one of the largest and highest-profile companies to have adopted this approach.
2. Security as an Enabling Team
In this model, a central security team supports multiple product development teams, getting involved from day one of a project to make sure they can provide security-specific feedback at each stage of the process. An important caveat here is that the security team shouldn’t actually perform analyses or implementations. They should simply promote best practices and provide guidance on which other teams can act.
Switching to the security-as-an-enabling team model can sometimes be an easier transition for enterprises because it doesn’t require the same degree of structural change that a fully shared responsibilities model does. Ultimately, the biggest challenge with this approach tends to be making the shift without confusion or regression.
Pros |
Cons |
|
|
The Final Word
This approach works well for companies that have a smaller number of teams to begin with, especially if those teams (or members of them) have a pre-existing interest in security. Enterprises that have taken this approach include Sportradar.
Evolve Teams to Suit Changing Security Needs
Remember that team design shouldn’t be static. The best fit for you today might get in the way of better, faster developments tomorrow, which is why you need to be prepared to adapt as your organization grows.
About iTMethods
iTMethods helps companies accelerate software delivery capabilities through their Cloud-native DevOps SaaS Platform. The Enterprise SaaS offering features a toolchain catalog comprised of best-of-breed DevOps tools including CloudBees Jenkins, Github, Atlassian, Sonatype, and many more. These tools are deployed to each customer’s specific requirements, including security, scalability, and 24/7 customer support.
Read more from iTMethods: