Cybreach Consulting Prendre RDV
Back to articles
Vulnerabilities

Supply chain security: dependencies, packages and third-party integration

The software supply chain encompasses everything that makes up a software beyond the development team's code: open source dependencies, build and CI/CD tools, container images, IDE plugins, third-party integrations. A compromise at any link in this chain can introduce malicious code into software that itself has no vulnerabilities. Supply chain attacks are particularly difficult to detect because they pass through trusted channels.

Compromised dependencies

Compromised dependency incidents have become frequent. event-stream (npm, 2018): a maintainer transfers the package to an attacker who adds malicious code targeting Bitcoin wallets. XZ Utils (2024): a contributor infiltrates the project for two years before introducing a backdoor in the SSH daemon via a compression dependency. polyfill.io (2024): a popular CDN is acquired and starts distributing malicious code to millions of sites. Colors and faker.js (2022): a maintainer deliberately sabotages their own packages.

Package typosquatting

Typosquatting consists of publishing a malicious package with a name similar to a popular legitimate package. A developer making a typo when installing a dependency may install the malicious package. Real examples: lodash vs lo-dash, cross-env vs crossenv, express vs expres. These malicious packages generally execute code during installation (postinstall in package.json).

Dependency confusion

Dependency confusion exploits the way package managers resolve dependencies between public and private registries. If an organisation uses a private registry (Artifactory, Azure Artifacts) with internal packages, and an attacker publishes a package with the same name on the public npm/PyPI/NuGet registry with a higher version number, some package managers may prefer the public package. Researcher Alex Birsan demonstrated this attack in 2021 against dozens of companies.

SBOM and dependency vulnerability management

A SBOM (Software Bill of Materials) is an exhaustive inventory of all components of a software. It allows quickly knowing whether a published CVE vulnerability affects any of the components used. Software composition analysis (SCA) tools like Dependabot (GitHub), Snyk, or OWASP Dependency-Check automate detection of vulnerable dependencies.

Vulnerable dependency audit

# npm : audit des vulnérabilités
npm audit
npm audit fix  # Corriger automatiquement

# Python
pip-audit

# Générer un SBOM (CycloneDX)
cyclonedx-py requirements requirements.txt

# Verrouiller les versions exactes
npm ci  # Utilise package-lock.json (versions exactes)
# Au lieu de npm install (peut installer des versions différentes)

Third-party integrations

Third-party scripts loaded from external CDNs (analytics, chat, maps) represent a supply chain risk. A compromised third-party script runs with all the host page's rights: it can read the DOM, submit forms, access cookies (if not HttpOnly), and exfiltrate data. Protection: use Subresource Integrity (SRI) for external scripts, self-host critical scripts, and use a strict CSP.

Subresource Integrity (SRI) for external scripts

<!-- Le navigateur vérifie que le hash du script téléchargé correspond -->
<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

<!-- Si le hash ne correspond pas (script modifié), le navigateur bloque l'exécution -->

A question after reading?

Want to assess your software supply chain security? Send a message.

Or book a 30-minute scoping call directly

Book a call