Open Source Security Guide

Most of the code an organisation ships was written by people it has never met, and most of that code arrives as transitive dependencies nobody chose on purpose. Open source risk is no longer only about known vulnerabilities: malicious packages, hijacked maintainer accounts, abandoned projects and stolen publishing tokens now sit alongside unpatched CVEs as routine causes of compromise. This guide covers how to consume open source safely: inventory with SCA and SBOMs, vulnerability data and triage, choosing dependencies, pinning and provenance, malicious package defences, the identities behind publishing, and the governance (OSPO, policy, licences and the EU Cyber Resilience Act) that holds it together. It is for application security, platform engineering and OSPO teams. Build pipeline hardening is covered in the CI/CD Pipeline Identity Security Guide and model and dataset supply chains in the AI Supply Chain and AI-BOM Guide.

Key takeaways

• You cannot secure what you have not inventoried. Generate an SBOM for every build artefact, including transitive dependencies, and keep it queryable so you can answer "are we affected?" in minutes.
• Vulnerable and malicious are different problems. Known CVEs are handled by SCA and patching; malicious packages execute at install time and need admission controls, registry proxies and behaviour checks before code ever lands.
• Pin, lock and verify. Lockfiles with integrity hashes, actions pinned to commit SHAs and a single internal registry stop silent changes and dependency confusion.
• Publishing credentials are the new crown jewels. Many recent package compromises began with a stolen maintainer or CI token; trusted publishing with OIDC removes the long-lived token from the picture.
• Health matters as much as CVE counts. A dependency with one maintainer, no release in a year and no security policy is a risk even when the scanner is clean.

What open source risk actually consists of

Treating "open source risk" as one thing leads to one control (usually an SCA scanner) and blind spots elsewhere. Each risk type needs its own control and owner.

MITRE ATT&CK tracks the attacker side as T1195.001 Compromise Software Dependencies and Development Tools; its mitigations include pinning versions and Actions commit hashes (M1013) and pulling only from internal, vetted repositories (M1033).

Know what you run: SCA, SBOMs and vulnerability data

CISA describes an SBOM as "a nested inventory, a list of ingredients that make up software components". Two formats dominate, and most tools read and write both:

• Generate at build time: manifests list what you asked for; lockfiles and built artefacts show what you got, including transitive and vendored code.
• Cover containers: base images carry operating system packages that application SCA misses; scan the image too.
• Pair SBOMs with VEX: CISA describes a VEX document as an attestation stating whether a product is affected by a known vulnerability. VEX is how you tell customers, and your own triage queue, that a CVE in a bundled library is not exploitable in your product.
• Store SBOMs centrally: an SBOM in a build log is no use when the next Log4Shell-scale advisory lands. Index them so one query lists every product containing a component.

SCA tools: standalone or inside an ASPM platform

Software composition analysis comes as open source scanners (OSV-Scanner, OWASP Dependency-Check), registry-integrated features (GitHub Dependabot alerts and dependency review), commercial SCA products, and as one module of application security posture management (ASPM) platforms that also ingest SAST, secrets and cloud findings.

• Choose standalone SCA when you have one or two ecosystems and a small AppSec team; free tools plus Dependabot or Renovate cover a lot.
• Choose ASPM when you have many scanners producing duplicate findings across hundreds of repositories, and the problem is prioritisation and ownership rather than detection.
• Either way, test: transitive resolution accuracy in your ecosystems, reachability analysis, malicious package detection, licence detection, SPDX and CycloneDX export, and VEX support.

Vulnerability data and triage

Advisory databases differ in coverage and precision, and that drives false positives and missed findings.

• Prioritise by exploitability and reachability: combine KEV, EPSS (Exploit Prediction Scoring System), reachability and exposure; a critical CVE in code you never call ranks below a medium one in your request parser.
• Automate updates, but not blindly: Dependabot and Renovate raise update pull requests. Require tests to pass and never auto-merge brand-new releases of high-impact packages. The axios npm compromise showed auto-merging bots pulling a hijacked release into projects within minutes.
• Use a cooldown window: many malicious releases are removed within hours or days. Renovate's minimum release age setting, or a registry proxy rule, delays non-security updates without slowing urgent fixes.
• Set SLAs by severity and exposure and track them in the same way as operating system patching. See the Patch Management Guide.

Choosing dependencies and judging project health

The cheapest dependency to secure is the one you never add. The OpenSSF Concise Guide for Evaluating Open Source Software starts with "Consider Necessity", then checks authenticity (typosquats, forks, creation time), maintenance (significant activity and a release within the previous 12 months, more than one maintainer, ideally from different organisations), security practices, licence clarity, and, for higher-risk additions, installing the package in an isolated environment and inspecting install scripts and obfuscated code.

OpenSSF Scorecard automates much of this for projects hosted on GitHub. Each check scores 0 to 10 and carries a risk weight:

• Use scores as a gate, not a verdict: for example, an aggregate below 5 or any failing Critical check triggers review of a new direct dependency; record exceptions.
• Abandoned packages need an exit plan: replace, fork and maintain internally, or fund the maintainers. Doing nothing is also a decision; record it.
• Single-maintainer projects deserve extra scrutiny: one person is a single point of failure for both burnout and social engineering. The XZ Utils backdoor was planted by a contributor who spent years earning maintainer trust.

Pinning, lockfiles and provenance

Version ranges let a new upstream release enter your build unnoticed. Lockfiles record the exact version and a content hash, and strict install modes refuse to proceed if anything differs.

The tj-actions/changed-files compromise shows why tags are not enough: attackers repointed existing version tags at malicious code, and every workflow referencing a tag ran it.

Provenance and signatures

• SLSA Build track: L1 "Provenance exists" (catches mistakes, trivial to forge), L2 "Hosted build platform" (signed provenance, protects against tampering after the build), L3 "Hardened builds" (isolated builds, signing secrets kept from user-defined steps, protects against tampering during the build). Ask critical suppliers which level they meet.
• Sigstore: Cosign signs artefacts, Fulcio issues "a short-lived certificate bound to the provided identity and public key" after checking an OIDC token, and Rekor records the event in an append-only transparency log. Verification checks the certificate identity (for example, the expected repository and workflow), not just that some signature exists.
• Registry attestations: npm publishes provenance automatically for packages released through trusted publishing from GitHub Actions or GitLab CI/CD. Verify it where tooling allows, and treat sudden loss of provenance on a package that had it as a warning sign.

Malicious packages, typosquatting and dependency confusion

Malicious packages usually act at install or import time, hitting developer laptops and CI runners before any production scanner sees them. The target is almost always credentials: cloud keys, registry tokens, SSH keys and CI secrets.

• Typosquatting: names one character away from popular packages. Defence: a registry proxy that blocks packages below an age or popularity threshold, and the OpenSSF Malicious Packages feed (available through OSV).
• Dependency confusion: a package manager prefers a public package with the same name as an internal one, often because it has a higher version number. Defence: one internal registry that is authoritative for your namespaces, reserved scopes or prefixes on public registries, and no fallback from private to public for internal names. The PyTorch torchtriton attack used exactly this to steal SSH keys from nightly build users.
• Self-spreading worms: malware that steals a maintainer's publishing token and republishes every package that token can reach, as in the Shai-Hulud first wave. Defence: cooldowns, short-lived publishing credentials, and isolated build runners with no standing cloud credentials.
• Install-time containment: install dependencies in ephemeral runners without production credentials, disable lifecycle scripts where possible, and alert on package managers that spawn shells or connect to unapproved hosts (the sequence ATT&CK describes for detecting T1195.001).

Where identity fits: maintainers, publishing tokens and CI

A legitimate package becomes malicious when someone gains the right to publish it. That right is held by human maintainer accounts and by non-human identities: registry API tokens, CI secrets and workflow tokens. Protect them in the packages you publish, and ask the same of critical upstream projects.

• Trusted publishing: PyPI uses OpenID Connect to "exchange short-lived identity tokens between a trusted third-party service and PyPI"; the minted API token is valid for 15 minutes. npm trusted publishing supports GitHub Actions, GitLab CI/CD and CircleCI on hosted runners (npm CLI 11.5.1 or later), and npm strongly recommends then setting publishing access to "Require two-factor authentication and disallow tokens".
• Revoke what is left behind: the Ultralytics PyPI compromise combined a GitHub Actions injection with a leftover PyPI API token, and the Ledger Connect Kit compromise came from a former employee's npm access that was never removed. Inventory every publishing token and maintainer seat, and remove both at offboarding.
• Phishing-resistant MFA for maintainers: require it for anyone with publish or admin rights on registries and source hosting, and keep that group small.
• Least-privilege workflow tokens: set default GITHUB_TOKEN permissions to read, grant write per job, and never expose publishing credentials to workflows triggered by untrusted pull requests.

See the CI/CD Pipeline Identity Security Guide and the Secrets Management Guide. If a token is exposed, follow the Leaked Credential Response Playbook.

Governance: OSPO, policy, licences and the CRA

• Open source programme office (OSPO): owns the open source policy, approves exceptions, tracks critical dependencies and decides where to contribute fixes or funding upstream. Small organisations can give the role to one architect with a written policy; large ones need an OSPO with engineering, legal and security members.
• Policy contents: approved registries, admission criteria for new dependencies, patch SLAs, SBOM requirements, forking and vendoring rules, and rules for staff contributing upstream.
• Licence risk: permissive licences (MIT, Apache-2.0, BSD) rarely constrain use; strong copyleft (GPL family) can require source disclosure on distribution, and AGPL extends that to software offered over a network. Code with no licence grants no rights. Record SPDX identifiers, set allow, review and deny lists in SCA, and route conflicts to legal.
• EU Cyber Resilience Act: Regulation (EU) 2024/2847 requires manufacturers of products with digital elements to exercise due diligence on third-party components, including open source; the recitals mention checking security update history and known vulnerabilities in public databases. It creates a light-touch regime for open-source software stewards (organisations that support open source projects on a sustained basis), who cannot affix CE marking and are not subject to the regulation's administrative fines. Reporting obligations apply from 11 September 2026 and most other obligations from 11 December 2027.

Implementing an open source security programme

1. Inventory (weeks 1 to 4): turn on SCA and SBOM generation for every repository and image in report-only mode, and find the worst 20 components.
2. Single front door (weeks 3 to 8): stand up an internal registry proxy per ecosystem, point CI at it, block direct public registry access from build networks, and reserve internal names on public registries.
3. Lock and pin: require committed lockfiles and strict install commands in CI, and pin third-party actions to SHAs. Roll out repository by repository; rollback is a revert of the CI configuration.
4. Gate in audit mode, then enforce: run admission rules (malicious package match, licence deny list, health threshold, minimum release age) as warnings for a pilot group for two to four weeks, tune false positives, then block on new findings only so existing debt does not stop delivery.
5. Secure your own publishing: move every package you publish to trusted publishing, disallow tokens, revoke legacy tokens and require phishing-resistant MFA for maintainers.
6. Provenance: sign your releases with Sigstore and generate SLSA provenance; start verifying signatures and provenance on the dependencies and base images that support it.
7. Burn down and govern: set SLAs, assign owners to the worst components, and review abandoned and single-maintainer dependencies quarterly through the OSPO.

Detection and measurement

Log what CI resolved (package, registry, hash), registry proxy blocks and overrides, publishing events on your own packages and token creation on registries. Alert on installs that bypass the proxy, new publishing tokens, and releases that did not come from the expected workflow.

• SBOM coverage: percentage of production artefacts with a current SBOM stored centrally.
• Time to answer "are we affected?": minutes from a new critical advisory to a complete list of affected products.
• Remediation SLA attainment: share of reachable critical and high findings fixed within SLA, and median age of open findings.
• Front door enforcement: share of CI builds resolving only through the internal registry with a strict install.
• Dependency health: number of production dependencies that fail Maintained or have a single maintainer, trending down.
• Publishing hygiene: share of your published packages using trusted publishing with token publishing disallowed.

Common failure patterns

• Scanning only for CVEs: the SCA dashboard is green while a typosquat with a credential-stealing install script runs on every developer laptop.
• Floating references in CI: version ranges, mutable tags and @latest pull whatever upstream ships today, as every consumer of the compromised tj-actions tags found out.
• Private and public registries both in the search path: the classic dependency confusion setup, often left over from a developer convenience change.
• Long-lived publishing tokens in CI secrets: stolen once, reused for months and rarely revoked when people leave, as the Ultralytics and Ledger cases above show.
• SBOMs generated for compliance and never queried: they exist, but nobody can search them when the next critical advisory lands.

Framework mapping

Practitioner checklist

• Generate and centrally store SPDX or CycloneDX SBOMs for every production artefact and container image.
• Route every ecosystem through an internal registry proxy and block direct public registry access from CI.
• Require committed lockfiles, strict install commands and SHA-pinned GitHub Actions.
• Gate new direct dependencies on necessity, Scorecard health, licence and malicious package checks.
• Apply a minimum release age to non-security updates and never auto-merge new releases of high-impact packages.
• Prioritise findings with KEV, EPSS and reachability, and track SLAs by severity.
• Move your own packages to trusted publishing, disallow token publishing and revoke legacy tokens.
• Require phishing-resistant MFA for anyone with publish or admin rights on registries and repositories.
• Review abandoned and single-maintainer dependencies quarterly and record replace, fork or fund decisions.
• Map obligations under the EU Cyber Resilience Act if you place products with digital elements on the EU market.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• CISA: Software Bill of Materials (SBOM)
• OpenSSF SLSA: Security levels
• OpenSSF: Scorecard checks documentation
• OpenSSF: Concise Guide for Evaluating Open Source Software
• Sigstore: Overview
• PyPI: Trusted Publishers
• OSV: Data sources

Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · AI Supply Chain and AI-BOM Guide · Secrets Management Guide · AI Coding Agents Security Guide