Hear from CIOs, CTOs, and other C-level and senior executives about data and AI strategies at the Future of Work Summit on January 12, 2022. Learn more
In the area of application security, the discussion about the concept of DevSecOps and the associated phrase “move to the left” can hardly be overlooked. The emergence of the widespread Apache Log4j vulnerability only added to the excitement.
But that doesn’t mean everyone is talking about the same thing, says Doug Dooley, chief operating officer at Application Security Vendor record.
For those who haven’t heard, DevSecOps aims to unify development, security, and operations in order to secure apps during the development process itself. “Shift left” refers to the idea of embedding security at the beginning or on the left side of the development lifecycle.
However, according to Dooley, an effective DevSecOps strategy isn’t really about keeping developers safe. “It’s about security teams having a more DevOps mindset – not DevOps, which is more of a security mentality,” he told VentureBeat.
“The thing that causes DevSecOps programs to fail is when a security officer finds an exploit and then calls a meeting about it,” said Dooley.
The better approach is to treat a vulnerability in your code “much more like a developer would treat it: treat it like a bug. Put it back in the system and go. Keep the feature velocity going, ”he said.
According to a recent report from Venafi, almost all IT senior executives – 97% – agree that software build processes are not secure enough. Application security concerns are rife following attacks like the SolarWinds Orion software supply chain violation, as well as open source vulnerabilities like the bug in Log4j, a logging library widely used in Java applications.
In response to such application security concerns, some organizations have tried to convince developers to work differently to ensure security.
For example, some companies have started talking about teaching developers how to write “secure code,” Dooley said. But every time that happens it is a “loss of credibility,” he said.
The developer’s immediate reaction will always be: “’I’m working on bugs and functions. Don’t make me learn to be safe. Don’t try to give me safety training, ”Dooley said.
As companies are increasingly dependent on their developers in the digital transformation, this is a critical point in order to be right.
“We’ve all worked in organizations where security is a punishment,” said Stephen Schmidt, chief information security officer at Amazon Web Services, during a session at AWS re: Invent this month.
“This creates a culture of fear and avoidance,” says Schmidt. “Instead, let’s make security a great experience for builders … We can never get into a position where someone does something ‘because security said so’. That doesn’t create trust. That doesn’t build property. And it doesn’t build a functional partnership. “
Journey towards DevSecOps
According to Dooley, DevSecOps clearly requires a high level of trust between the developer and security side of the company. This is partly because DevSecOps is ultimately best achieved by automating security as much as possible during app development.
To get to a true DevSecOps program, security teams must first provide data to developers that is presented in the form in which they work – which for many DevOps teams is done through a Jira ticket, Dooley said. “Appear in the packaging and format they are used to and give them all the information they need for treatment [security issues] like a bug or like a feature, ”he said.
Therefore, the first stage on the road to DevSecOps can be to provide developers with a safe code sample that fixes a specific problem in the code, Dooley said. However, this secure code has yet to be implemented manually.
At the next level, companies can enable semi-automated fix, he said. This can include automatically disabling issues that pose a security risk. With this approach, a human still needs to be signed off on the final build.
The top level is full automatic correction. For example, if a misconfiguration is detected, that problem can be automatically fixed and provisioned as soon as the detection occurs, Dooley said.
“If you have this setup, it means you have a DevSecOps program,” he said. “The development team now trusts the security team – that if they bring them things, it’s real. Well worth repairing. It’s worth changing. That is the ideal scenario. “
Data Theorem provides a platform for enabling DevSecOps, serving customers such as Netflix, Salesforce, Microsoft and five of the seven largest banks in the world. The platform helps secure a total of more than 8,000 applications for corporate customers.
Data Theorem’s customers who take a fully automated DevSecOps approach, alongside developer-heavy organizations like Netflix, include financial services company Fannie Mae. “Most people would describe them as very traditional, very local. But they moved to the cloud pretty quickly, ”said Dooley.
For this reason they also got into DevSecOps. This shows that regardless of what its brand suggests, a company can still make a quick move to DevSecOps if it takes an overall digital and cloud-centric approach, Dooley said.
Currently, about a third of Data Theorem’s customers have a fully automated DevSecOps program, while another third is semi-automated, he said. “But at least they stopped making spreadsheets and convening meetings” when they found a security problem, Dooley said.
In the final third, security and DevOps don’t see themselves as a team yet, and there isn’t much collaboration between them yet, he said.
The burden rests on the security teams
However, for companies that stay at this level, the burden is mostly on security to prove they can be of value to a DevOps team, Dooley said.
“And we’re trying to help them show up with data, show up with automation, and show up with [a] Value they can offer the DevOps team, ”he said.
At the other end of the spectrum, however, the number of companies that switched to a fully automated DevSecOps approach has grown rapidly during the pandemic. Dooley says that while a third of the company’s customers are now at this top tier within DevSecOps, that percentage was only around 15% before the pandemic started.
Dooley estimates that for the Fortune 500, around 20% of companies have already implemented DevSecOps – and that the number will rise to 30% or more in 2022.
“DevSecOps is by far the most transformative thing an application security team can do to add value to the business,” he said. “If you had to choose a project for AppSec, implementing a DevSecOps program in the next five years is without a doubt the most transformative.”
VentureBeat’s mission is to be a digital marketplace for technical decision makers to gain knowledge about transformative technologies and transactions. Our website provides essential information on data technologies and strategies to help you run your organization. We invite you to become a member of our community to gain access:
- current information on the topics of interest to you
- our newsletters
- closed thought leadership content and discounted access to our award-winning events such as Transform 2021: Learn more
- Network functions and more
become a member