Securing the Software Supply Chain - Intezer

Securing the Software Supply Chain

Written by Itai Tevet

    Join our free community
    Get started
    Share Article

    Top Blogs

    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 have made headlines. Yet they are 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:


    1. Public release – releasing installable software or code that is consumed by other organizations around the world or within the same organization, running directly on the customers’ environment.
    2. Cloud-based deployment releasing SaaS-based software that is deployed on the organization’s cloud or on-premise servers, likely containing sensitive customer data. The software is usually consumed via browser and the organization’s code is not running directly on the customer’s environment.


    1. Installable software (Adobe Photoshop, accounting software, IT software like SolarWinds) – includes freeware and procured software and is usually deployed by IT or individuals.
    2. Third party code – most companies have an internal development org within, both software vendors and companies who are not software vendors but are developing software for internal purposes (banks). Development teams are constantly ingesting software by importing third party code (open-source libs, container images).

    How Supply Chain Attacks Happen

    • Compromising the vendor’s proprietary source code – compromising the SCM (Software Configuration Management), compromising a developer machine, or via a malicious insider (developer).
    • Compromising the vendor’s build process – compromising the build system or build machines.
    • Compromising third party code that the vendor is importing – compromising a third party library or code (80% of an average application is third party code).
    • Compromising the delivery process – compromising the delivery mechanism, such as replacing software releases in the distribution website or compromising the automated update mechanism.
    • Exploiting a vulnerability in the software – exploiting a deployed or installed application via a known or unknown vulnerability to execute malicious code in runtime.

    Securing the Supply Chain

    The vast majority of organizations have a supply chain that includes all of the above categories, as most companies develop software either for internal or external use, and consume software by themselves. This is why it’s important that a supply chain security initiative includes security controls for each —software consumption (installable software, third party code) and software release (public releases and cloud-based deployments). Here’s a quick start guideline we created for securing each of these categories:

    Securing Software Releases

    1. 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 increasinglyly 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.
    1. 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

    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.
    1. 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.


    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 detect, analyze and respond to malware.

    © 2022 All rights reserved
    Analyze malware and unknown files for freeAnalyze malware for free