Software supply chain attacks are on the rise, with attackers embedding malware in novel and sophisticated ways, including using emerging technology such as generative AI. To make things even more complex, the software that organizations are developing and using is made up of an amalgam of many different constituent pieces including open source and third-party components.
A recent DigiCert-sponsored webinar titled Digital Trust in Software Supply Chains & AI Models, addressed the challenges in preventing software supply chain attacks. Hosted by DigiCert CEO Amit Sinha, it featured three industry-recognized experts in the space:
These three experts delineated several of the challenges organizations are facing and then offered several best practices for organizations to adopt going forward.
According to the Open Source Security and Risk Analysis Report, 96% of scanned codebases contain open source. This contributes to overall risk because this code is not under the organization’s control and expands the attack surface that bad actors can manipulate. While software supply chain problems have always existed, this expansion in software size and complexity has caused attack payloads to grow. A 2023 ReversingLabs report found that almost 90% of companies detected software supply chain risks in the last year alone, and more than 70% say that current application security solutions fail to provide the necessary protections against these types of attacks.
"Third-party components have increasingly been used [by bad actors] for evasion and lateral movement, especially in larger and more important breaches. Software supply chain attacks can happen through open source and third-party compromises, or as it was in the case of the attack on SolarWinds, through the exploitation of the build system."
For software developers, generative AI brings about additional security risks. Generative AI enables malware to morph into different forms that can elude security controls or tamper with AI models being used internally. Bad actors can also leverage AI to automate cybersecurity attacks.
Hugh discussed this issue in more detail:
"We've seen already some examples of high-velocity attacks that we believe are automated by machine learning and AI on the backend that are very difficult for a set of humans or an enterprise to adapt to. Folks are moving quickly in this space, but we've got to remember that AI models that are out in the wild could have a multitude of problems associated with them, one of which is they can themselves contain malware, and so it's something that needs to be evaluated carefully before you go full steam ahead."
In the webinar, the three industry leaders shared their insights on the best practices organizations should adopt to protect the software supply chain:
During the webinar, Mario pointed out that when most people think about software supply chain attacks, they think of public attacks such as the SUNBURST attack, best known for its impact on SolarWinds, which showed organizations in a dramatic fashion that a single attack can impact tens of thousands of companies in one fell swoop. “A lot has been made about making sure we build our resiliency to a completely different level to withstand major attacks in the future,” he said.
At the same time, the focus on SUNBURST and other publicized attacks like Codecov and Kaseya has perhaps led organizations to mistakenly believe they haven’t had a software supply chain attack when they may well have. But everyone is at risk for this type of attack.
Hugh said that this has to do with the complexity of most software in use today.
"[Software is] comprised of not just code you write internally, but all of these third-party libraries and constituent components that you pull dynamically when you compile the system. So even if the attack wasn't exactly focused on you as a company, you still have the ability for an attacker to manipulate one of these commonly used libraries and infiltrate software. And I think this is one of the biggest challenges that we're grappling with right now."
To protect against these attacks, organizations need to implement deep threat and vulnerability detection analysis. In addition to scanning code, this requires searching for such threat and vulnerability patterns within final software binaries as malware, secrets leakage, software tampering and other CVEs (Common Vulnerabilities and Exposures).
In the last several years, we’ve seen several examples of what happens when code signing keys are improperly secured. Hugh noted that sophisticated attackers have typically found the weakest link in the chain to be around cryptography. For example, the ASUS code signing breach resulted from hackers breaching the insecure web servers where developers had stored their code signing keys and infected them with malware. And a quick scan of the dark web will not only reveal stolen code signing credentials but also malware kits that nontechnical buyers can use to exploit unprotected keys.
To counteract this problem, CA/B Forum now (as of June 1, 2023) requires that code signing private keys must be stored on a FIPS 140-2 or Common Criteria Level EAL4+ compliant device. But as Amit noted, organizations also need to have policy-based controls in place, including role-based administration, and audit logs that show who is signing code and where it is being run, among other things. In addition, robust validation. “You need to thoroughly vet the organization that is requesting the signing authority,” Amit said.
Concurring, Hugh said:
"There’s a lot to like about a code signing infrastructure because its premise is that as the software maker, you’re making an attestation that this is the software you produced. But it relies on a couple of things. First, it relies on the fact that you’re keeping the private key in a secure way so that an attacker cannot exfiltrate it and sign software masquerading as you. The other is [making sure] the systems around it, which automatically push software through the signing infrastructure, haven’t been compromised. Because if they have been compromised, an attacker can take their software, which may be a modified version of your software, and push it through your own signing infrastructure without you knowing it. And it looks legitimate."
A software bill of materials, or “SBOM,” is an attestation that “the software being signed is free from bugs, malware and other vulnerabilities, that it hasn’t been tampered with and that the software team knows exactly what components are inside of it,” DigiCert senior marketing manager Eddie Glenn explains in a June DigiCert blog post.
The increasing importance of SBOMs is being driven by recent government regulations and industry standards, Saša explained, including U.S. federal government’s Executive Order 14028 and the EU’s Cyber Resilience Act. Saša compared SBOMs to nutrition labels on food.
"Decades ago, it became widely accepted that it was a good idea to know what we are putting into our bodies. So, the FDA came out with this nutrition label so we know what’s in things. Now it’s completely common practice for us to go to the store, look at the ingredient list and if you have glycemic issues, say, “I would like something with a lower sugar concentration.”
Similarly, there is now this increasing need for us to know what we’re putting into our enterprise systems. I may have a deliberate decision to avoid certain libraries or license types because they could put me in legal liability. If something were to happen down the road, I want to be able to very quickly know where I have Log4j, where I am using Infragistics and where other things are in my environment.
Therefore, it’s essential that you scan everything that makes up the software you’re attesting to the legitimacy and safety of.
"It's not just the open source code, it's not just the code that you've written yourself, it's the models that may be in there, but it's also the binaries. Many people stop at the binaries and don't actually scan them. They just enumerate that these binaries exist, but in fact, huge risks could come from those binaries as well."
Digital trust is more than just the technologies that make it possible. For organizations to be champions of digital trust, they must understand and actively implement the structure, processes and activities that make it possible. This includes keeping up with changes to industry standards, maintaining compliance with regulatory requirements in each geography, managing the lifecycle of digital trust technologies and extending trust into digital ecosystems.
Software trust is fundamental to realizing digital trust. To achieve software trust, an organization must ensure that their software is:
Toward the end of the webinar, Amit said, “The importance of digital trust in software supply chains and in particular AI models these days has never been greater.” To that effect, he announced a major evolution in software trust thanks to DigiCert’s new partnership with ReversingLabs. DigiCert has integrated ReversingLabs’ advanced binary analysis and threat detection into DigiCert® Software Trust Manager’s workflows to ensure the software is free of malware, tampering and other CVEs within a single pane of glass that an organization can centrally control. This integration also generates a comprehensive SBOM.
DigiCert Software Trust Manager provides full protection of private keys along with all the controls and standards needed in a mature software trust solution. Amit went on to say that this joint solution can be summarized in three words: inspect, sign and ship.
Want to learn more about how to achieve digital trust throughout your software supply chain? Watch the webinar here: https://www.digicert.com/about/webinars/the-ai-model-impact-on-the-software-supply-chain
Learn more about DigiCert Software Trust Manager at https://www.digicert.com/software-trust-manager.