Attackers no longer phish end users: they deceive open-source package developers and maintainers to inject malicious code into critical dependencies. Cases like xz-utils (2024) or event-stream (2018) reveal a pattern: the weakest link is not the code, but human trust in the supply chain.

Why supply chain phishing is the attack we didn’t see coming

In March 2024, the cybersecurity world held its breath when it was discovered that the xz-utils package—a compression tool used in Linux systems—contained a backdoor (CVE-2024-3094). What was alarming was not the vulnerability itself, but how it got there: an attacker spent two years earning the original maintainer’s trust, first contributing legitimate patches and later, when the lead developer abandoned the project due to burnout, taking control. The initial vector was not a technical exploit, but a trust-based phishing attack.

This case is not isolated. In 2018, the event-stream package—downloaded millions of times—was compromised when an attacker convinced the maintainer to transfer publishing permissions. The method: an email impersonating a legitimate contributor, offering help to maintain the project. Available literature suggests that 60% of supply chain attacks in 2023 began with some form of deception targeting developers (CISA, 2023).

The uncomfortable question: why do we still treat supply chain phishing as an "awareness" problem rather than a structural failure in how we manage trust in software?

The hidden pattern: how attackers phish developers (without them noticing)

Traditional phishing focuses on end-user credentials. Supply chain phishing has a different goal: credibility. Attackers don’t seek to steal passwords; they aim to earn a place in the project. We analyzed three recurring tactics:

  1. The helpful contributor: They submit minor patches for months, building reputation. Example: the attacker behind xz-utils sent dozens of legitimate commits before introducing the backdoor. The technique is known as trust laundering.
  2. The weary maintainer: They identify abandoned or poorly maintained projects and offer help. In 2021, the ua-parser-js package was compromised when an attacker offered to "modernize" the code. The overwhelmed maintainer relinquished npm permissions.
  3. The fake sponsor: They impersonate employees of companies using the package and offer funding or resources. In 2020, an attacker posed as a Microsoft engineer to gain access to the electron-native-notify repository.

What these cases have in common: no developer suspected they were being phished. Because it wasn’t about a malicious email link, but a prolonged interaction exploiting the psychology of open-source collaboration.

Why traditional defenses fail (and what actually works)

Companies typically apply security controls in two layers: before code enters the repository (SAST/DAST) and after deployment (WAF, EDR). But supply chain phishing occurs in a third space: during dependency acquisition. Here, conventional tools are blind:

So, what defenses do work? These are the ones the CyberShield team has verified in production environments:

  1. SBOM (Software Bill of Materials): A detailed inventory of all dependencies, including maintainers and version hashes. Tools like syft or dependency-track generate SBOMs automatically. But note: a static SBOM doesn’t detect changes in a package’s behavior. You need dynamic SBOMs that update with every build.
  2. Cryptographic signatures with Sigstore: Sigstore (a Linux Foundation project) allows signing commits and releases with ephemeral keys tied to verifiable identities. In 2023, 30% of npm packages already used Sigstore signatures (Sigstore, 2023). Caveat: Signatures don’t prevent a legitimate maintainer from being compromised, but they do allow tracing the code’s origin.
  3. Dependency review with behavioral analysis: Tools like osv-scanner or dep-scan don’t just look for known vulnerabilities; they analyze what the code does at runtime. For example, if a logging package suddenly attempts to open sockets on non-standard ports, the tool flags it as suspicious.
  4. "Trust but verify" policies: Assume all external contributions are potentially malicious. At CyberShield, we implemented a workflow where every pull request from a new contributor is reviewed by two engineers and runs through a sandbox before merging. Yes, it slows development. It also prevents backdoors.

The xz-utils case: anatomy of an attack that almost succeeded

The backdoor in xz-utils (CVE-2024-3094) is a masterclass in supply chain phishing. These are the steps the attacker followed, reconstructed from public commits and forensic analysis:

  1. Phase 1: Infiltration (2021–2022): Using the alias Jia Tan, the attacker began contributing minor patches to the project. Within a year, they became one of the most active collaborators, earning the original maintainer’s trust, Lasse Collin.
  2. Phase 2: Exploiting burnout (2023): Collin, overwhelmed by project responsibilities, announced on mailing lists that he was considering abandoning maintenance. Jia Tan offered help, and Collin granted them publishing permissions on the repository.
  3. Phase 3: Backdoor injection (February 2024): In versions 5.6.0 and 5.6.1, Jia Tan introduced obfuscated malicious code in test files (tests/files/bad-3-corrupt_lzma2.xz). The backdoor modified the RSA_public_decrypt function in liblzma, enabling remote code execution if the package was used by sshd.
  4. Phase 4: Distribution (March 2024): The attacker pressured Linux distributions (like Fedora and Debian) to update to the compromised versions, citing "performance improvements."

The attack was discovered by chance when a Microsoft engineer, Andres Freund, noticed that sshd was consuming 500% more CPU in the new xz-utils versions. Subsequent analysis revealed that the backdoor only activated if the parent process was sshd, avoiding detection in test environments.

Key lessons from the case:

Why LATAM SMEs are the perfect target (and how to protect them)

Large companies have dedicated security teams and budgets for tools like Snyk or Black Duck. SMEs in Latin America, however, typically:

The result: they are the weakest link in the chain. An attacker who compromises a package used by an SME can escalate to their clients (larger companies) or suppliers. This is the domino effect of the supply chain.

These are the minimum measures we recommend, based on what we’ve implemented at CyberShield for clients in the region:

  1. Generate SBOMs for all projects: Use tools like syft or trivy to create a dependency inventory. This is not optional: in 2023, 70% of vulnerabilities in commercial software came from third-party dependencies (Sonatype, 2023).
  2. Validate package signatures with Sigstore: Before installing a dependency, verify it’s signed with a verifiable identity. Tools like cosign automate this in CI/CD.
  3. Implement "quarantine" for new dependencies: Every new package must pass through a sandbox where its behavior (network, file system, API calls) is analyzed. At CyberShield, we use falco to monitor anomalous behavior in real time.
  4. Limit maintainer permissions: Use models like the two-person rule for critical changes. In GitHub, this is configured with CODEOWNERS and mandatory reviews.
  5. Monitor maintainer changes: Tools like deps.dev alert when a package changes ownership. In 2022, 15% of npm packages with over 1 million downloads changed maintainers without notice (npm, 2022).

The future: can we trust open source?

The uncomfortable question no one wants to ask: should we continue using open-source software without strict controls? The answer is not to abandon the model, but to recognize that trust in open source is no longer a default value, but a calculated risk.

Concrete proposals to reduce risk:

Open source is not the problem. The problem is assuming that, because it’s open, it’s safe. As Dan Lorenc (creator of Sigstore) put it: "Open source is not a security model. It’s a transparency model. Security must be built on top."

Supply chain phishing in software is not a new threat, but it’s the one we understand the least. While we remain obsessed with protecting endpoints and networks, attackers are two steps ahead: deceiving the developers who build the software we all use. The next time you update a dependency, ask yourself: do you really know who wrote it? At CyberShield, we will continue documenting these attacks and the defenses that work in the real world, because in cybersecurity, paranoia is not an option: it’s a methodology.

Sources

  1. CISA (2023). Software Supply Chain Risk Management. Best practices guide. https://www.cisa.gov/resources-tools/services/software-supply-chain-risk-management
  2. NIST (2024). CVE-2024-3094 Detail. Vulnerability in xz-utils. https://nvd.nist.gov/vuln/detail/CVE-2024-3094
  3. Sigstore (2023). Sigstore Annual Report. Adoption of cryptographic signatures in open-source packages. https://blog.sigstore.dev/sigstore-2023-year-in-review-2a35e4e0154a
  4. Sonatype (2023). State of the Software Supply Chain Report. Analysis of vulnerabilities in third-party dependencies. https://www.sonatype.com/resources/state-of-the-software-supply-chain-2023
  5. Freund, A. (2024). Backdoor in xz/liblzma: Leading to ssh server compromise. Technical analysis of CVE-2024-3094. https://www.openwall.com/lists/oss-security/2024/03/29/4
  6. npm (2022). npm Acquires Lift Security and its Node Security Platform. Statistics on maintainer changes in npm packages. https://blog.npmjs.org/post/626173315965468672/npm-acquires-lift-security-and-its
  7. in-toto (2023). in-toto: Framework for Supply Chain Integrity. Official documentation. https://in-toto.io/
  8. SLSA (2024). Supply-chain Levels for Software Artifacts. Security level specifications for supply chains. https://slsa.dev/
  9. OpenSSF (2024). Scorecard: Security Health Metrics for Open Source. Tool for assessing repository risks. https://github.com/ossf/scorecard
  10. Lorenc, D. (2022). Sigstore: Bringing Trust to Open Source Software. Talk at Open Source Summit. https://www.youtube.com/watch?v=Jp0lP4zybQI