Shift-left should not mean shift-only. Diagram of three stages of the software supply chain: 01 Intended (source code, dependencies and manifest, what developers declared), 02 Built (jar, whl, tar and image artifacts with hashes, what the artifact contains) and 03 Running (containers on a Kubernetes cluster with alerts, what production executes).

Research brief · Software supply chain Compiled 26 Sep 2026

Research report · Shift-left and production reality

Shift-left should not mean shift-only.

This report checks one argument against published evidence: source and dependency scanning show the risk before the build, and what gets built and run can be different. The sources are CISA guidance, peer-reviewed and preprint studies, incident analyses, and vendor telemetry reports.

01 · INTENDED

What developers declared

Manifests, lockfiles, source

02 · BUILT

What the artifact contains

Images, binaries, packages

03 · RUNNING

What production executes

Loaded, reachable, exposed

2026 update · Latest published data

The 2026 data shows more components, more attacks and new reporting deadlines

These reports were published between January and September 2026. They strengthen the case for inventories that follow the artifact into production. Most of the figures are vendor telemetry or audit samples, and the source line under each one says which.

48%

of breaches involved a third party, up 60% year over year. Exploited vulnerabilities (31%) overtook stolen credentials as the top way in, for the first time.

Verizon DBIR 2026 · May 2026 · 2025 incident data

26%

of known exploited vulnerabilities were remediated in 2025, down from 38% the year before.

Verizon DBIR 2026, via Abnormal AI · secondary

+107%

rise in mean open source vulnerabilities per codebase, with 30% more components and 74% more files. Of the codebases audited, 87% had at least one vulnerability.

Black Duck OSSRA 2026 · 947 codebases, Nov 2024–Oct 2025

454,648

new malicious open source packages found in 2025, bringing the total to 1.233 million (+75%). Downloads across the four largest registries reached 9.8 trillion.

Sonatype SSSC 2026 · Jan 2026

65%

of organisations reported a software supply chain attack in the past year. Two-thirds of the attacks used purpose-built malicious packages, and a third used hijacked legitimate ones.

Black Duck OSSRA 2026 · survey data

~5.5%

of running workloads still use vulnerable images with critical or high vulnerabilities in use. Sysdig says this figure has plateaued, while some vulnerabilities are now exploited within hours of publication.

Sysdig 2026 · Apr 2026

28.6M

new secrets exposed in public GitHub commits in 2025, up 34% year over year and the largest single-year jump on record. Leaked AI-service credentials rose 81%.

GitGuardian 2026 · Mar 2026 · public GitHub commits, 2025

of organisations pin every marketplace GitHub Action they use to a commit hash. 71% never pin any, so a compromised Action reaches their pipelines on the next automatic update.

Datadog 2026 · Feb 2026 · GitHub Actions usage to Jan 2026

REGULATION · IN FORCE 11 SEP 2026

EU CRA reporting obligations now apply

Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform. An early warning is due within 24 hours and a full notification within 72. Goodwin notes that the duty also covers vulnerabilities in third-party components integrated into a product. Machine-readable SBOMs become mandatory from 11 December 2027.

European Commission · accessed Sep 2026

GUIDANCE · 29 JUL 2026

CISA 2026 SBOM minimum elements replace NTIA 2021

CISA, the NSA, the FBI and international partners jointly issued the 2026 Minimum Elements after a 2025 public comment period. According to Sbomify, the 2025 draft added fields for component hash, licence and generation context. The final text was not reviewed here, so check which fields survived.

CISA · final published Jul 2026

INDIA · CERT-IN, SEBI, RBI

CERT-In v2.0Sets the BOM standard

SEBI CSCRFMakes SBOM binding for regulated entities

RBIExpects entities to follow CERT-In through its IT governance and vendor-risk rules

CERT-In

Advisory

CERT-In's Technical Guidelines v2.0 (MeitY, 9 July 2025) apply to government, public sector organisations, essential services and software exporters. They encourage organisations to adopt SBOM, QBOM, CBOM, AIBOM and HBOM as "a mandatory standard practice" in procurement and software development. Section 2.2 uses banks and fintechs as its worked example, because they run a mix of COTS, open-source and custom-built software.

§7.1.2: software supplied to government, public sector and essential services must come with a complete SBOM, in SPDX or CycloneDX (§7.1.5), using the 21 data fields in §4.2. The fields include hashes, EOL date and a unique identifier.
§3.2: recognises six lifecycle SBOM classes, including Analyzed (inspecting final artifacts after the build) and Runtime (monitoring dynamically loaded components).
§7.1.10: consumers map the supplier's SBOM into an internal SBOM. §7.2.12 asks them to obtain supplier assurances on its accuracy and completeness.
§7.1.6: suppliers issue a VEX (not affected, affected, fixed or under investigation), followed by a CSAF advisory.
§8.4.1.1: government, public sector and essential services "shall require" a CBOM and QBOM. §8.4.2.8 sets reviews at least quarterly, and §8.5.4 asks for quarterly vendor post-quantum migration reports with C-level attestation.

Primary source · CERT-In v2.0, sections as cited

SEBI

Binding

SEBI's CSCRF (circular of 20 August 2024) requires regulated entities to obtain and maintain SBOMs for critical systems. The requirement covers in-house, COTS and SaaS software. Legacy systems without an SBOM need a board-level risk justification.

SEBI's circular of 30 June 2025 extended the deadline for most entities to 31 August 2025. Market infrastructure institutions, KYC registration agencies and qualified RTAs were excluded from that date.

SEBI's 5 May 2026 advisory on AI vulnerability-detection tools tells all regulated entities to patch promptly, run continuous vulnerability assessments, strengthen API security and onboard to Market-SOC.

Primary source · SEBI circulars

Why it matters . A 24-hour reporting window for an exploited component depends on knowing that the component is inside a shipped product. A manifest-only inventory is weak evidence for that. Neither the CRA nor CISA specifies which SBOM type to use.

Relevance. SEBI's requirement covers COTS and SaaS, where regulated entities usually have no source code. For those systems the SBOM has to come from analysing the artifact or from the vendor, so the declared-versus-shipped gaps in Findings 01–03 apply directly.

RBI

Via CERT-In

RBI has no standalone SBOM or CBOM circular. Its expectation reaches banks in two ways:

the Master Direction on IT Governance, Risk, Controls and Assurance Practices (in force since April 2024), which sets vendor and third-party risk rules
supervisory expectations that entities follow CERT-In's technical guidelines

RBI Master Direction · practitioner summaries

Global regulatory map · verified Sep 2026

SBOM requirements differ by country and sector

Every row was checked against the regulator's own page or a legal or practitioner summary. Where a commonly repeated claim did not hold up, the row says so under "Verified".

The strongest 2026 signal for this report's argument comes from US policy.

OMB memo M-26-05 (23 January 2026) made federal SBOM requests optional for each agency. Where an agency does ask a cloud provider for an SBOM, it should require an SBOM of the runtime production environment, on request (Mayer Brown, Wiley). That is policy language asking for a picture of what is actually running, not only what was declared.

JurisdictionInstruments · scopeStatusKey dates · formatVerified

USAUnited States

EO 14028 · FDA §524B (medical "cyber devices") · Army SBOM memo (defense contracts) · OMB M-26-05 (federal civilian) Sector-mandatory EO May 2021 · FDA refuse-to-accept since 1 Oct 2023 · Army memo 16 Aug 2024 · M-26-05 23 Jan 2026 · SPDX · CycloneDX Correction: the timeline runs into 2026, not 2025. M-26-05 rescinded M-22-18 and M-23-16, so federal civilian SBOMs are now at each agency's discretion. FDA is still statutory. The Army memo is from a secondary source.

EUEuropean Union

CRA (2024/2847) · BSI TR-03183-2 (German technical baseline) · NIS2 · DORA — products with digital elements on the EU market Mandatory 2027 In force 10 Dec 2024 · reporting from 11 Sep 2026 · SBOM from 11 Dec 2027 · fines up to €15M or 2.5% of turnover · CycloneDX ≥1.6 · SPDX ≥3.0.1 (BSI) CRA dates and fines confirmed. Qualify: BSI TR-03183-2 v2.1.0 (Aug 2025) raised the minimum format versions. DORA does not explicitly require an SBOM, and NIS2 is also related rather than an SBOM rule. Medical devices are outside the CRA.

INDIndia

CERT-In BOM guidelines v2.0 (SBOM, AIBOM, CBOM, QBOM, HBOM) · SEBI CSCRF · RBI — government, public sector, essential services, securities market Mixed CERT-In v1 3 Oct 2024, v2.0 9 Jul 2025 · SEBI deadline 31 Aug 2025 · CycloneDX · SPDX Qualify "mandatory (govt)": AZB describes CERT-In's guidelines as not mandatory, although the procurement clauses say "must". SEBI is binding. RBI applies CERT-In's guidelines through its supervisory expectations and has no standalone circular.

JPNJapan

METI Guide on Introduction of SBOM for Software Management — software vendors, industrial sectors Guidance v1.0 Jul 2023 · v2.0 Aug 2024 · co-signed CISA Shared Vision Sep 2025 and 2026 Minimum Elements 30 Jul 2026 · SPDX / SPDX Lite discussed Correction: v2.0 was finalised in August 2024, not a 2024 draft with a 2025 pilot. METI ran proofs of concept earlier. It co-signed the 2026 Minimum Elements.

KORSouth Korea

Comprehensive Plan for Information Security Across Ministries (MSIT and partners) — public sector IT systems and products Roadmap · 2027 Announced 22 Oct 2025 · SBOM submission from 2027 · format not yet specified The 2027 date is confirmed by the government. Unverified: the "2025 pilot". One vendor reports that financial, telecom and platform sectors will also be covered.

GBRUnited Kingdom

Software Security Code of Practice (DSIT and NCSC, co-sealed by Canada's CCCS) — anyone who develops or sells software to businesses Voluntary Launched 7 May 2025 · 14 principles in 4 themes · no mandated format Voluntary status confirmed by the NCSC. Qualify: the PSTI Act covers consumer connected-product security and does not require an SBOM.

AUSAustralia

ASD Information Security Manual (software development controls) · co-signed 2026 Minimum Elements Guidance ISM control: SBOM produced and made available to consumers · 2026 Minimum Elements published 30 Jul 2026 Qualify: the requirement comes from the ISM, which applies across sectors, rather than guidance written for critical infrastructure. ISM wording is quoted via Sonar.

TWNTaiwan

Cyber Security Management Act amendment (MODA / ACS) — government agencies and specific non-government agencies, including critical infrastructure No explicit SBOM Passed 29 Aug 2025 · promulgated 24 Sep 2025 · effective date set by the Executive Yuan Qualify: the amendment adds CISO appointments, outsourcing controls and investigative powers. No SBOM clause was found, so an SBOM is at most implied.

"Sector-mandatory" means binding only for the named sectors or procurement channels. Where a legal summary and a vendor blog disagreed, this report follows the legal summary. Treat this map as research, not legal advice.

Framework · CISA SBOM types (Apr 2023)

Six inventories, six points in the lifecycle

CISA's community working group published this taxonomy on 21 April 2023. Each type describes the software at a different stage. Shift-left tooling mostly produces the first two.

SOURCE

Design

Intended components, some not yet built.

Shift-left

SOURCE

Source

Built from the dev environment and declared dependencies. This is the typical SCA output.

Shift-left

BUILD

Build

Generated in CI. Covers more than the source. May carry the wrong versions of dynamically linked dependencies.

Build-time

ARTIFACT

Analyzed

Produced by analysing executables, packages, containers or VM images after the build. No build access needed.

Binary / BCA

DEPLOYMENT

Deployed

Software present on a system, including configuration.

Shift-right

RUNTIME

Runtime

Captured by instrumenting the running system, including dynamically loaded components.

Shift-right

CISA notes a limitation of Source SBOMs, as summarised by FOSSID: they can flag components "that never run or are compiled out in deployed code," and they can miss runtime, plugin or dynamic components.

Finding 01 · Intended ≠ built

Manifests don't list everything that ships

Endor Labs' 2024 Dependency Management Report found that for some Python customers, undeclared dependencies were 0–60% of all dependencies, and those dependencies held up to 85% of the vulnerabilities. The report also says thousands of Python and Java components "rebundle binary code from other open source projects."

Log4Shell showed the same problem in Java. JFrog found around 400 Maven Central packages that contained Log4j code without declaring it as a dependency. The cause was fat JARs, shading, or code copied in directly. In ~30% of the class-level cases, Log4j did not appear in the transitive dependency list at all. Snyk said at the time that its CLI might not find Log4j that was "not disclosed in the manifest file, forked, or repackaged," and shipped a JAR-inspecting command in response.

Declared dependencies are also not always resolved the same way twice. A 2025 empirical study notes that most earlier SBOM-tool evaluations used manifest files, "which do not deterministically encode transitive dependencies." The authors used lockfiles instead and got much better reproducibility.

85%

Highest share of vulnerabilities found in undeclared Python dependencies, across the Endor Labs customers sampled.

Endor Labs, Sep 2024 · vendor telemetry, select customers

~400

Maven Central packages that contained Log4j code without declaring it as an external package.

JFrog via SC Media, 2022 · compare with ~17,000 packages that declared Log4j (Google)

Sources disagree. A secondary write-up of the same Endor report says "56% of library vulnerabilities" occur in phantom dependencies. That figure does not appear in Endor's own summary, which gives the 0–60% and up-to-85% ranges. Cite the primary figures.

Finding 02 · The build can inject

The XZ Utils backdoor was in the tarball, not the repository

CVE-2024-3094 affected xz versions 5.6.0 and 5.6.1 and was disclosed on 29 March 2024. As Sam James summarised it, "the release tarballs upstream publishes don't have the same code that GitHub has." A modified build-to-host.m4 ran during the build and pulled the payload out of binary test files in the repository.

According to a 2024 analysis, the macro was added to .gitignore so it never reached the repository. The injection also ran only on x86-64 Linux builds using glibc and GCC through dpkg or rpm, according to Wikipedia's summary of the analyses. It was designed to trigger in distribution builds and not on developer machines.

Xygeni reports that in August 2025, Binarly found the backdoor still present in about a dozen Debian images on Docker Hub. That report is secondary; Binarly's own publication was not reviewed here.

WHERE EACH CONTROL LOOKS

SAST / code review on git macro not present

SCA on manifest xz 5.6.x listed, no CVE yet

Tarball vs git diff would diverge

Built liblzma binary payload present

Analyst's summary, based on the sources cited. Andres Freund found the backdoor through an SSH latency anomaly, not through a scanner.

Finding 03 · Artifact inventory is not solved

Scanning the artifact is necessary. It is not automatically accurate.

SBOMproof (Bufalino et al., Cnam, Aalto and Thales; arXiv, Oct 2025) tested eight container SBOM and scanning tools on Debian and Alpine OS packages. It reports that "no tool fully respects the pURL format." The tools were "largely incompatible," which led to "a large amount of undetected vulnerabilities." When one tool's SBOM was scanned by another tool, the scan often found no vulnerabilities at all. The authors call this SBOM confusion.

CVE detection recall, Debian bookworm (all packages)

Recall = share of ground-truth CVEs detected · SBOMproof Table 6

Trivy

0.97

Google Artifact Analysis

0.97

Anchore (Syft/Grype)

0.89

Docker Scout

0.49

Amazon Inspector

0.07

Microsoft sbom-tool / Defender

0.00

Read with care. The authors say the Debian-all dataset has few vulnerable packages because CVEs from 2025 were excluded, so precision and recall "may not be entirely representative." On Alpine the results are much closer together, with recall of 0.77–0.81. The paper is a preprint, and the tool versions tested date from 2024–25. The table shows how much results vary between tools. It is not a vendor ranking.

Package-manager metadata has a blind spot too. Kawaguchi et al. (2024) found that scanners missed up to 70% of packages installed into container images without a package manager, as cited in SBOMproof. This is the category where binary composition analysis should add the most, since there is no metadata to read.

18%

The share of critical-CVSS dependency vulnerabilities still rated critical once runtime context was added: whether the service is in production, whether it is under attack, and whether an exploit exists.Datadog, State of DevSecOps 2026 · unchanged from 2025

Finding 04 · Built ≠ running

Production is where exposure is set, and it is where most exposure sits

Telemetry vendors keep reporting the same pattern. Known-vulnerable components reach production and stay there. Whether a vulnerability matters depends on facts that are only visible at deployment and runtime.

87%

of organisations have at least one exploitable vulnerability in deployed services. The vulnerable services are 40% of all services.

Datadog 2026 · Jan 2026 data

32%

of organisations started using a public Docker image within a day of its release. The share for libraries is 50%.

Datadog 2026

4.4 → ~80

Average high or critical vulnerabilities per image: 4.4 for images under 100 MB, 42.2 for 250–500 MB, and almost 80 for larger images. Much of that is base-image content.

Datadog 2024 via DevOps.com

85%

of images running in production had at least one patchable vulnerability. Only 48% of images were scanned before runtime.

Sysdig 2022 ·

Sysdig's 2024 report says prioritising by what is in use at runtime cut critical and high vulnerabilities in use by nearly 50% over one year. It also recommends drift control: automatically shutting down workloads that are modified while running. That recommendation assumes a running workload can differ from its image.

Claim check

How well the evidence supports each claim in the post

Statuses show what this review found. "Not sourced" means no independent evidence was found here. It does not mean the claim is false.

ClaimStatusBasis

Version ranges can resolve differently at build time Partial Manifests don't pin transitive dependencies deterministically, and lockfiles improve reproducibility (arXiv 2511.20313). No study here measured drift from resolution directly.

Dev-only dependencies may never ship Supported CISA: Source SBOMs can flag components that are compiled out or never run.

Tree-shaking can remove components Not sourced Follows from how bundlers work, but no source measuring it was found in this review.

Builds can introduce or inject components Supported XZ Utils (CVE-2024-3094). CISA: Build SBOMs cover "more components than just source code."

Base-image OS packages go unseen by source SCA Supported Container images include OS libraries and binaries (SBOMproof §2.2). Vulnerability counts rise with image size (Datadog).

Vendored, copied-in or rebundled code Supported Log4j found in shaded and fat JARs (JFrog). Rebundling across ecosystems and phantom dependencies (Endor Labs).

Statically linked libraries and generated binaries Partial CISA: Analyzed SBOMs may find hidden dependencies, and packages installed outside a package manager are missed up to 70% of the time. No source here isolated static linking.

Runtime modifications and drift Partial CISA's Runtime SBOM covers dynamically loaded components, and Sysdig recommends drift control. No source here measured how often drift happens.

"SBOM tells you what you shipped" Qualify SBOMproof shows SBOMs of the same image differ from tool to tool. A more defensible wording: an artifact SBOM records what the tool found in what you shipped.

What the sources establish

Declared dependencies and delivered artifacts differ in measurable, repeated ways.
At least one high-impact attack (XZ) put its payload only in build inputs that source review could not see.
Artifact-level SBOMs vary widely by tool, and moving SBOMs between tools can lose findings without any warning.
Runtime and exposure context cuts the "critical" queue by more than 80% in one large telemetry set.

What this report infers

Reconciling Source, Build, Analyzed and Runtime inventories is the practical way to find gaps between intended, built and running software. No source here evaluates reconciliation as a practice.
Binary composition analysis matters most for undeclared, rebundled and manually installed components, and for third-party software with no source available.
BOM quality controls (pURL conformance, cross-tool validation) belong in the same programme. Otherwise the new inventory repeats the same problems.

Frequently asked questions

What is the shift-left gap?

It is the difference between what developers declared (manifests, lockfiles and source), what the build actually produced (images, binaries and packages) and what production runs. Source and dependency scanning only see the first of these, so risks introduced during the build or at runtime can go unseen.

Why does source-level SCA miss components?

Manifests do not list everything that ships. Endor Labs found undeclared dependencies were 0–60% of all dependencies for some Python customers and held up to 85% of vulnerabilities. During Log4Shell, JFrog found around 400 Maven Central packages containing Log4j code without declaring it, because of fat JARs, shading or copied-in code.

How did the XZ Utils backdoor avoid source review?

The malicious build-to-host.m4 macro was only in the upstream release tarballs, not in the git repository, and it ran during distribution builds to extract a payload hidden in binary test files. Code review and SAST on git could not see it; inspecting the tarball or the built liblzma binary would have.

Are container SBOM tools accurate?

Not consistently. The SBOMproof preprint (October 2025) tested eight tools and reported that no tool fully respected the pURL format and that tools were largely incompatible, so scanning one tool's SBOM with another often found no vulnerabilities. On its Debian dataset, CVE recall ranged from 0.97 to 0.00, although the authors caution the dataset is small.

What are the six CISA SBOM types?

Design, Source, Build, Analyzed, Deployed and Runtime, published by CISA's community working group in April 2023. Shift-left tooling mostly produces Design and Source SBOMs; Analyzed, Deployed and Runtime SBOMs describe what was actually shipped and run.

Do Indian regulators require SBOMs?

SEBI's CSCRF makes SBOMs binding for critical systems of regulated entities, including COTS and SaaS. CERT-In's Technical Guidelines v2.0 (July 2025) set the SBOM, QBOM, CBOM, AIBOM and HBOM standard for government, public sector, essential services and software exporters, though legal commentary describes them as guidance. RBI has no standalone SBOM circular; its 31 July 2026 cybersecurity directions instead require vendors to certify software is free of known vulnerabilities and malware.