Today’s software development lifecycle is moving faster than ever before as enterprises push out new, artificial intelligence (AI)-powered services and features — and, too often, security comes in at the tail end.

This means that vulnerabilities in code aren’t often caught ahead of time, which can put organizations — and their software supply chains — at significant risk.

The only way to solve this problem, experts say, is to bring security to development. This is the concept behind development, security, and operations (DevSecOps), which integrates security testing at every stage of the software development process. It is the next natural progression of DevOps, which automates and integrates software development and IT operations teams.

DevOps is “development and operations coming together as a shared responsibility model,” Lee Faus, global field CTO for DevSecOps platform GitLab, told SDxCentral. “With DevSecOps, we’re incorporating the security component.”

Security addressed much earlier in the process

Traditionally, Faus noted, developers were only responsible for writing code; once they did so, next-stage responsibilities would be rolled over to operations teams, who would package, deliver, and release. Security would typically then come in “way down the road” as part of the testing scenario — say, on day 29 in a 30-day cycle.

When security teams identified vulnerabilities that late in the game they would alert operations and try to halt release, Faus explained. This would then result in a negotiation, with project managers making promises to fix the code after release. But as Faus put it, “they’ll say they’ll fix everything in the next month, but they don’t.”

With DevSecOps, security is able to identify such vulnerabilities far earlier in the process.

“We’ve been saying for a while in cybersecurity that we need to ‘shift left,’” Terry O’Daniel, head of security at Amplitude, told SDxCentral. (That is, “test early and often.”) “In production it’s way too late.”

With DevSecOps, organizations can layer in automated security testing to find problems before releasing to live production environments.

Faus agreed, underscoring the fact that finding a bug or vulnerability in production can be “very costly.”

Not waiting until it's too late

There has been a significant rise in the use of open-source code as it cuts down the need for developers to write code from scratch — in fact, a whopping 97% of applications are estimated to contain open-source code.

While it is important and becoming invaluable, it’s difficult to know how well open-source code has been maintained, Faus noted. A developer might incorporate third-party code and inadvertently introduce a vulnerability.

DevSecOps allows security teams to flag that vulnerability and work with the development team to identify whether the code should be written differently or if the vulnerability is even dangerous (it could be a false positive). Ultimately, all parties can assure that they did everything they could to produce the most secure code possible.

In both DevOps and DevSecOps, “the two primary principles are collaboration and transparency,” Faus said.

Another core tenet is automation, which creates repeatability and reuse. If a developer knows how to resolve a specific vulnerability, they can reuse it across every other project with that same vulnerability.

From the developer perspective, “I’m not just providing a better security posture for my individual project, I’m helping with the entire company security posture,” Faus said.

DevSecOps still not fully mature

Still, O’Daniel asserted, “DevSecOps as an idea has not really come to fruition in many companies.” Many organizations haven’t yet reached that federated or embedded environment required to best protect themselves.

This isn’t because teams aren’t willing to work together, but instead it’s because leaders don’t understand or aren’t all-in on the concept, he said.

“Most companies don’t have the right tone at the top to promote DevOps in a sustainable way,” O’Daniel said.

O'Daniel previously worked at Yahoo, Netflix, and Instacart, and he joined Amplitude with a goal to “build a bridge back between security and engineering.”

Some members of his security team have come from an operations background, and there have also been internal transfers from security teams to platform teams. Those types of interchanging roles and cross-training are crucial to DevSecOps, O’Daniel noted.

Ultimately, O'Daniel said engineering leadership needs to have a more “eyes open” view and “treat security as a partner.” Security, meanwhile, should be more technical and provide context for well-meaning development teams shipping code at speed so they can make risk-aware decisions on a daily basis.

“An embedded model can have really good benefits,” O’Daniel said. “It cuts the Gordian knot between development teams that don’t understand how infrastructure works and a centralized infrastructure team writing standards rather than procedures.”

Further, everyone across the business needs to understand their data — where it is stored, how it is maintained, and transmitted, who has access to it. Culture must then be built around that data, O’Daniel said.

“It’s starting from a radiating perspective of what are the crown jewels of our business. Almost always it’s going to be data,” he said.

Also, while organizations are rushing to adopt DevSecOps platforms — the global market is expected to reach $23.16 billion by 2029, representing a 31.5% compound annual growth rate (CAGR) — it’s not just about tools.

“Security and DevOps need to work so tightly together,” O’Daniel said. If they’re just building a dashboard “it doesn’t go anywhere, it doesn’t drive action.”

Security is no longer an opt-in — it’s an opt-out

One of the biggest challenges in implementing security throughout the development cycle is the legacy mindset in how security is treated, Faus pointed out. Organizations must be willing to embrace cultural change and be open, transparent, and collaborative about fixing security issues.

Another challenge lies in building in the right type of automation. “One of the first things is to make security a requirement for every new project,” Faus said.

It’s important to have project templates with security as a default, requiring that scans are always completed. Faus pointed out that organizations will often use tools based on what they believe is in a project. For instance, they might run a scan for a Java-based project and everything will look fine. In reality, though, there could be many files — such as Terraform or Shell — that could end up in a project and could bring their own vulnerabilities.

Considering this, organizations should identify different types of files and perform corresponding security scans, Faus advised.

“Security should be first and foremost,” he noted, adding that DevSecOps “should be the core of any software development life cycle.”

Ultimately, he emphasized, “this is no longer an opt-in. This is now an opt-out. When you opt-out, you better have a good reason for why you’re opting out.”