Shift Left: How Security Pros Should Prepare Developers for DevSecOps

Moving from a traditional approach to security — we might call it the “roadblock” model, where security teams block applications from deploying due to security issues — to a DevSecOps approach requires a dramatic shift in how organizations manage security and how they define the responsibilities of all the stakeholders in the engineering organization. In addition to changing day-to-day responsibilities, many organizations moving towards DevSecOps add new roles to help bridge the gaps between development, operations, security and executives.

Here’s how roles change for developers, operators and security professionals as organizations move towards DevSecOps.

The Security Pro

The role of security professionals in a DevSecOps model is dramatically different from traditional approaches to infosec and application security. Instead of personally evaluating how secure an update or new application is, security professionals in DevSecOps organizations are internal consultants whose main responsibility is to help give developers the tools and training to deploy secure code on their own.

Security teams’ responsibilities in a DevSecOps world generally include creating or selecting tools that developers and operators can use to either catch security issues early in the development process or to respond to security incidents in runtime. They set policies and determine security strategy. “They are also an escalation point for cases the require deeper expertise,” explained Guy Podjarny, founder and president of cloud native security company Snyk. “They should be a governing body that the organization as a whole and different teams individually are operating in a way that keeps the organization secure.”

The role of security professionals in a DevSecOps model is dramatically different from traditional approaches to infosec and application security.

“The internal consultants should have a decent understanding of the different pieces in the DevSecOps stack,” explained David Widen, director of training at DevOps consulting firm BoxBoat. “They have to figure out how to treat DevSecOps as a product or a service that can be used by all the different teams affected.”

The career path for security professionals has also changed. Particularly as security shifts left, it is becoming increasingly important for security professionals to empathize with developers. Whereas traditionally the path into infosec came through operations, an increasing number of security professionals have a background in development. Regardless, being able to understand developers, including what is hard and what is not, is a critical skill for any security team in a DevSecOps organization.

The Developer

According to this report from Logz.io, about 63% of DevOps engineers consider themselves and their teams responsible for security, while only 31% of developers consider themselves responsible for security. DevSecOps does dramatically shift responsibly for security to developers, however, by including security in the feedback loop that developers are expected to address during the build/test phase.

“Now, a developer does a code check-in and there’s some piece of automation that tells the developer sorry, we agreed on this piece of code can not go into a repository, can not go into production,” explained Loris Degioanni, chief technology officer and founder of cloud native security provider Sysdig. “It’s completely impersonal. It’s the role of the developer to find this kind of stuff and fix it automatically without a security guy telling him to.”

This could be perceived as more work for the developer because there are more things to address during the build/test phase. On the other hand, there’s no release day stress when a security professional blocks the release because of a vulnerability the developer didn’t know existed. In addition, DevSecOps relies heavily on automation, so the actual manual work that developers have to do to ensure secure code should be minimal. In fact, one could say it’s the security team’s job to make security as easy as possible for developers. 

The System Administrator and the SRE

In the same report from Logz.io, 54% of system administrators and 54% of SREs considered themselves and their teams responsible for infrastructure and application security. “Ops were traditionally the ones most aligned with security, and had to apply and operate a lot of security in their day-to-day business,” Podjarny said. Indeed, of all the roles in DevSecOps, that of the system administrator and SRE are probably changed the least, because most of the changes in workflow related to the interaction between code development and security checkpoints rather than infrastructure and runtime security.

New Roles

Adopting DevSecOps also involves creating new roles within the infosec organization. One idea is to create a security champion who can bridge the gap not just between security, development and operations but also with the executive team to ensure they are on board with security practices and to make sure the security team has the resources it needs to operate.

In terms of other new job titles, there are increasingly organizations looking for security engineers or security automation engineers, highlighting the desire for security professionals who can create and configure custom security tools.

Changing Relationships

As important as the changing roles are, the changing relationships between dev, sec and ops are perhaps even more critical to successful DevSecOps. “It’s important to bring DevOps teams, traditional infosec practitioners, infrastructure folks, networking folks, into a single working group or committee,” explained Varun Badhwar, senior vice president, Prisma Cloud at Palo Alto Networks. “Really forcing common goals and practices across these teams is the first step in the right direction.”

It’s also important to understand that any discussion of organizational structure and roles is based on generalities. “If you’re a software engineer and you want to get into DevSecOps, you absolutely have to know how security works in a vacuum, but also how does security work specifically in your company?” Widen explained. Understanding the specific context within an organization is critical to everything from setting up appropriate workflows to selecting the right tools. Because everyone runs their technical teams differently and has different priorities and tech stacks, understanding not just the generalities about DevSecOps best practices but also how they relate to your specific infrastructure and business is an essential part of success.

“We’re really seeing a conversation shifting to security terms being consultants in the process, really focusing on policy and governance and making sure the requirements are well understood,” Badhwar said. “That’s a great shift because it’s providing more ownership and accountability to the DevOps teams, allowing them to find security issues earlier in the process and build awareness and training around security.”

Palo Alto Networks and Snyk are sponsors of The New Stack. 

Feature image Photo by andrea krug on Unsplash.