Disclaimer: This article is general information, not legal, compliance or security consulting advice. arjankc.com.np is not a security vendor, auditor or consultancy, does not recommend or rank specific products or providers, and does not receive referral or affiliate fees. Federal policy and standards in this area changed several times in 2025 and 2026; check the primary sources linked below and speak to qualified security and legal professionals about your environment.

Last reviewed: 13 October 2026

Most enterprise software is assembled rather than written from scratch. A typical application pulls in open source libraries, container base images, build plugins, CI/CD actions and, increasingly, code suggested by AI coding assistants. Each of those inputs is part of the software supply chain, and each can be a way in for an attacker. This guide explains the standards and government guidance that shape software supply chain security for enterprises in 2026, how to manage vulnerabilities in third-party components, what changes when developers use AI assistants, and the criteria to use when evaluating software composition analysis (SCA) and SBOM tools.

What software supply chain security covers

Software supply chain security is the set of practices that give you confidence in three things:

  1. What is in the software: the components and their versions, licenses and known vulnerabilities.
  2. How it was built: that the artifact you run came from the expected source code through the expected build process and was not altered.
  3. How problems are handled: that vulnerabilities in components are found, assessed and fixed in a reasonable time, and that this is communicated to customers.

The SLSA project frames the risk well: an attacker can tamper at any link from source control through build, packaging and distribution, so scanning the source alone does not prove that the binary you deploy matches what was reviewed (SLSA, About SLSA).

The US policy picture in 2026

Executive Order 14028 (May 2021) pushed software supply chain security into federal procurement after the SolarWinds intrusion. It led NIST to publish the Secure Software Development Framework (SSDF), SP 800-218, and OMB to issue Memorandum M-22-18, which required agencies to collect a self-attestation from software producers using a common form developed by CISA.

Two later changes matter for anyone reading older guidance:

  • Executive Order 14306 (June 2025) amended EO 14144 of January 2025. It removed EO 14144’s plan for software producers to submit machine-readable attestations and supporting artifacts to CISA for central validation, and instead directed NIST to run an industry consortium on SSDF implementation and publish an updated SSDF (Federal Register, EO 14306).
  • OMB Memorandum M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies are no longer required to collect the common attestation form. They must still maintain complete software and hardware inventories and adopt risk-based assurance policies, and they may choose to use the attestation form or require a current SBOM on request (OMB M-26-05).

Meanwhile, NIST released SSDF version 1.2 (SP 800-218 Rev. 1) as an initial public draft on 17 December 2025, with comments closing on 30 January 2026. NIST’s SSDF publications page still lists it as a draft; version 1.1 (February 2022) remains the final edition (NIST CSRC, SSDF publications).

For private enterprises, none of this is a direct legal mandate, but it shapes what large customers and federal buyers ask for in contracts and security questionnaires. Expect requests for an SBOM, evidence of SSDF-aligned practices and a vulnerability disclosure process rather than a single standard form.

The building blocks at a glance

Table of five software supply chain building blocks: SBOM minimum elements, SLSA, NIST SSDF, VEX and the CISA KEV catalog, with publisher, the question each answers and status in October 2026

Chart: arjankc.com.np, from CISA, NIST and the OpenSSF SLSA specification. Status as of 13 October 2026.

SBOMs: an ingredients list for software

A software bill of materials (SBOM) is a formal, machine-readable inventory of the components in a piece of software and how they relate. It does not make software secure by itself; it makes it possible to answer “are we affected?” quickly when a new vulnerability is published.

Minimum elements

The original baseline was the NTIA’s 2021 Minimum Elements for a Software Bill of Materials. On 29 July 2026, CISA, the NSA, the FBI and international partners published 2026 Minimum Elements for an SBOM, which updates and replaces the NTIA document and applies to all software, including open source, AI software and software as a service (CISA).

The 2026 data fields include:

Area Data fields in the 2026 minimum elements
About the SBOM SBOM author, author signature, timestamp, data format name and version, generation context, tool and version, SBOM version
About each component Component name, version, producer (formerly “supplier name”), identifiers, license
Integrity Component hash value and hash algorithm
Structure Component dependency relationships

“Generation context” records whether the SBOM was produced before, during or after the build, which affects how complete it is. The guidance also asks SBOM authors to state explicitly when information is unknown rather than leaving gaps ambiguous (CISA 2026 Minimum Elements, PDF).

Formats

CISA’s guidance names the two widely used formats:

  • SPDX (System Package Data Exchange), an ISO standard as ISO/IEC 5962:2021, which also provides the SPDX license identifiers used across the industry.
  • CycloneDX, an OWASP project standardised by Ecma International as ECMA-424.

Most SCA tools can produce both. What matters more is that SBOMs are generated automatically in the build, versioned with each release, signed, and stored where the security team can query them.

Build integrity: SLSA levels

SLSA (Supply-chain Levels for Software Artifacts) is an industry specification maintained under the OpenSSF. Version 1.2 contains a Build track and a Source track (SLSA v1.2). The Build track levels are:

Build level Requirement Main protection
L0 None None (no SLSA)
L1 Provenance exists showing how the package was built Mistakes; documentation
L2 Signed provenance generated by a hosted build platform Tampering after the build
L3 Hardened build platform Tampering during the build

Source: SLSA Build track basics.

SLSA is explicit about what it does not cover: it does not judge code quality, it does not address producers who intentionally ship malicious software, and an artifact’s SLSA level says nothing about the level of its dependencies. It complements the SSDF rather than replacing it, and the SLSA project describes itself as one way to measure progress toward SSDF practices.

The NIST SSDF in brief

The SSDF groups practices into four families: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). NIST also published SP 800-218A, a community profile that adds practices for generative AI and dual-use foundation models (NIST CSRC). Many enterprises map their secure development policy to these families so that customer questionnaires can be answered consistently.

Signing and provenance with Sigstore

Signing lets a consumer verify that an artifact came from the expected publisher and was not modified. Sigstore, an OpenSSF project, signs release files, container images, binaries and SBOMs using short-lived certificates tied to an identity instead of long-lived private keys (Sigstore overview). Its main components are:

  • Cosign, the client that signs and verifies;
  • Fulcio, a certificate authority that issues a short-lived certificate after checking an OpenID Connect identity token (for example, a CI workflow identity);
  • Rekor, an append-only transparency log that records signing events so they can be audited.

Verification checks the signature, that the certificate’s identity matches the expected signer, and that the entry appears in Rekor. For enterprises, the practical step is to enforce verification at deployment time (for example, in a Kubernetes admission controller), not just to sign.

Judging open source dependencies: OpenSSF Scorecard

Before adopting a dependency, teams can check how it is maintained. OpenSSF Scorecard runs automated checks on a repository and returns a score out of 10 for each check plus a weighted aggregate. The checks cover areas such as code review, branch protection, pinned dependencies, token permissions in workflows, signed releases, fuzzing, static analysis, a security policy and whether the project is maintained (OpenSSF Scorecard). Scorecard is a signal, not a verdict: a low score is a prompt to look closer, and a high score does not prove a package is free of vulnerabilities.

Vulnerability management: CVE, NVD, KEV and VEX

Identifiers and enrichment

A CVE ID is the common identifier for a publicly disclosed vulnerability, assigned by a CVE Numbering Authority. NIST’s National Vulnerability Database (NVD) lists every CVE and has historically “enriched” records with severity scores and affected-product data. In April 2026, NIST announced that it would prioritise enrichment for CVEs in CISA’s KEV catalog, software used by federal agencies and EO 14028 critical software; other CVEs remain listed but are marked lowest priority and are not immediately enriched. NIST also moved its backlog of unenriched CVEs published before 1 March 2026 into a “Not Scheduled” category (NIST, NVD).

The practical consequence: SCA tools that rely only on NVD enrichment may show missing severity or product data for many CVEs. Ask vendors which advisory sources they use (for example, ecosystem advisories, vendor advisories and OSV) and how they handle CVEs without NVD analysis.

Prioritising with KEV and SSVC

CISA’s Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities that have a CVE ID, reliable evidence of exploitation in the wild and a clear remediation action. CISA recommends that every organisation use KEV as an input to prioritisation (CISA KEV).

For federal civilian agencies, Binding Operational Directive 26-04 (10 June 2026) carries the KEV criteria forward from BOD 22-01 and sets remediation timelines based on four factors: whether the vulnerability is in KEV, whether the asset is publicly exposed, whether exploitation is automatable and whether the technical impact is total or partial (CISA BOD 26-04). The resulting timelines are:

BOD 26-04 outcome Meaning
3 days and forensic triage Remediate within 3 days and check whether the asset was compromised
3 days Remediate within 3 days
14 days Remediate within 14 days
60 days Remediate within 60 days
Fix on system upgrade Remediate at the next scheduled major upgrade or rebuild

Source: CERT/CC SSVC, CISA BOD 26-04 response model.

Private companies are not bound by the directive, but its decision model is a reasonable template for internal service-level targets.

VEX: “affected” is not the same as “present”

An SBOM can show a vulnerable library that is never actually used. A Vulnerability Exploitability eXchange (VEX) statement lets a supplier say whether a product is affected. CISA’s minimum requirements define four statuses: not affected, affected, fixed and under investigation. A “not affected” statement should give a justification, such as the component or vulnerable code not being present or not being in the execution path (CISA, Minimum Requirements for VEX). Supporting VEX on both the producing and consuming side cuts down on false-positive tickets.

AI coding assistants: new supply chain risks

AI coding assistants change the supply chain in three ways.

Package hallucination (“slopsquatting”)

A code-generating model may suggest installing a package that does not exist. If an attacker registers that name in a public registry, a developer who runs the suggested install command pulls in the attacker’s code. In a study presented at USENIX Security 2025, researchers generated 576,000 code samples in Python and JavaScript with 16 models; 19.7% of the 2.23 million packages recommended were hallucinated, including 205,474 unique non-existent names. Average rates were at least 5.2% for the commercial models tested and 21.7% for the open source models (Spracklen et al., USENIX Security 2025). These figures describe the models and prompts in that study, not every assistant in use today.

OWASP’s 2025 Top 10 for LLM Applications describes the same attack under LLM09:2025 Misinformation, with the scenario of attackers publishing malicious packages under commonly hallucinated names (OWASP LLM09:2025).

Insecure suggestions

Generated code can repeat insecure patterns from training data. An earlier academic study prompted GitHub Copilot with 89 scenarios based on high-risk CWE weaknesses and found approximately 40% of the 1,689 resulting programs to be vulnerable (Pearce et al., “Asleep at the Keyboard?”). Tools and models have changed since then, but the lesson holds: AI-generated code needs the same review, testing and static analysis as human-written code.

Secrets and data exposure

Prompts and context windows can contain credentials, internal code and customer data. OWASP lists LLM02:2025 Sensitive Information Disclosure and LLM03:2025 Supply Chain (compromised models, datasets and adapters) among the top risks (OWASP Top 10 for LLM Applications 2025).

Controls that help

  • Route package installs through an internal registry proxy with an allow-list or quarantine period for new packages, so a hallucinated name cannot be fetched directly from the public registry.
  • Require lockfiles with hashes and fail builds when a new dependency appears without review.
  • Run secret scanning on commits and on AI tool configuration files.
  • Keep SAST and SCA in pull requests regardless of whether code was AI-assisted.
  • Set an enterprise policy for which assistants and models are approved, what data they may see and how prompts are logged.

Hardening the CI/CD pipeline

The build system is a high-value target because it holds signing credentials and can publish releases. Common hardening steps, many of which map to SSDF “Protect the Software” tasks and to Scorecard checks, include:

  • Least-privilege tokens: set CI workflow tokens to read-only by default and grant write access per job.
  • Pin third-party actions and images to a commit SHA or digest rather than a mutable tag.
  • Short-lived credentials: use OIDC federation from CI to cloud providers instead of stored long-lived keys.
  • Branch protection and code review on the default branch and on workflow files.
  • Isolated, ephemeral build runners so one job cannot influence another, a core SLSA Build L3 expectation.
  • Generate provenance and SBOMs in the build, sign them, and verify signatures before deployment.
  • Log and alert on changes to pipeline definitions, secrets and release permissions.

Evaluation checklist for SCA and SBOM tooling

The criteria below are vendor-neutral. Score each candidate against your own environment and ask for documentation or a proof of concept for every claim. This site does not rank tools.

Criterion What to check
Ecosystem coverage Languages, package managers, container images and operating system packages you actually use
SBOM output SPDX and CycloneDX versions supported; whether the 2026 CISA minimum elements are populated; signing support
SBOM ingestion Can it import supplier SBOMs and VEX documents and match them to your inventory?
Advisory sources Which databases beyond NVD are used; how CVEs without NVD enrichment are scored
Prioritisation KEV flagging, exploit-prediction or SSVC-style inputs, reachability analysis and how each is explained
Malicious package detection Detection of typosquatting, newly published or hallucinated package names before install
Policy and gating Ability to block builds or merges on license, severity, KEV status or unapproved packages
Developer workflow IDE, pull request and CI integrations; quality of fix suggestions; noise and false-positive handling
Provenance and signing Support for Sigstore or other signing; SLSA provenance verification
Data handling Where source code and SBOMs are processed and stored; retention; vendor’s own SOC 2 or ISO/IEC 27001 attestations
Reporting and APIs Export formats, APIs and integration with ticketing and asset inventory
Commercial terms Pricing model (per developer, per project or per scan), contract length and exit terms, documented by the vendor

Key takeaways

  • Federal software supply chain policy shifted in 2025 and 2026: the common attestation form is no longer required government-wide, but SBOMs, SSDF practices and risk-based assurance remain central.
  • CISA’s 2026 Minimum Elements replaced the 2021 NTIA baseline and add fields such as hashes, licenses and generation context.
  • SLSA covers build and source integrity; the SSDF covers the wider development life cycle; Sigstore and Scorecard are practical tools that support both.
  • With NVD enrichment now prioritised, KEV, VEX and multiple advisory sources matter more for triage.
  • AI coding assistants add package hallucination, insecure suggestions and data exposure risks, which registry controls, lockfiles and normal code review can reduce.

Sources