Start paying down your ‘security debt’ with DevSecOps

Organizations that postpone remediating security issues, or just ignore them, are playing a risky game. But DevSecOps can help reduce your security debt.

Financial debt isn’t necessarily a bad thing. Most people wouldn’t be able to buy a house if they didn’t take out a mortgage.

Security debt—the kind that builds up when you don’t fix “older” vulnerabilities in your software—isn’t like that. It’s not like a mortgage, where nothing bad will happen as long as you make all the required monthly payments for 30 years.

It’s a bit more like paying only the monthly minimum on your credit card and letting everything else you spent the previous month pile up. Eventually the accumulated interest will put you in the hole.

But security debt is even more dangerous than that. If you don’t address the vulnerabilities accumulating in your applications, networks, and systems, something bad could happen anytime—and the odds increase the longer you let the “debt” build up.

DevSecOps and security debt

Fortunately, there is an effective way to address security debt: by embracing a DevSecOps culture, the principle that all technology teams, not just those with “security” in their names, are accountable for security.

Unfortunately, too many organizations are still ignoring, or forgetting, even catastrophic examples had of what can happen if they fail to adopt DevSecOps.

Like what you’re reading? Subscribe to the blog!

One of the most notorious is Equifax, the credit reporting giant breached in 2017 because it failed to patch a known vulnerability in Apache Struts, a popular open source web application framework. The patch had been available for months. The breach compromised crucial personal data of more than 147 million people.

Yet, more than a year later, the Synopsys OSSRA (Open Source Security and Risk Analysis) report showed that of the analyzed codebases containing Apache Struts, a third were still vulnerable to the same bug that affected Equifax.

‘Security by obscurity’

Or you could look at more recent headlines. The Security Ledger reported that seven years after security researchers at IOActive issued a warning about insecure, internet-connected Emergency Alert System (EAS) hardware, “scores of the devices across the U.S. remain unpatched and vulnerable to cyberattack.”

The Ledger noted that security researcher Shawn Merdinger warned less than two weeks earlier that more than 50 EAS deployments in the U.S. still contained the vulnerability reported in 2013.

That’s security debt. And those are stark illustrations of the reality that too many organizations fix vulnerabilities they discover while building applications, networks, or systems but ignore those discovered later, going back months or even years. Sort of a “security by obscurity” mindset, as in, “If I forget about that stuff from six months ago, the bad guys will too.”

Bad idea. Security debt is bad debt. And bad things can happen from bad debt.

Just a new version of technical debt

Unfortunately, this is not something new. It’s a version of “technical debt,” a term coined more than a decade ago by programmer Ward Cunningham (developer of the first wiki), who compared failure to address problems with software to “borrowing money thinking you never had to pay it back.”

“Of course, if you do that—say with your credit card—eventually all your income goes to interest and your purchasing power goes to zero,” he said.

When it comes to software security, a version of accumulating “interest” is what experts have been warning about for decades as well: It costs more time and money to fix something later than sooner. Beyond that, an organization’s failure to “pay down the interest” on its security debt could put it at risk of becoming yet another version of Equifax—the victim of a catastrophic breach made possible by a vulnerability it could have fixed.

And Utsav Sanghani, staff product manager at Synopsys, said many organizations are carrying a potentially catastrophic level of security debt. “The percentage of security improvements needed in a typical technical debt bucket ranges from 40% to 50%,” he said. “This is because security is still an afterthought in many development decisions, and over time it grows to be sizeable.”

How to reduce security debt with DevSecOps

But amid all that ominous news, there is good news. As noted above, organizations can start addressing their security debt with DevSecOps. While the cliché “better never late” is true, what’s also true is “better late than never.”

Sneha Kokil, senior security consultant at Synopsys, said she has become a fan of the DevSecOps activities summarized with what many call the “elevator acronym” CALMS. Its five pillars include:

• Culture. Encourage collaboration and shared responsibility among the development, security, and operations teams.
• Automation. Replace manual security tooling and processes with automated ones whenever possible.
• Learn. Enable continuous improvement through feedback and fine-tuning security processes.
• Measurements. Collect data on processes and deployments through outputs from pipelines and scan results. Offer feedback for learning and improvement.
• Sharing. Share information within and among teams to keep everyone working toward the same goals, one of which is building secure, high-quality software.

“More specifically, it means bringing in security early on, in the design and requirements phases,” Kokil said, “so you’re building security in from the start and during all SDLC phases.”

Shift left and lead by example

Sanghani agreed. He said taking DevSecOps seriously means to “shift left (make security a part of the SDLC from the start), advocate security to be front and center of every development and design decision, and help customers integrate at different stages in the SDLC to achieve that.”

What are the chances of that happening? Kokil is hopeful that organizations that “lead by example” might move the needle in the right direction. “Every organization learns from others, I believe,” she said, adding that one way to learn from others is through the BSIMM (Building Security In Maturity Model), an annual report on what more than 120 organizations in multiple verticals are doing to improve their software security.

“Organizations can use such reports as a springboard to a wider assessment of how solid their DevSecOps culture is,” she said.

Sanghani, however, fears that it will take something more like a stick than a carrot to get organizations to address the problem of security debt. “A repeat of an Equifax-like breach is the only wake-up call, unfortunately,” he said.