Decision RecordActivePublished without chair review
CRT-2026-040519 Oct 2026MORNING EDITIONDaily Roundtable
Response to verified compromised npm build exposure
When a build is independently verified to intersect an affected package name, exact version, and integrity hash, stop the release, quarantine runners, caches, and artifacts, preserve build evidence, rotate credentials and signing assets reachable by affected build identities, and rebuild on clean infrastructure.
Current public guidance · the full record
What to do now
At a glanceThe edition's authoritative action board carries no action for this record's subjects — no What to do now guidance.
Why now
Partially supportedThe 19 October 2026 analysis described the affected-version lists for Chalk, Debug, and Shai-Hulud as evolving and warned that package-name-only inventories are inadequate.
It cited [email protected] and [email protected] as examples of why exact version matching matters, while the audit found that the complete authoritative mapping was missing.
The response is therefore event-driven: act immediately when an exact package-name, version, and integrity-hash intersection is independently verified, rather than waiting for a package-name-only assessment or treating the examples as exhaustive.
Who is affected
WeakNpm release teams are affected when a build is independently verified to contain an affected Chalk, Debug, or Shai-Hulud package name, exact version, and integrity hash; they must stop the intersecting release and rebuild it.
CI/CD operators responsible for runners, package caches, container layers, and build artifacts touched by that build must isolate relevant infrastructure and preserve evidence. Owners of credentials and signing assets reachable by the affected build identities must rotate or replace those assets.
Downstream release and provenance teams must reassess artifacts produced in the affected environment because a prior valid signature alone does not establish cleanliness.
Teams that know only that they use npm, or that see [email protected] or [email protected] without a verified integrity-hash match, cannot determine exposure from this packet alone.
What supports this
Partially supportedDirect support — The 19 October 2026 supply-chain analyst excerpt says to inventory package name, exact version, and integrity hash; inspect lockfiles, SBOMs, workspaces, package caches, container layers, build artifacts, and transitive dependencies; and immediately stop intersecting releases.
It names [email protected] and [email protected] as examples showing why exact matching matters.
Direct support — The evidence auditor confirmed that the cited analysis explicitly supports quarantining runners, caches, and artifacts; preserving forensic material; rotating credentials and signing assets reachable by affected runners; and rebuilding from known-good inputs on clean infrastructure.
Scope support — The decision scout limited the procedure to exact dependency tuples and assets reachable from affected execution identities. Evidence gap — A second audit finding says the incident-specific advisories and primary sources were not included.
Evidence gap — A third audit finding says two examples and evolving lists are insufficient to determine exposure without a complete package-version-hash map.
How the Roundtable reached this
Partially supportedThe supply-chain analyst’s 19 October 2026 analysis called for matching npm exposure by package name, exact version, and integrity hash, then stopping intersecting releases and containing the build environment.
The decision scout framed that guidance as an operational response for Chalk, Debug, and Shai-Hulud exposure.
The evidence auditor found direct support for the response procedure but identified two gaps: the cited primary advisories were not included, and the packet lacked a complete affected package-version-hash map.
The boundary reviewer therefore rejected wording that would treat every named release set as independently established by this packet. The arbiter resolved the issue by making independent verification of an exact tuple the trigger for action.
The record-linking role found no prior decision available for comparison, so the selected outcome was a new operational record rather than an update.
Positions are generated by AI specialist personas and chaired by Halil Öztürkci.
Panel composition
- Scout (AI panel role)Scout identified 8 candidate signals.
- Linker (AI panel role)Linker evaluated 8 relation judgments.
- Evidence Auditor (AI panel role)Evidence Auditor recorded 20 evidence signals; 11 gaps.
- Prediction Steward (AI panel role)Prediction Steward accepted 0 predictions and rejected 2 claims.
- Boundary Reviewer (AI panel role)Boundary Reviewer recorded 11 public/private findings.
- Arbiter (AI panel role)Arbiter produced 8 decision envelopes.
Key disagreement
Scout (AI panel role)
Affected-version lists are evolving, and a valid prior signature does not establish that an artifact produced by a compromised build was clean.
Arbiter outcome
Arbiter outcome: new decision record. The response procedure is strongly supported, and incomplete incident mapping can be handled by applying it only after an affected package tuple is independently verified.
Candidates considered
Considered 8 candidates · opened 1 · 7 not opened (7 other)
Considered, not opened
Sign in to preview Considered-Not-Opened entries (moves to Pro at launch).
Sign in to preview practitioner entries.
What is uncertain
ConflictingThis packet cannot determine whether any particular build encountered an affected Chalk, Debug, or Shai-Hulud release because the complete package-version-hash mapping is absent and described as evolving.
It also cannot establish the local reach of an affected build identity into credentials or signing assets. A prior valid signature does not establish that an artifact produced in a compromised build environment was clean.
Because this is a bounded historical replay of the 19 October 2026 source run, it provides no live validation of later changes to affected-release lists or incident findings.
What evidence is missing
ConflictingThe packet does not contain the underlying authoritative advisories, citation URLs, or equivalent primary evidence for the reported malicious-release and credential-access claims.
It also lacks a complete, time-bounded list of affected package names, exact versions, and integrity hashes for Chalk, Debug, and Shai-Hulud. The analyst excerpt names [email protected] and [email protected] as examples but supplies no integrity hashes and does not establish a complete exposure map.
Determining local impact additionally requires each deployment’s lockfiles, SBOMs, provenance, transitive dependency data, runner identities, and evidence showing which credentials or signing assets those identities could reach.
What would change this
WeakAn authoritative, time-bounded package-version-hash list could broaden or narrow which Chalk, Debug, or Shai-Hulud builds trigger this response.
Verified evidence that a build has no matching package name, exact version, and integrity hash would mean this procedure is not triggered for that build.
Evidence that particular credentials or signing assets were unreachable from the affected build identities would narrow the rotation scope, while proof of broader reach would expand it.
Release suspension can end after a clean rebuild from known-good inputs, validation against clean SBOM and provenance data, and replacement of every reachable credential or signing asset.
Primary evidence contradicting the analyst’s incident characterization would require reassessing the incident-specific scope, though not the conditional containment procedure.
What to watch next
WeakWatch authoritative Chalk, Debug, and Shai-Hulud advisories for additions, removals, or corrections to exact package versions and integrity hashes.
Re-run tuple matching whenever those lists change; a new exact match in a lockfile, SBOM, workspace, cache, container layer, build artifact, or transitive dependency triggers release suspension and containment.
For each downstream release, watch for clean SBOM and provenance results, malicious lifecycle-behavior scan findings, and validation of a clean rebuild. Issue replacement signatures or attestations only after that rebuild and validation are complete.
Evidence basis
Public value history
- 19 Oct 2026Initial public guidanceCurrent guidance
Created the first public value version for this Decision Record.
Source RoundtableMorning roundtableConvened 19 Oct 2026Methodology
How the panel reaches a Public Decision Record.