To help investors evaluate the cybersecurity risk of companies they may want to invest in, the US Securities and Exchange Commission (SEC) on December 15 2023 implemented a requirement for public companies to disclose:

  • Material cybersecurity incidents four business days after a public company determines the incident is material.
  • Cybersecurity risk management, strategy, and governance on an annual basis.

While each company will have their own specific cybersecurity practices and processes, they generally (and traditionally) tend to fall into three domains:

  • AppSec – application security 
  • InfoSec – system and data security
  • Vendor Security – key contractor and supplier security stance

Each of these areas is both broad and deep, involving numerous ways to measure and monitor risk that should be included in any SEC cybersecurity disclosure. The bad news is that even  such a comprehensive report would still be missing a key cyberattack vector, namely the software supply chain. 

Software supply chain security falls into the cracks between vendor security (open source authors as suppliers of third party software are your vendors, but they won’t be filling in your questionnaires) and AppSec, where most organizations are only concerned with open source vulnerabilities, which is merely the tip of the supply-chain-security iceberg of attack vectors.

For example, just in the past year there have been numerous “non-traditional” exploits, including:

  • 3CX is a well-known provider of VoIP software. In April, a software supply chain attack that compromised 3CX’s Mac and Windows client installers, impacting up to 600,000 users. This month-long, state-actor-led attack prompted 3CX to urge users to uninstall compromised apps and migrate to safer frameworks.
  • MOVEit – Progress provides MOVEit Transfer, which is managed file transfer software. In June, a zero-day vulnerability allowed hackers to compromise the software with a credential stealer that has led to a gigantic chain of record-breaking breaches affecting >1000 businesses and >60M individuals, eventually costing businesses >$9.9B in damages.
  • JetBrains TeamCity has been used to build everything from websites to banking systems, but a recently discovered vulnerability has been targeted by bad actors who upload malware (typically a backdoor exploit) to public-facing TeamCity servers, compromising them in a similar manner to Solarwinds. In other words, any software built on a compromised TeamCity implementation also becomes compromised, and then gets propagated downstream to its customers, compromising them. 

Software Supply Chain Security Metrics

In order to address these new vectors of attack, CISOs need to prioritize measuring (and enforcing) key initiatives around securing the software supply chain, such as:

  • # of incidents of suspicious open source flagged/quarantined
  • # of malware incidents originating from open source software
  • % progress toward implementing a SLSA Build Level 3 hardened build system
  • # of violations of supply chain security rules (i.e. missing software attestation, missing provenance attestation, unsigned package, packages with critical vulnerabilities, etc)

Let’s take a closer look at each of these measures, starting with quarantining suspicious software. 

Most organizations have some kind of software in place such as a Software Composition Analysis (SCA) tool and/or Static Application Security Testing (SAST) tool to help understand if the open source code they are importing is free of vulnerabilities and safe for use. 

When applied to imported source code, vulnerability and malware analysis is fairly accurate. However, most organizations import prebuilt open source packages which can lead to too many: 

  • False positives, where a codebase includes unused dependencies.
  • False negatives, where dependencies not explicitly defined in the scanned manifest/definition file may be missed.
  • Instances of unidentified malware in prebuilt binary packages since binary scanners can be problematic. 

The result is often a deluge of quarantined suspects resulting in an escalating number of exceptions to policy rules to free these suspects following minimal (if any) due diligence. 

Organizations that circumvent these drawbacks by importing source code will need to build their open source packages themselves. But to avoid the specter of the Solarwinds hack, you’ll need to build all packages using a hardened, declarative build system, such as that defined by Supply chain Levels for Software Artifacts (SLSA) Build Level 3, which requires:

  • Pre-scripted, parameterless builds to ensure bad actors can’t get access to/edit build scripts.
  • Build environments that are ephemeral, isolated, and hermetically sealed (i.e., no access to the internet) ensure against bad actors compromising the build process.
  • Isolated signing service to ensure against bad actors accessing secrets used to sign the provenance.
  • Signed software attestations that show where the code was sourced from, and how the package was built.

With such a service in place, it becomes possible to implement (and measure exceptions to) security rules for open source packages. For example, any package consumed by a step in the software development process should:

  • Have its software attestation validated
  • Have its signature verified
  • Have its vulnerability status checked

And so on. Exceptions to policy can then be flagged and measured to improve software supply chain security and avoid the kinds of attacks that compromised 3CX, MOVEit and TeamCity.

Conclusions – Measuring Software Supply Chain Security

Measuring software supply chain security means measuring more than just traditional AppSec metrics, such as # of known vulnerabilities, # of unapplied patches, time to fix critical vulnerabilities, and so on. Overly focusing on vulnerabilities, as well as counting on traditional tools to catch exploits in binary packages are two of the key reasons that software supply chain attacks have exploded in the past few years. Even software build and delivery systems can no longer be assumed immune to infection.

But implementing a solution to measure and enforce security in the software supply chain is a time and resource intensive undertaking. This is why we built the ActiveState Platform, which will automatically build your open source dependencies from vetted source code using a SLSA Level 3 hardened build service, and generate a software attestation for each. As a result, you can add software supply chain security metrics to your SEC cybersecurity disclosure in a matter of days. 

Next Steps:

Watch our webinar SAST, DAST and IAST Are Not Enough (to Cover Your Ass) to learn how you can protect your organization against new attack vectors.