Software Supply-Chain Security: Protecting What You Did Not Write

Modern software is rarely built from scratch. A typical application depends on dozens - sometimes hundreds - of open-source libraries, third-party APIs, and CI/CD pipeline tools. Each of those dependencies is a potential entry point for an attacker. Supply-chain attacks exploit this reality: rather than attacking your application directly, adversaries compromise something upstream that your application trusts.

The consequences can be severe. When a widely-used package is compromised, every project that depends on it inherits the infection - often without any action or error on the part of the development team.

How Supply-Chain Attacks Work

There are several distinct patterns that show up repeatedly in supply-chain incidents:

• Dependency confusion: an attacker publishes a malicious package to a public registry with the same name as an internal package, exploiting the way package managers resolve names. The build system fetches the attacker’s version instead of the legitimate one.
• Typosquatting: malicious packages with names nearly identical to popular libraries (a transposed letter, an added hyphen) wait for developers to mistype an install command.
• Compromised maintainer accounts: attackers gain access to the credentials of a legitimate open-source maintainer and push a malicious update to an otherwise trusted package.
• Malicious CI/CD pipeline plugins: build and deployment pipelines rely on plugins and integrations that have elevated access to source code, secrets, and production environments. A compromised plugin can exfiltrate secrets or tamper with build artefacts.
• Trojanised build tools: attackers target the infrastructure used to compile and package software, injecting malicious code into binaries that appears identical to legitimate output.

Practical Defences for Development Teams

Supply-chain security does not require a separate team or a new budget line. Most of the effective controls can be integrated into existing development workflows.

Use a Software Bill of Materials (SBOM). An SBOM is a structured inventory of every component in your software - libraries, frameworks, tools, and their versions. Generating an SBOM as part of your build process gives you a clear picture of your dependency tree and makes it far easier to identify when a vulnerable component needs to be updated.

Pin dependency versions. Allowing package managers to automatically pull the latest version of a dependency creates a window for supply-chain attacks. Pin specific, reviewed versions and update them deliberately rather than automatically.

Verify package integrity. Most package registries now support checksums and cryptographic signatures. Verify hashes on download and, where available, check maintainer signatures. Tools like Sigstore are making this significantly more accessible for open-source ecosystems.

Audit dependencies regularly. Tools like npm audit, pip-audit, and Dependabot can surface known vulnerabilities in your dependency tree automatically. Make dependency audits part of your CI pipeline, not an occasional manual task.

Apply least privilege to your CI/CD environment. Build pipelines should have only the permissions they genuinely need. Secrets used for deployment should be scoped tightly and rotated regularly. Audit what your pipeline can access - it is often far more than necessary.

Vet new dependencies before adoption. Before adding a new library, check when it was last updated, how many maintainers it has, whether the maintainer accounts have security features like MFA enabled, and whether the package has a meaningful history of real usage. A new package with few downloads and an anonymous maintainer warrants extra scrutiny regardless of how convenient it looks.

The Bigger Picture

Supply-chain security is ultimately about trust boundaries. Every dependency you add is an implicit trust relationship. Being deliberate about those relationships - choosing well-maintained packages, monitoring for changes, and verifying what enters your build - does not eliminate risk, but it dramatically reduces the attack surface.

Organisations that treat security as part of the development lifecycle, rather than a review step at the end, are far better positioned to catch supply-chain risks early.

Unity Software Solution builds software with supply-chain hygiene as a standard practice - including dependency auditing, SBOM generation, and CI/CD hardening - so our clients ship products they can have genuine confidence in.