Software Supply Chain Security
Since the SolarWinds attack (2020) the term is omnipresent. Maybe the Stuxnet attack 2009/2010 on Siemens Step 7 PLCs in Iran has been the first prominent incident of that sort. But real action followed in 2020 with the SUNBURST event with the Executive Order 14028, that forced every software vendor providing services to US agencies to provide SBOMs, establishing a minimum security standard for software sold to the US government and to improve detection, investigation and sharing of cyber incident information between the government agencies and the private sector. Since these days also Zero Trust Architectures accelerate in the governmental area.
To learn more about the nature of such attacks, see peak into the following artcles:
The SolarWinds attack, codenamed SUNBURST by researchers, represents one of the most sophisticated and impactful software supply chain compromises in history. The attack’s core approach was to breach the network of SolarWinds, a network management software provider, and inject highly sophisticated malicious code directly into the build environment for their flagship product, Orion. This method of embedding malware into a legitimate, trusted software update is known as a Tainted Artifact attack.
The malicious code was meticulously inserted into the Orion source code repository. During the standard build process, the malware was compiled alongside the genuine software and digitally signed with SolarWinds’ own private keys, making the resulting trojanized update appear completely legitimate to all security tools and systems. The attackers achieved deep penetration and patient reconnaissance, distributing the contaminated updates to approximately 18,000 of SolarWinds’ customers—including government agencies, defense contractors, and major technology firms—between March and June 2020.
The effect of the SUNBURST attack was profound, exploiting the implicit trust inherent in vendor updates. Once installed, the malicious update remained dormant for weeks before discreetly activating a back door, allowing the attackers to gain persistent, privileged access to highly sensitive internal networks. The incident underscored the devastating potential of supply chain compromise, where an attacker needs only to compromise a single upstream vendor to subsequently breach thousands of high-value downstream targets, fundamentally shifting the focus of cybersecurity from perimeter defense to artifact and pipeline integrity.
Maybe the most prominent, widespread attack that illustrates the dependency risk has been the Log4Shell incident 2021. This vulnerability exposed the catastrophic fragility inherent in modern software’s reliance on nested open-source components.
The Log4Shell vulnerability (CVE-2021-44228) was an extreme example of a Vulnerable Dependency attack. It centered on the ubiquitous Java logging library, Log4j, used by millions of applications globally. The vulnerability stemmed from an obscure feature within the logger that allowed it to perform lookups via the JNDI (Java Naming and Directory Interface) protocol. An attacker could exploit this by simply injecting a specially crafted string (containing a reference to a malicious external server) into any log input—such as a search box, a user agent header, or a username field. When Log4j logged this string, it would interpret the lookup, reach out to the attacker’s server, and execute remote code (RCE) on the victim’s system, all without authentication.
The effect of Log4Shell was immediate and systemic chaos across the digital landscape. Because Log4j was so deeply embedded, often many layers deep as a transitive dependency, most organizations were unaware they were using it. This resulted in an unprecedented global effort to discover, triage, and patch vulnerable systems, impacting major cloud providers, enterprise applications, and countless proprietary software stacks. The attack demonstrated that control over the software supply chain is meaningless if a single, foundational component is compromised, highlighting the critical necessity of Software Composition Analysis (SCA) and maintaining a complete Software Bill of Materials (SBOM) to gain visibility into the dependency graph.
The Shai-Hulud attack, see details in our consulting arm’s (EACG) description, has been a sophisticated supply chain attack worm targeting the npm ecosystem (Node.js packages) early to mid of September 2025. It evolved dependency compromise playbook by incorporating a self-propagating element, making it far more dangerous than typical credential-stealing attacks.
The approach of the Shai-Hulud attack was two-fold. First, it leveraged malicious npm packages to steal developer credentials and tokens, exporting them to public repositories. However, the critical escalation was the introduction of a worm element. After compromising a system using the initial tokens, the worm used those credentials to spread to other private repositories accessible to the compromised account. It injected itself into new projects by adding bundle.js as a postinstall script within the package.json file. This ensured the malicious actions were executed and that the worm achieved persistence in its own branches with dedicated workflows.
The effect of the Shai-Hulud worm went beyond simple credential theft. Once established in a new repository, it attempted to convert or clone private repositories into public versions. Crucially, it injected itself into allpackages it could access and then published these infected packages back to the public registry. This created a rapid, exponential spread across the supply chain, turning victims into unwitting vectors for further attacks. The incident served as a stark warning about the risks associated with the default trusting nature of package managers and the vital need for integrity checks and package proxy servers to vet dependencies before they are executed in the build environment.
Want to learn more about Software Supply Chain Security and how to protect yourself?
Understand how TrustSource Platform protects you from different attack types
The base of all sort of protection is transparency of the attack surface. This is why EO 14028 and EU CRA require every software supplier to provide SBOMs.
TrustSource developed an open source scanning solution that supports all types of assessment and analysis to provide sound and comprehensive Software Bill of Materials (SBOM). ts-scan really builds the software artifact for composition assessment and does not only read the assembly lists. This allows to catalogue all and everything that is used to create the observed build artifact, including all transitive dependencies. See here for more information.
ts-scan is designed as single pane of glass for all sorts of assessments: docker containers, seeking 3rd party binaries for known malware, assess file structures or convert SBOMs from one SBOM standard to the other, supporting CycloneDX 1.4, 1.6 and SPDX 2.2 and 2.3 (and our format). All in one tool keeping it simple to manage and maintain.
How TrustSource supports you:
TrustSource allows you to activate a “version jump” detection.
Nowadays modern CI/CD-pipelines will start building upon each check-in of new code. This is when a new configuration appears, when dependencies will be pulled by the package manager. ts-scan or any 3rd party scanner will create a SBOM of the new artifact. TrustSource will then assess the versions used in this build against the versions of the last build.
To be successful, dependency attacks tend to use higher version counts, especially, when the target is unknown. Thus, a standard upgrade would be a v1.2 to a v2.0.x, or v6.3 to a 7.1. Given TrustSource identifies a v8.0 or v20.1 following a v5.3.4 – or any other, unusual version increase – it will alert the project manager of the artifact.
What is a Dependency Confusion Attack?
A dependency confusion attack is a supply chain compromise that exploits how modern package managers (like npm, PyPI, or NuGet) resolve software dependencies when a package name is ambiguous or exists in both a private, internal repository and a public repository.
The attack works by an adversary identifying a package name that a target company uses internally (e.g., @acme/utils) but has never published publicly. The attacker then uploads a malicious package with the exact same name to the public repository (e.g., npmjs.com), but with a much higher version number.
During a routine build or installation, the package manager checks both the internal and public repositories. Due to a default preference for the highest available version, or poorly configured build tools, the system pulls the malicious, high-versioned package from the public repository instead of the legitimate, internal package. This confusion allows the attacker’s code to be executed within the victim’s secure build environment, often leading to network reconnaissance, credential theft, or the establishment of a persistent back door.
What are OpenSSF Scorecards?
OpenSSF Scorecards are a set of automated security health metrics for open-source projects. Developed by the Open Source Security Foundation (OpenSSF), their primary goal is to quickly and objectively assess the security posture of an open-source dependency based on observable security practices and configurations. Each scorecard assigns a pass/fail grade or a numerical score across various automated checks, such such as whether the project enforces signed commits, uses static analysis (SAST), has branch protection enabled, or undergoes regular fuzzing.
In the context of Software Supply Chain Security, Scorecards are invaluable because they help consumers of open-source software make informed trust decisions. Since over 90% of modern codebases rely on OSS, security teams must evaluate the quality of their upstream dependencies. Instead of manually inspecting thousands of projects, Scorecards provide a standardized, scalable method for grading the hygiene of a package. This allows automated governance systems to flag low-scoring dependencies for manual review or, following a Zero Trust principle, automatically reject them from inclusion in high-security applications, thereby mitigating the risk of incorporating vulnerable or poorly maintained components into the enterprise supply chain.
OpenSSF Scorecard
TrustSource heavily leverages scorecards:
- We pull scorecards for every open source component. If they are not yet rated, you may execute a test that TrustSource will execute for you.
- Given you want to execute the scorecard test on your own repository, you may allow TrustSource access to execute the test on your repo. Read here how to arrange that.
- We collect all scorecard information, allowing to show score developments over time.
- You may filter your SBOM for weak scorecards for further assessments
Often several hundred components are combined to make an artifact. It is a huge effort to assess and monitor all components for their supply chain security efforts. This is why TrustSource takes responsibility for that task. We assess all components of your SBOM and execute the scorecard checks where required for you.
The results can be seen in the Scorecard Report. The report provides you with the summary of all scores in your SBOM and compares this to the average distribution across all projects in the platform. This gives you an indication of where you reside in the overall supply chain security and how vulnerable your code base may be to supply chain attacks.
What is a distribution attack?
In this approach the attacker exchanges an original binary with his maliciously manipulated binary. Typically this is must not be the exact deliverable but an underlying supporting element, e.g. a container image or some supporting infrastructure or common open source components.
How TrustSource protects you
TrustSource allows to link particular binaries, identified through hashes, to your SBOMs. Each release automatically generates a key, that you may integrate in your app or solution. With this key it is possible to call a TrustSource API and verify the checksums, SBOMs and Notice Files together with the binaries.
Thus, your customer will always have a chance to see, whether he is using the original or manipulated assets.