CRA Reporting Went Live on 11 September: 24 Hours to ENISA, 3.08 Billion Rekor Entries, 17% of PyPI Attested, 92% SBOM False Positives

I publish an Apache-2.0 microVM platform, PandaStack, that organisations in Europe download and run; that is the disclosure, and it is why I have spent the last month reading the Cyber Resilience Act as a manufacturer would. Annex III lists "hypervisors and container runtime systems that support virtualised execution" as important products, class II, the tier that normally needs a notified body. Whether that reaches a Firecracker orchestrator given away under an open licence is the kind of question the CRA makes everyone answer. On 11 September its first obligation switched on, and ENISA's reporting portal went live the same day. This is the ledger: what applies now, what applies in December 2027, where the standards and tooling actually stand, with the SBOM and provenance numbers measured rather than asserted, and what a small team should build this quarter.

What switched on at 11 September

The CRA, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Provisions on notifying conformity assessment bodies applied from 11 June 2026, reporting obligations from 11 September 2026, and everything else, Annex I essential requirements, CE marking, conformity assessment, the support period, from 11 December 2027.

The live duty is Article 14. A manufacturer that becomes aware of an actively exploited vulnerability in its product, or a severe incident affecting its security, files an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix being available, or within one month of the 72-hour notification for an incident. The notification goes simultaneously to the CSIRT of the manufacturer's main establishment and to ENISA, through the platform Article 16 told ENISA to build; the Commission's reporting page stresses that manufacturers report once and the coordinator CSIRT forwards to every other member state where the product is sold. ENISA switched the CRA Single Reporting Platform on 11 September; per the launch coverage, each manufacturer registers one primary assigned representative and up to twenty secondary ones, and an API is promised for later.

Date	What applies	Who	Source
10 Dec 2024	Entry into force	Everyone in scope	EC
11 Jun 2026	Provisions on notification of conformity assessment bodies	Member states, notified bodies	EC summary
11 Sep 2026	Art. 14: 24 h early warning, 72 h notification, 14 day or 1 month final report, via ENISA SRP	Manufacturers	EC reporting
31 Oct 2026 (proposed; was 30 Aug)	Horizontal Type A and vulnerability-handling standards due under M/606	CEN, CENELEC, ETSI	cyberresilienceact.eu
11 Dec 2027	Annex I essential requirements incl. SBOM, CE marking, conformity assessment, support period; Art. 24(3) steward reporting	Manufacturers, stewards	EC reporting
Penalties	Up to EUR 15 million or 2.5% of worldwide turnover for Annex I, Art. 13 and 14 breaches; EUR 10 million or 2% for most others; none for stewards	Art. 64	EUR-Lex

Manufacturer or steward: the question open source must answer

The CRA scopes to products made available on the market, so a hobby project on GitHub is out and a paid product is in. Open source lives in the gap, and the regulation invented a role for it. Article 24 says an open-source software steward, a legal person that provides sustained support for an open-source product intended for commercial activity, must "put in place and document in a verifiable manner a cybersecurity policy" covering secure development and vulnerability handling, must cooperate with market surveillance authorities on request, and from December 2027 inherits a version of the reporting duty. No CE mark, no conformity assessment, no fines. The Eclipse Foundation's ORC Working Group whitepaper on stewards walks through the test; the OpenSSF's brief guide for OSS developers is the shortest honest treatment.

The hard part is deciding you are one. Taking money around a project, even support contracts on an open core, pushes you toward manufacturer. For PandaStack my reading is that the code I give away is not placed on the market while a hosted service built on it is a different product. The CRA wants a documented decision, not a vibe.

The ecosystem has not made that decision. The Linux Foundation's 2026 CRA Awareness and Readiness Report, with OpenSSF, Balena, Ericsson and Revanite, found 66 percent of respondents unfamiliar with the regulation, up from 62 percent a year earlier. Among those aware of it, 54 percent were unclear on manufacturer versus steward, 32 percent produce SBOMs for all their products, flat on 2025, 51 percent passively rely on upstream for fixes, and 41 percent of manufacturers expect full compliance on time. OpenSSF's readiness guide landed the week the reporting duty began.

The standards are late, and that is the manufacturers' problem

A manufacturer of an important class I product, which Annex III defines to include browsers, password managers, VPNs, operating systems, SIEMs and routers, may self-assess only against a harmonised standard or a European certification scheme; otherwise a notified body is required. Class II, hypervisors and container runtimes, firewalls, tamper-resistant microcontrollers, always requires a third party, though the Commission's summary notes that a free and open-source product in these classes may self-assess if its technical documentation is public.

The standards are not there. Standardisation request M/606, accepted by CEN, CENELEC and ETSI in April 2025, set 30 August 2026 for the horizontal Type A and vulnerability-handling standards. In July the Commission drafted an amendment pushing those to 31 October 2026 and the product-specific Type C standards to 31 December; as of September it was still unadopted and no CRA harmonised standard has been cited in the Official Journal; prEN 40000-1-3 on vulnerability handling is expected to be the first. Anyone in class I hoping to self-assess has nothing to point at yet, and the notified bodies that opened on 11 June will be the bottleneck.

SBOMs: the format war ended, the quality problem did not

Annex I Part II (1) is the sentence that puts SBOMs into European law: manufacturers shall "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies". Top-level only, machine-readable, format unspecified. Two formats clear it. CycloneDX 1.7 shipped on 21 October 2025 with citations for the provenance of BOM data, patent fields and an expanded cryptography BOM. SPDX remains ISO/IEC 5962, 3.0 is the current major version, a 3.1 release candidate appeared on 26 January 2026, and the Python Software Foundation began shipping SPDX SBOMs with CPython 3.14 in October 2025. Pick either; the converters work.

The US side moved the definition of good enough. CISA's 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026 after a draft that drew more than 90 comments, replaces the 2021 NTIA list and adds four fields: component hash, component licence, SBOM tool name, and SBOM generation context, which records whether the SBOM came from source, build, analysis or deployment. An AI SBOM companion with G7 partners followed on 16 June.

Now the quality problem, which is why "we generate SBOMs" means less than it sounds. A study of 55,444 SBOMs from six tools across 3,287 repositories, submitted January 2026, found package-detection consistency between tools as low as 7.84 to 12.77 percent depending on language, licence accuracy below 20 percent, and poor agreement between a tool and its own earlier versions. A 2,414-repository analysis found downstream scanners produced a 92.0 percent false-positive rate, mostly from flagging vulnerabilities in unreachable code, with function-call analysis pruning 61.9 percent of those alarms. CISA's generation-context field is a direct response: a source-scan SBOM and a build-time SBOM of the same project disagree, and until now nothing told you which you were holding.

Provenance: SLSA 1.2, the registries, and what Rekor holds today

SBOMs say what is in the box; provenance says who built it and from what. SLSA v1.2 is the current approved specification. The Build track keeps three levels, L1 provenance exists, L2 provenance signed by a hosted platform, L3 a platform hardened so the build cannot forge its own provenance, and the Source track is promoted to approved with four levels from version control through immutable history and enforced controls to L4, two-party review on protected branches.

GitHub's artifact attestations give SLSA v1.0 Build L2 out of the box and L3 with a reusable signing workflow, writing public-repository attestations to the Sigstore public good log and private ones to a GitHub-run Sigstore without a log; attest-build-provenance is at v4.2.2. A claim that GitHub now generates L3 attestations automatically for every public workflow run circulated this summer; I could not verify it in GitHub's changelog or docs and have left it out. npm's trusted publishing reached GA on 31 July 2025 and attaches provenance automatically, and after the Shai-Hulud worms npm revoked every classic token in December 2025, covered in the npm worms post. PyPI's 2025 review reports more than 50,000 projects on trusted publishing, 20 percent of all file uploads through it, and 17 percent of uploads carrying attestations. Homebrew added bottle attestation verification in 4.3.0 in May 2024; Maven Central added Sigstore verification in January 2025 per the cosign v3 announcement, opt-in beside the PGP signatures it still requires. The long tail is thin: one March 2026 survey found 76 of 1,059 npm packages in a single dependency tree carried provenance, 7.2 percent, and Maven Central under 1 percent; one person's measurements, not registry statistics.

Sigstore turned a corner in October 2025. Cosign v3 on 8 October made the bundle format, trusted root and signing config the defaults. Rekor v2 reached GA on 10 October: a tile-backed log on Tessera, two entry types instead of eleven, shards named by year, URLs distributed through TUF so clients stop hardcoding them. But a June 2026 post on the Sigstore blog says the public good instance will keep Rekor v1 as the default "for the foreseeable future", because v2 breaks older verifiers. I checked both this morning from the scratchpad: curl https://rekor.sigstore.dev/api/v1/log returned an active tree of 2,960,881,224 entries plus inactive shards of 117,740,831 and 4,163,431, so 3,082,785,486 entries in Rekor v1 at 05:33 UTC on 5 October 2026, and the v2 shard at log2025-1.rekor.sigstore.dev/api/v2/checkpoint reported 138,593,791. Three billion signatures in an auditable log is the quiet success of this field; the 7.2 percent is the reminder that signing and verifying are different acts.

The pipeline I would actually run

The minimum I would put in front of a December 2027 deadline: build, attest the artifact, generate and attest a build-time SBOM, then verify downstream with tooling that does not trust the registry. Versions pinned to today's.

# .github/workflows/release.yml
# Build L2 provenance plus an attested, build-context SBOM. L3 needs the
# attest step moved into a reusable workflow (see GitHub's SLSA L3 post).
name: release
on:
  push:
    tags: ["v*"]
permissions:
  contents: read
  id-token: write        # OIDC token for Sigstore keyless signing
  attestations: write    # store attestations with GitHub
jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v5
      - name: Build
        run: make dist && sha256sum dist/* > dist/SHA256SUMS
      - name: Install syft 1.54.0 (1 Oct 2026)
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh \
            | sh -s -- -b /usr/local/bin v1.54.0
      - name: SBOM from the built artifact, not the source tree
        run: syft dist/pandastack-linux-amd64 -o cyclonedx-json@1.7 > dist/sbom.cdx.json
      - name: Attest build provenance (SLSA v1 predicate)
        uses: actions/attest-build-provenance@v4.2.2
        with:
          subject-path: dist/pandastack-linux-amd64
      - name: Attest the SBOM to the same subject
        uses: actions/attest-sbom@v3
        with:
          subject-path: dist/pandastack-linux-amd64
          sbom-path: dist/sbom.cdx.json

# Consumer side. gh checks the GitHub-issued attestation and the Sigstore log;
# cosign (v3.1.3) does the same from a downloaded bundle, no GitHub login needed.
gh attestation verify ./pandastack-linux-amd64 --owner pandastack \
  --signer-workflow pandastack/pandastack/.github/workflows/release.yml

gh attestation download ./pandastack-linux-amd64 --owner pandastack   # writes sha256:<digest>.jsonl
cosign verify-blob-attestation ./pandastack-linux-amd64 \
  --bundle sha256:*.jsonl --new-bundle-format \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/pandastack/pandastack/.github/workflows/release.yml@refs/tags/v'

# Verify an npm package's provenance the same way (per the Sigstore blog)
curl -s https://registry.npmjs.org/-/npm/v1/attestations/semver@7.6.3 \
  | jq '.attestations[] | select(.predicateType=="https://slsa.dev/provenance/v1").bundle' > npm.sigstore.json
cosign verify-blob-attestation --bundle npm.sigstore.json --new-bundle-format \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/npm/node-semver/.github/workflows/release-integration.yml' \
  semver-7.6.3.tgz

# How big is the log you just trusted? (run 5 Oct 2026: 2,960,881,224 active entries)
curl -s https://rekor.sigstore.dev/api/v1/log | jq '.treeSize, [.inactiveShards[].treeSize]'

The verification commands follow Sigstore's bundle verification guide; the identity regex is the whole point, since a valid signature from the wrong workflow is exactly what a compromised CI job produces. The CRA requires none of this, only a documented vulnerability-handling process and an SBOM; the cheapest way I know to have a true SBOM and a defensible process is to make the build emit both and sign them.

Scorecard, Baseline, and the US going the other way

Two OpenSSF projects are becoming the de facto answer to "show me your cybersecurity policy". The OSPS Baseline, first released 25 February 2025, is a tiered control set for open-source projects; the 2026-02-19 version has 59 controls across three levels with crosswalks to NIST 800-161 and PCI DSS among others, and the 2026-08-28 release moved it onto the Gemara v1 schema and added a Scorecard mapping. Scorecard v5.5.0 shipped 23 April 2026; the v6 proposal merged in March reframes it from a 0 to 10 score into an "evidence engine" emitting pass, fail or unknown per Baseline control, and is candid that of those 59 controls only 8 are fully observable from a repository today, 17 partially, 31 not at all and 3 never will be. The honest number is 8 of 59, before anyone maps Baseline to Annex I.

Meanwhile the United States has stepped back from mandates. EO 14306 of 6 June 2025 amended EO 14144 to remove the requirement that federal software vendors submit validated attestations and artifacts to CISA's repository and replaced a mandated SSDF update with a "preliminary" one. OMB's M-26-05 of 23 January 2026 then rescinded M-22-18 and M-23-16, the memos that made self-attestation compulsory, in favour of agency-by-agency risk decisions. NIST's SSDF 1.2, SP 800-218 Rev. 1, appeared as an initial public draft on 17 December 2025 and remains a draft. So in 2026 the SBOM requirement in US federal procurement is a maybe, decided per agency, while in the EU it is a regulation with a fine attached. If you sell to both, build to the EU bar.

Why the worms are the reason this is worth doing

I would not write about compliance if the threat were hypothetical. In September 2025 Shai-Hulud used stolen npm tokens to republish itself across more than 500 packages, CISA issued an alert, and the November sequel exfiltrated secrets from tens of thousands of repositories. Sonatype's 2026 report counts more than 454,600 new malicious packages in 2025, up 75 percent. The full year is in the npm worms post.

Read those incidents against the CRA and two things stand out. First, an SBOM would not have caught any of them: a worm that replaces a version at the registry leaves the version string in your SBOM exactly where it was, which is why provenance, a cooldown on new versions and scripts off by default do the work SBOMs get credited with. Second, every victim who shipped a compromised build to customers was, from 11 September, holding an actively exploited vulnerability with a 24-hour clock on it. The regulation does not care whether you have an AI pair programmer or a platform team; it asks whether you knew what you shipped and could say so to a CSIRT within a day. That is a build-pipeline property, which is why the unglamorous disciplines, reproducible builds, signed provenance, a release a human approves with a hardware key, matter more now that agents, the non-human identities holding your tokens, open the pull requests and run the installs, not less.

What I take from the month. The live obligation is small and concrete: know when you are being exploited and tell ENISA within 24 hours, through a portal that exists. The December 2027 obligation is large and still fuzzy, because the standards that define conforming are two months late and counting. The tooling in between is good enough and mostly free: SLSA 1.2 names the levels, the registries issue provenance for the price of an OIDC token, and Rekor's three billion entries prove the model scales. The gap is adoption, 17 percent of PyPI uploads and a long npm tail, and quality, where 92 percent false positives means an SBOM nobody reads. This quarter I am writing the manufacturer-or-steward memo for PandaStack and filing it where an authority could ask for it, moving the release workflow to attested builds with a build-time SBOM, registering a representative on the SRP so the 24-hour clock does not start with account creation, and running Scorecard against Baseline. None of that is a product feature. All of it is what shipping software into Europe now means.

---

Related: The Worms Learned to Use Your AI Agent, MCP Security in 2026 and CI/CD When Agents Open the Pull Requests.