Article By : Ann R. Thryft
Software security is said to no longer be only about securing applications. Now, it also involves securing what’s used to build those applications.
What do epic cybersecurity attacks like 2021’s SolarWinds and Kaseya have in common with DevOps, AppSec, and the pandemic? Not much. But when it comes to securing the software supply chain, they may all be connected.
Not much has changed since we last checked in on this problem a year ago. Cyberattacks continued to increase in 2021. Compared with 2020, they rose by 606% against software publishers, according to a recent Netscout report. Attacks on computer storage manufacturers jumped by 263%, and on computer makers by 162%.
Nearly three-quarters of software companies and almost two-thirds of large enterprises suffered hacks and intrusions last year, according to a report from Anchore released in January. More than half of the IT, security, and development executives surveyed said they are making software supply chain security a top focus this year.
That’s a good thing because many reports say the state of their unpreparedness is very high.
KNOWING ISN’T DOING
Nearly two-thirds of senior IT security professionals said they wouldn’t be able to stop an attack against their development environment, and almost the same number admitted they haven’t done anything to secure their software supply chain, according to a CyberArk survey.
Fewer than 40% of companies can detect when their developed code has been tampered with, and a miniscule 7% check their code for tampering at each phase of the development cycle, senior software employees reported in a recent ReversingLabs survey. An overwhelming majority were clearly aware that tampering could result in a security breach.
These disconnects are symptoms of a wider problem, Jon Jarboe, director of product marketing for Cycode, said in an interview with EE Times. While many on the development side have been focused on other security issues—primarily on solving application vulnerabilities—these attacks on the software development pipeline were increasing.
“I’m not sure that most organizations are currently equipped to address that type of security problem,” Jarboe said. “If attackers can take over your pipeline, it doesn’t matter how secure your code is because they can insert their code, their malware, and your pipelines will send it to your production environment or to your customers.”
For these reasons, software security is no longer about securing only the applications. Instead, it’s also about securing what’s used to build those applications. This includes the tools and environments, and as Jarboe explains, “all the pieces that go into it, whether you wrote it or bought it off-the-shelf or pulled it in from an open-source repository.”
“The supply chain has its own dependencies, with the same vulnerabilities that can be leveraged by attackers in applications. [Its] security problem is the next step in application security,” he added.
THE STATE OF SECURITY TOOLS
Attempts to solve this problem are still so new that not all areas of the possible attack surface are known yet, while new ones continue to appear, Jarboe noted. The tools available for preventing known problems work well and are often automated so they don’t get in the developer’s way.
But they can’t give a complete picture of all the possible, unknown risks, whether for creating new software or for integrating third-party code.
Vulnerabilities especially are a major problem, both during development and after code has shipped. “Once software is put out into the world, there may be vulnerabilities we weren’t aware of,” Jarboe said. “And how do you recognize when new vulnerabilities are relevant to you?”
Another problem is the constraints on the security tools we do have.
For instance, static application security testing (SAST) tools used before code gets deployed, and software composition analysis (SCA) tools that look for known vulnerabilities, don’t give the developer much in the way of guidelines for using them.
“A big operational challenge with these tools is they can tell you there are problems; but how do you know where to start?” Jarboe said. “How important is each problem? Where will that code be used—in a production environment, or as a support tool without access to customer data? Where is it located in the source code, and what needs to be done to fix it?”
Then there’s the challenge of maintaining code in the real world: understanding its components and being able to look at the history of what happened throughout its development and deployment.
The pandemic has also influenced both DevOps and AppSec. While developers had already begun working remotely, lockdowns increased both remote work and related security concerns.
When even larger numbers of developers began working remotely, this pushed them, as well as many other workers, out into the cloud—a trend that had already begun in DevOps. That shift spawned tools like Terraform for codifying the state of infrastructure—infrastructure as code (IaC)—instead of getting things done through IT, Jarboe said.
“IaC enables us to better understand the context where the code will run, so we can make better decisions about the security findings we’re getting from the tools,” he said. “I think AppSec can be seen as a subset of software supply chain security—they’re all part of the same thing.”
CONTROLS, TOOLS, AND GUIDELINES
Some new tools have become available.
Last fall, for example, Google announced its Minimum Viable Secure Product (MVSP) initiative, a vendor-agnostic set of minimum baseline controls for the business, application design, application implementation, and operational stages of developing secure B2B software products. The idea is to give companies, including underserved, smaller ones, a template so they don’t have to start from scratch.
More recently, the Center for Internet Security and Aqua Security co-developed guidelines for software supply chain security, as well as an open-source tool for auditing an organization’s own software supply chain.
Without visibility into the development process, security teams can’t secure it. According to Jarboe, “we’re seeing a huge upswing in software supply chain attacks like SolarWinds, typosquatting, and dependency confusion.”
Both the development process and the environments have become valuable targets, and a huge attack surface for applications built with them. “There’s a lot of cultural inertia to overcome, but companies need to get their arms around this problem,” he said.
This article was originally published on EE Times.
