Making DevSecOps more than just lipstick on a pig

  • Developers need to take ownership of the code they write, and that includes security

  • But enterprises need to equip development teams with the necessary tools and training to incorporate security into cloud applications from the start

  • The term “DevSecOps” is “lipstick on a pig,” said Contrast Security’s Larry Maccherone

While security needs to be built into cloud applications from the beginning, developers can't be held responsible if they aren't given the tools and training to do the job, experts told Silverlinings.

Instead of just dumping security on the plates of already overworked developers teams, enterprises need to set those teams up for success. That means platforms need to make security the default, enterprises need to deploy tools that automate security and developers need effective education in good security practices.

“Today, you have silos between the security world and the DevOps world,” Pierre Betouin, SVP of product management at Datadog, told Silverlinings. Methodology, data and even the places these teams work are different. “We need to bring those teams together. We need to embed them together. We need to make them work together,” Betouin said.

Betouin is describing DevSecOps, combining development, security and operations in a single discipline, to ensure cloud applications are built from the beginning to be secure and performant.

Larry Maccherone, Contrast Security's DevSecOps transformation architect, said he coined the term — or at least popularized it — as writer of the DevSecOps Manifesto. He’s not a fan of the word anymore, preferring to say “developer-centric security.”

“It’s become lipstick on a pig. The term ‘DevSecOps’ has been poisoned,” Maccherone said. “It’s traditional security with a new label. DevSecOps originally was about empowering engineering teams to do security.”

It’s no wonder that 90% of security teams say they struggle to secure cloud applications.

It’s a cloud thing

Developers becoming involved in security is a phenomenon of the cloud, said Katie Norton, senior research analyst for DevOps & DevSecOps at IDC.

“In our research, we generally only see developers involved in cloud security to the extent they are writing cloud-native applications that are being run securely in the cloud,” she said. Among the key concerns this raises are avoiding vulnerabilities, protecting secrets and avoiding using insecure APIs.

Platform engineering is picking up much of the security burden, by building security and compliance into the platform and making it easier for developers to build and deploy secure apps, Norton added.

DataDog chases the ball

Datadog, which provides an observability and security platform for cloud applications, is bringing the silos together by providing them a shared platform for telemetry data to manage site reliability, performance and security, Betouin said.

Datadog’s Security Inbox provides DevOps and security teams with information about the top security issues they need to address to reduce risk across cloud accounts, Kubernetes clusters, containers and applications. Late last month, Datadog added identity, vulnerability and app-level findings to Security Inbox.

Development teams need to focus on security problems they’re well suited to solve — for example, detecting and remediating vulnerabilities in third-party and open source code libraries that comprise the preponderance of new application development, Betouin said. On the other hand, developers are not well suited to investigating and remediating a denial-of-service attack from a particular geographical location. That should be the responsibility of dedicated security teams.

Security teams and development teams complement each other. Security teams will generate lists of vulnerabilities in running code, but the DevOps team has the information needed to prioritize which vulnerabilities need remediation, Betouin said. For example, a vulnerability in code that isn’t deployed doesn’t require immediate remediation.

Who owns the problem?

Developers need to be given responsibility for security of the code they write. They need to take ownership of it, said Contrast Security’s Maccherone.

“Who will be on the line if something goes bad?” Maccherone said. “If I put my hand on the hot plate and you don’t feel the pain, the lesson doesn’t really sink in for you.”

Ownership gives you power over how things are done, but you are on the hook for the outcome, he added.

Developers need to change their processes and tools to incorporate security practices into their daily work, Maccherone said. Security needs to be built into applications, the same way that reliability and usability are.

And DevOps team need help with with their tools for that process. Security monitoring needs to be built into the Application Performance Monitoring (APM) tools that DevOps teams already use, checking for security vulnerabilities alongside reliability.

“You meet them where they are already working today, where they do their job,” Betouin said.

These types of tools can help DevOps teams become more proactive about building security into their products without adding to those teams’ already overwhelming schedules, Betouin said.

Getting schooled

Additionally, Dev teams need training, Maccherone said. But it has to be the right kind of training. Big all-day or multi-day classes don’t yield positive results, and can actually be harmful.

Instead, developers should get just-in-time training — a few minutes of education in how to remediate vulnerabilities when scanning tools detect that vulnerability, Maccherone said. Also effective: coaching of developers by a member of the security team helps improve the security profile.

Developers need to be motivated to take ownership of the security of their work by connecting security to overall quality, which developers already care about.

“You can’t policy-enforce your way into it. If you do, you get minimal responses — checkbox responses,” Maccherone concluded.

(Disclaimer: Contrast Security is a sometime client for Mitch Wagner's content marketing business. But they did not pay him for inclusion in this article and he is not currently doing any work for them.)