You are here

You are here

Bridging the Development-Security Divide

public://pictures/ofungwu_0.jpg
Francis Ofungwu Global Field CISO , GitLab
Photo by krakenimages on Unsplash
 

The good news: GitLab's 2022 DevSecOps survey found that 70% of DevOps teams surveyed release code continuously, once a day, or every few days, a figure that is up about 11 percentage points from last year.

Even more good news: The survey also found that security was the No. 1 investment area for survey respondents for 2022.

Now for the bad news: A trend of misalignment between security and development teams persists. In this DevSecOps Survey, over half of the respondents said that security is a performance metric for developers within their organization; however, 50% of security professional respondents reported that developers are failing to identify security issues, with roughly 75% of vulnerabilities being left for security professionals to find.

This isn’t new information. When GitLab conducted the same survey two years ago, several security-team members reported that developers didn't find enough bugs early in the process and that they were slow to fix them when they were found. Additionally, that survey found ongoing confusion over who in the organization was responsible for security.

This misalignment is most apparent on a tactical level, but security and developer priorities start to deviate from one another long before the first line of code is even written. Most organizations understand the importance of security but fail to create the conditions that allow for true cross-functional collaboration—and better security—throughout the organization.

There are a few ways, though, that organizations can better align developer and security teams at the start of the software development lifecycle (SDLC) to reduce downstream tensions—without relying on tooling and expensive risk assessments.

Aligning Metrics and Incentives

Currently, many organizations give their developers and security professionals conflicting priorities. Developers are incentivized by the speed at which they release new features; security professionals, on the other hand, are incentivized to reduce risk—which may mean slowing down delivery activities to better understand threats and the organization's exposure. The two teams will inherently remain at odds so long as their goals and key metrics are not aligned.

To achieve better collaboration between these teams, they must engage early to agree on nonfunctional requirements in the design phase and acknowledge the need for tradeoffs. For example, both teams can agree that a failed security scan does not mean a failed pipeline and lost productivity—and should consider a risk-based approach to apply context to failed scans, as well as triage vulnerabilities based on other mitigation measures.

Building Teams

Organizations should examine whether their security teams have the skill sets to understand and manage risks in the development environment. Security-team members should hold a range of qualifications—including knowledge of and experience in software development, secure-coding techniques, and more dynamic security testing. Having a team with diverse backgrounds can be critical to building a security program that enables and supports developers in building secure products.

Because finding and keeping security talent continues to be difficult, organizations should evaluate how much time teams spend on caring for and feeding security tools—and determine if this is the best use of scarce resources. Consolidated and managed platforms can help free up security-team members to become better partners to the development teams—and to spend more time in the design and operations phases of the SDLC.

Assigning Responsibility and Expectations

Every organization that uses or relies on software likely wants to deliver software faster to keep up with the speed of the market. It only takes one security incident, however, to overshadow even the most efficient development team. Thus, security is a key component of quality software; it must be a team effort.

Software development is a rapid process; some new attack vectors and vulnerabilities in dependencies are only identified after deployment. Organizations that are misaligned need to realign expectations and support at all levels for developing a secure product. Security teams must realize that there will always be vulnerabilities that get to production.

To keep the number of live vulnerabilities to a minimum, security teams should make an ongoing effort to provide developers with the tools and data needed to identify vulnerabilities as early as possible—especially those vulnerabilities that are seen repeatedly. The policy for handling these vulnerabilities as they are identified should also be documented. That way, every team member has access to these best practices, and expectations are clearly defined.

For engineers, it's important to continue prioritizing security throughout the development process because security is a critical part of building trust with customers and other stakeholders. Developers should be incentivized to help security teams by identifying and flagging areas of concern, asking questions, and helping security-team members understand the code being written. Teams should also implement a single DevSecOps platform to develop software so that all internal stakeholders can communicate priorities and key areas of measurement while having a single source of truth for reference.

The demand for faster deployments is only going to increase—and, along with it, the scrutiny faced by individual organizations to keep all products and information secure. We've all heard that every company is a software company, but in order to survive, it is imperative that each company also focuses on security.

The misalignment between developers and security is not sustainable for any organization that wants to continue delivering software efficiently without compromising security. Let's rethink how these teams can work together, create new workflows and organizational structures that enable better cross-functional collaboration, and close the developer-versus-security divide for good.

Keep learning

Read more articles about: DevOpsSecure DevOps