Securing the Software Supply Chain

How to scope, plan, and execute an effective supply chain security initiative.

Supply Chain is Latest Land Grab for Cyber Attackers

Software supply chain attacks such as those on Kaseya and SolarWinds made headlines. Yet they were not the first occurrences of such attacks. In 2009, Operation Aurora aimed to compromise legitimate software vendors such as Adobe and Akamai in order to tamper with their software and potentially infect millions of organizations worldwide.

This vector of compromising the supply chain is a huge opportunity for attackers, as it is enough to penetrate one organization in order to gain control over other entities and conduct damage on a global scale. Another reason for hackers’ appetite around this attack vector is that it’s very hard to detect. Over time, it’s become almost impossible for software vendors to maintain integrity over their code base, and they are struggling to prove that their code isn’t tampered with. On the other hand, software consumers have no good solutions for verifying that the legitimate software they use is not embedded with malicious code.

Security Industry Falls Short

The security industry is not coping well with supply chain attacks. It’s extremely hard to detect malicious code embedded within legitimate software; and commonly used techniques like sandboxing, signatures and machine learning are falling short at identifying such attacks. This attack vector deserves a different point of view and its own dedicated security approach.

What the Software Supply Chain Looks Like

While every organization is unique, there are general commonalities between what their software supply chains typically look like:

Securing Software Releases: Public Releases and Cloud-Based Deployment

Public release

1. Scan your software for any embedded malicious code before releasing it.
2. Monitor your software release dynamically to detect second-stage payloads, a common theme in most supply chain attacks.
3. Compare your software release with the previous version to detect any major differences. In most supply chain attacks, there were major additions to the software capabilities that did not appear in the previous release.
4. Make sure to produce a Software Bill of Materials (SBOM) together with your software, as organizations are increasingly demanding it from their vendors.
5. Scanning your software release is especially important because it’s the last stage before releasing your software to clients, and you will be able to detect tampering in multiple stages of the development process (dev, build, delivery).
6. Apply security controls during the SDLC (Software Development Lifecycle), namely implementing strict access management for developers, and using software integrity solutions such as in-toto.

Cloud-based deployment

1. Follow the recent Presidential Executive Order recommendation, “Continuous monitoring of production systems for cyber incidents, as well as automatic threat blocking when an exploit is confirmed to target a previously known or unknown vulnerability.”
2. Deploy a runtime security solution on your production environment, both on cloud and on-premise. It will function as a safety net for any tampering or vulnerability that was missed during the development process by detecting threats in real-time.
3. Make sure that your runtime security solution is suitable for running in your environment. Many solutions claim to support Linux platforms but fall short in detecting Linux threats.
4. Make sure that your runtime security solution can identify malicious code and malicious activity such as shell commands, and allows you to conduct forensic analysis to discover the root cause of the attack in order to prevent the attack from repeating.
5. Apply security controls during the SDLC (Software Development Lifecycle), namely implementing strict access management for developers, and using software integrity solutions such as in-toto.

Securing Software Consumption: Installable Software or Third-Part Code

1. Installable software
   1. Request a Software Bill of Materials (SBOM) from your software vendor as per the recent Presidential Executive Order.
   2. Verify incoming software for any malicious code by using a file scanning solution (such as a malware analysis platform or Sandbox).
   3. Make sure your file scanning solution is not only based on behavior analysis or signatures, so that it will also be able to detect software tampering.
   4. Best practice is to integrate file scanning into the place where IT ingests software into the organization, such as Remote Management (RMM), MDM, SCCM or patch management solutions; so you can make sure you’re not compromised before deploying the risky software across your organization.
2. Third-party code
   1. Use a dependency scanning solution that can advise your development teams to select secure and reputable open-source libraries and containers.
   2. Make sure that the dependency scanning solution you pick can help you detect Zero-Day vulnerabilities, not just known vulnerabilities.
   3. Your dependency management solution should have basic capabilities to detect malicious code, such as detecting typo squatting techniques and known malicious libraries.

Summary

Supply chain attacks are unfortunately here to stay and will be one of the most dominant attack vectors in the next few years.

Organizations should plan a strategy for securing all aspects of the software supply chain, including software consumption (installable software, third party code) and release (public releases and cloud-based deployments).

Itai Tevet

Once led a government CERT. Now CEO at Intezer, changing the way we investigate and respond to cybersecurity incidents.