Though this is technically a “Buyer’s Guide” by SD Times terminology, let’s preface this article by remembering that buying a piece of software isn’t the key to fixing all security issues. If there was some magical security solution that could be installed to instantly fix all security problems, we wouldn’t be seeing a year-over-year increase in supply chain attacks, and you probably wouldn’t be reading this article.
Yes, tooling is important; You can’t secure the software supply chain with secure coding practices alone. But you’ll need to combine those best practices with things like software bills of materials (SBOMs), software composition analysis, exploit prediction scoring systems (EPSS), and more.
Before we can begin to think about what tooling can help, step one in this fight is to get the fundamentals down, explained Rob Cuddy, global application security evangelist at HCLSoftware. “There’s a lot of places now that are wanting to do security better, but they want to jump to steps four, five, and six, and they forget about steps one, two, and three,” he said.
See also: A guide to supply chain security tools
He explained that even with new types of threats and vulnerabilities that are emerging, it’s still important to take a step back and make sure your security foundation is strong before you start getting into advanced tooling.
“Having the basics done really, really well gets you a long way towards being safe in that space,” he said.
According to Janet Worthington, senior analyst at Forrester, the first step is to ask if you’re following secure development practices when actually writing software.
“Are we secure by design when we’re building these applications? Are we doing threat modeling? Are we thinking about where this is going to be installed? About how people are going to use it? What are some of the attack vectors that we have to worry about?”
These are some of the basics that companies need to get down before they even start looking at where tooling can help. But of course, tooling does still play a crucial role in the fight, once those pieces are in place, and Cuddy believes it is crucial that any tool you use supports the fundamentals.
The bare minimum for software supply chain security is to have an SBOM, which is a list of all of the components in an application. But an SBOM is just an ingredient list, and doesn’t provide information about those ingredients or where they came from, Worthington explained.
Kristofer Duer, software architect team lead at HCLSoftware, added, “you need to know what goes into it, but you also need to know where it’s built and who has access to the code and a whole list of things.”
According to Worthington, this is where things like software composition analysis tools come in, which can analyze SBOMs for security risks, license compliance issues, and the operational risk of using a component.
“An example of an operational risk would be this component is only maintained by one person, and that single contributor might just abandon the software or they might go do something else and no longer be maintaining that application,” she said.
According to Colin Bell, AppScan CTO at HCLSoftware, EPSS — a measure of the likelihood that a vulnerability actually gets exploited — is another emerging tool to improve supply chain security by smartly prioritizing remediation efforts.
“Just because you have something in your supply chain doesn’t necessarily mean that it’s being used,” he explained.
Bell said that he believes a lot of organizations struggle with the fact that they perceive every vulnerability to be a risk. But in reality, some vulnerabilities might never be exploited and he thinks companies are starting to recognize that, especially some of the larger ones.
By focusing first on fixing the vulnerabilities that are most at risk of getting exploited, developers and security teams can effectively prioritize their remediation strategy.
Worthington added that integrating secure by design foundations with some of these tools can also cut down on release delays that are caused by scanning tools finding security issues at the last moment, right before deployment, which might prevent deployments from going out until the issues are resolved. This is needed as companies are under more and more pressure to release software faster than ever.
“Organizations that release frequently with high confidence do so by embedding security early in the Software Development Life Cycle (SDLC),” said Worthington. “Automating security testing, such as Software Composition Analysis and Static Application Security Testing, provides feedback to developers while they are writing code in the IDE or when they receive code review comments on a pull request. This approach gives developers the opportunity to review and respond to security findings in the flow of work.”
She also said that identifying issues before they are added to the codebase can actually save time in the long run by preventing things from needing to be reworked. “Security testing tools that automate the remediation process improve product velocity by allowing developers to focus on writing business logic without having to become security experts,” she said.
XZ Utils backdoor highlights importance of people in protecting the software supply chain
However, as mentioned at the top, tools are only one component in the fight, and secure practices are also needed to deal with more advanced threats. A recent example of where the above-mentioned tools wouldn’t have done much to help on their own is when in March, it was announced that a backdoor had been introduced into the open-source Linux tool XZ Utils.
The person who had placed the backdoor had been contributing to the project for three years while gaining the trust of the maintainers and ultimately was able to rise to a level at which they could sign off on releases and introduce the backdoor in an official release. If it hadn’t been detected when it was and had been adopted by more people, attackers could have gained access to SSH sessions around the world and really caused some damage.
According to Duer, the vulnerability didn’t even show up in code changes because the attacker put the backdoor in a .gitignore file. “When you downloaded the source to do a build locally, that’s when the attack actually got realized,” he said.
He went on to explain that this goes to show that developers can no longer just “get the source and run a build and call it a day. You have to do so much more than that … They have the SHA-256 hash mark on the bins, but how many people run those commands to see if the thing that they downloaded is that hash? Does anybody look in the CVE for this particular package to see if there’s a problem? Where do you rely on scanners to do that work for you? It’s interesting because a lot of the problems could be avoided with another couple of extra steps. It doesn’t even take that much time. You just have to do them,” Duer said.
Worthington added that it’s really important that the people actually pulling components into their applications are able to assess quality before bringing something into their system or application. Is this something maintained by the Linux Foundation with a vibrant community behind it or is it a simple piece of code where nobody is maintaining it and it might reach end of life?
“A very sophisticated attacker played the long game with a maintainer and basically wore that poor maintainer down through social engineering to get their updates into XZ Utils. I think we’re finding that you need to have a really robust community. And so I think SBOM is only going to get you so far,” said Worthington.
While this may seem like an extreme example, the Open Source Security Foundation (OpenSSF) and the OpenJS Foundation put out an alert following the incident and implied that it might not be an isolated incident, citing similar suspicious patterns in two other popular JavaScript projects.
In the post, they gave tips for recognizing social engineering attacks in open source projects, such as:
- Aggressive, but friendly, pursuit of maintainers by unknown community members
- Requests from new community members to be elevated to maintainer status
- Endorsement of new community members coming from other unknown members
- PRs containing blobs as artifacts
- Intentionally difficult to understand source code
- Gradually escalating security issues
- Deviation from typical project compile, build, and deployment practices
- A false sense of urgency to get a maintainer to bypass reviews or controls
AI will make things worse and better
AI will also exacerbate the number of threats that people have to deal with because as much as AI can add useful features to security tools to help security teams be more effective, AI also helps the attackers.
Having AI in applications complicates the software supply chain, Worthington explained. “There’s a whole ecosystem around it,” she said. “What about all the APIs that are calling the LLMs? Now you have to worry about API security. And there’s gonna be a bunch of new types of development tools in order to build these applications and in order to deploy these applications.”
Worthington says that attackers are going to recognize that this is an area that people haven’t really wrapped their heads around in terms of how to secure it, and they’re going to exploit that, and that’s what worries her most about the advances in AI as it relates to supply chain security.
However, it’s not all bad; in many ways, supply chain security can benefit from AI assistance. For instance, there are now software composition analysis tools that are using generative AI to explain vulnerabilities to developers and offer recommendations on how to fix it, Worthington explained.
“I think AI will help the attackers but I think the first wave is actually helping defenders at this point,” she said.
Bell was in agreement, adding “if you’re defending, it’s going to improve the threat detection, it’s going to help with incident response, and it’s going to help with detecting whether vulnerabilities are real.”
The government is starting to play a role in securing supply chains
In 2021, President Biden signed an executive order addressing the need to have stronger software supply chain security in government. In it, Biden explained that bold change is needed over incremental improvements, and stated that this would be a top priority for the administration.
The executive order requires that any company selling software to the government provide an SBOM and set up a pilot program to create an “energy star” type program for software so that the government can easily see if software was developed securely.
“Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit,” the White House explained. “This is a long-standing, well-known problem, but for too long we have kicked the can down the road. We need to use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.”
Worthington said: “I think the Biden administration has done a really good job of trying to help software suppliers understand sort of like what the minimum requirements they’re going to be held to are, and I think those are probably the best place to start.”
Cuddy agreed and added that the industry is starting to catch up to the requirements. “Not only do you need to generate a bill of materials, but you have to be able to validate across it, you have to prove that you’ve been testing against it, that you’ve authorized those components … So much of it started with the executive order that was issued a few years ago from President Biden, and you’ve now seen the commercial side starting to catch up with some of those things, and really demanding it more,” he said.
