Software must be developed quickly. The market won’t wait. Software must also be secure because a vulnerability could kill, or at least seriously wound, the business. Companies struggle to reconcile these two seemingly opposing priorities. So when it comes to software development, the question becomes: who owns security? Although the feel-good answer is everyone, it’s a dangerously ineffective one.

Consider this. If everyone in your household were responsible for taking out the trash, who would end up doing it? Probably no one because, in practice, “everyone” becomes “someone other than me,” which results in no one at all. Not to say you shouldn’t enable security fluency throughout the organization or share accountability across teams. But you do need to establish clear ownership of this role while providing the appropriate level of accountability and support to make it happen.

Who should own security in the SDLC?

Today, most people think developers should own security. A study by GitLab found 69% of developers say they’re expected to write secure code, and a survey by Snyk reports 81% think developers should own the security of their application code. There seems to be agreement. But there’s a problem—several, in fact. 

First, ownership doesn’t automatically guarantee execution. Snyk discovered 37% of users don’t implement any sort of security testing during CI, and GitLab found 49% struggle to get developers to make remediation of vulnerabilities a priority. Execution requires accountability, but according to GitLab, nearly 44% of developers say they’re not judged on their security vulnerabilities. 

Second, ownership doesn’t automatically create competency. The GitLab study reports 68% of security professionals feel less than half of developers can actually spot security vulnerabilities. To ensure competency, you need to provide the right training, support, tools and data to build security into the development process.

Still, not everyone agrees developers should be responsible for security. You could argue development and security are different specialized skills. On the coding side, there’s really no such thing as a generic “developer” who does it all. There are different kinds of development: front-end, back-end, mobile app, database, embedded, the list of specializations goes on and on. Each type works in their own languages and tool sets. You can’t just plop a web developer who lives in Ruby on Rails or Django into a back-end project and expect them to develop an Oracle database. By the same token, you can’t ask a developer to take on the highly specialized knowledge and skills of security. 

Are we even asking the right questions?

Perhaps a better question is how do we effectively make security a priority across the SDLC? As businesses started to realize fast and high-quality development must be a priority to stay competitive, they didn’t ask who owns speed to market. That said, they did adopt a DevOps model to bring together teams, tools and processes to infuse the development process with operational agility. It’s a coordinated collaboration, not a dumping of responsibility from one group to another. Similarly, DevSecOps is about adding security into that mix. 

The path to successful DevSecOps

DevOps required organizational change, and so does the move to DevSecOps. But like any meaningful transformation, there’s no one single thing that will get you there. Businesses successfully employing DevSecOps have gotten the following right:

  • Mindset and culture: Developers, and the organization as a whole, need to change their security mindset from an obstacle to a way of doing business. To do this, you need to build security into your organizational culture and language so it becomes naturally ingrained. 
  • Training and support: While you don’t need your developers to become security experts, you do need to help them build secure coding skills. And you need to provide them resources which put security in their language and context, rather than forcing them to learn how to “speak security.”
  • Processes and tools: You need to embed security throughout the development process across the entire SDLC. Where you need developers to take action, make it easy for them to do so. Automation is key here, as is the ability to correlate results across tools and consolidate units of work. You need to use the right tools across the entire software lifecycle. For example, your developers probably don’t have the time or skills to review open-source code for security, so use SCA to check code dependencies. Developers can scan code as they write it with SAST tools to provide immediate feedback on vulnerabilities. DAST scans can find certain vulnerabilities in deployed code. And you need to be able to scan your container and cloud environments. Finally, you need orchestration, which is the consistent selection, on boarding and management of the tools you need to run an effective software and infrastructure vulnerability program. 
  • Accountability and governance: Include and track relevant security metrics in KPIs for the company as a whole, using appropriate role-based metrics to drive the right behavior throughout all of DevSecOps. And build security into your overall risk management strategy, with visibility and transparency to track compliance and communicate consistently to all stakeholders.  

Security can’t effectively be owned by a single entity, either benevolent overlord or dictatorial taskmaster. Instead of asking developers to own security on their own, help each member of the DevOps team own the portion of security that’s relevant to their specific role. Give them the support and means to do so. And make security sure remains one of their most important accountability outcomes.

Share This