Hear from CIOs, CTOs, and other C-level and senior execs on data and AI strategies at the Future of Work Summit this January 12, 2022. Learn more
In the realm of application security, it’s hard to miss the discussion right now around the concept of DevSecOps—and its companion phrase, “shift left.” The arrival of the widespread Apache Log4j vulnerability has only increased the buzz.
But that doesn’t mean everyone is talking about the same thing, says Doug Dooley, chief operating officer at application security vendor Data Theorem.
For those who haven’t heard, DevSecOps aims to unify development, security, and operations to secure apps during the development process itself. “Shift left” is a reference to the idea of embedding security at the beginning, or left side, of the development lifecycle.
But an effective DevSecOps strategy is not actually about bringing security to developers, according to Dooley. “It’s about security teams having more of a DevOps mindset—not DevOps having more of a security mindset,” he told VentureBeat.
“The thing that makes DevSecOps programs fail is when a security person finds an exploit, and then calls a meeting about it,” Dooley said.
The better approach is to treat a vulnerability in code “more like devs would treat it: Treat it like a bug. Put it back into the system and go. Keep the feature velocity going,” he said.
App insecurity
According to a recent report from Venafi, nearly all senior IT executives — 97% — agree that software build processes are not secure enough. Concerns about application security are widespread in the wake of attacks such as the SolarWinds Orion software supply chain breach, as well as open-source vulnerabilities such as the flaw in Log4j, a logging library used widely in Java applications.
In response to such application security concerns, some enterprises have attempted to get developers to work differently in order to ensure security.
Some companies, for instance, have begun talking about teaching developers how to write “secure code,” Dooley said. But any time that happens, that is a “credibility-losing moment,” he said.
The developer’s immediate reaction will always be, “‘I work on bugs and features. Don’t make me learn security. Don’t try to put me through security training,’” Dooley said.
As digitally transforming enterprises rely ever more heavily upon their developers, this is a critical issue to get right.
“We’ve all been in organizations where security becomes punitive,” said Stephen Schmidt, chief information security officer at Amazon Web Services, during a session at AWS re:Invent this month.
“What that creates is a culture of fear and avoidance,” Schmidt said. “Instead, let’s make security a great experience for builders … We can never be in a position where somebody is doing something ‘because security said so.’ That doesn’t build trust. That doesn’t build ownership. And it doesn’t build a functional partnership.”
Journey toward DevSecOps
Clearly, DevSecOps requires a high degree of trust between the developer and security sides of the organization, according to Dooley. In part, that’s because DevSecOps is ultimately best delivered through automating security as much as possible during app development.
For getting to a true DevSecOps program, security teams must start by providing data to developers that is presented in the form in which they operate—which for many DevOps teams is through a Jira ticket, Dooley said. “Show up in the packaging and format that they’re used to, and supply them with all the information that they need to do to just treat [security issues] like a bug or like a feature,” he said.
Thus, the first level on the journey to DevSecOps can involve supplying developers with a secure code sample that fixes a certain issue in the code, Dooley said. But this secure code still needs to be implemented manually.
At the next level, companies can enable semi-automated remediation, he said. This can involve automatically disabling issues that are creating a security exposure. With this approach, a human still has to sign off on the final build.
The top tier is full auto-remediation. For instance, when a mis-configuration is detected, that issue can be automatically fixed and deployed as soon as the detection occurs, Dooley said.
“If you have that setup, that means you have a DevSecOps program,” he said. “The development team now trusts the security team—that when they bring them stuff, it’s real. It’s worth fixing. It’s worth changing. That is the ideal scenario.”
Cloud correlation
Data Theorem offers a platform for enabling DevSecOps that serves customers including Netflix, Salesforce, Microsoft, and five of the world’s seven largest banks. The platform helps to secure more than 8,000 applications for enterprise customers in total.
Along with developer-heavy organizations such as Netflix, other Data Theorem customers that are following a fully automated DevSecOps approach include financial services firm Fannie Mae. “Most people would think of them as very traditional, very on-prem. But they’ve moved to the cloud pretty fast,” Dooley said.
And as a result, they’ve also moved into DevSecOps. This shows that regardless of what their brand suggests, a company can still shift into DevSecOps rapidly once it embraces a digital- and cloud-oriented approach overall, according to Dooley.
Currently, about a third of Data Theorem’s customers have a fully automated DevSecOps program, while another third are semi-automated, he said. “But at least they’ve stopped doing spreadsheets and calling meetings” when they find a security issue, Dooley said.
For the last third, security and DevOps don’t yet view themselves as one team, and there’s not a lot of cooperation between them yet, he said.
The burden is on security teams
For companies that continue to remain at that level, however, “the burden is mostly on security” to prove that they can be valuable 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 value that they can provide to the DevOps team,” he said.
On the other end of the spectrum, however, the number of companies that have shifted to a fully automated DevSecOps approach has grown quickly during the pandemic. Dooley says that while a third of the company’s customers are now at that top tier within DevSecOps, that proportion was only about 15% before the pandemic began.
Dooley estimates that for the Fortune 500 overall, about 20% of companies have already embraced DevSecOps—and that the figure will expand to 30% or more in 2022.
“DevSecOps is by far the most transformative thing an application security team can do to make themselves valuable to the organization,” he said. “If you had to pick one project for AppSec, the most transformative thing for you to do, over the next five years, is to do a DevSecOps program, without a doubt.”
VentureBeat
- up-to-date information on the subjects of interest to you
- our newsletters
- gated thought-leader content and discounted access to our prized events, such as Transform 2021: Learn More
- networking features, and more
Source: Read Full Article