Understanding the Gaps in Your DevSecOps

Organizations today are taking great strides when it comes to innovation but unfortunately, security and governance continue to lag behind. Although the DevOps teams ratio is around 10:1, the average DevSecOp ratio is only 100:1. A recent study shows that organizations who prioritize DevSecOps are 3x as likely as their peers to use security as a way to speed up application delivery.

We need to understand what’s causing this gap and what actions we can take to bridge it.

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.

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.

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.

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. 

Conclusion

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. A fully managed platform maximizes the internal team’s ability to focus only on the core business, and in most cases also results in a more secure DevOps toolchain, because responsibility for security is with the platform provider, not an internal IT team trying to do hundreds of other things. 

Why do Enterprises Trust Our Managed DevOps SaaS Platform?

Managed SaaS Model