Cyber Decision LedgerDecision area
Supply chain
67 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
AOMEI update-path response thresholds
Use execution evidence to determine the response. Metadata contact should trigger review; payload retrieval combined with telemetry gaps warrants precautionary escalation; and evidence of execution, persistence, command-and-control, or credential access requires isolation, rebuilding, and credential response.
Response to verified compromised npm build exposure
When an independently verified package name, exact version, and integrity hash intersects a build, stop the affected release, quarantine relevant runners, caches, and artifacts, preserve build evidence, rotate credentials and signing assets reachable by the affected build identities, and rebuild from known-good inputs on clean infrastructure.
Approval Controls for AI-Generated Dependencies
AI coding workflows should not autonomously install newly generated package names. Organizations should use approved registries, require human review for new dependencies, and block packages that are absent from approved dependency records.
Hunting and Containment for the Reported Malicious imgdecode Package
Organizations should validate reports concerning imgdecode version 1.0.3, search relevant dependency records, caches, registries, build runners, and Windows hosts, and contain systems where execution or compromise is confirmed. Rebuilding and credential rotation should be based on evidence of execution, secret access, or host compromise.
Audit npm Trusted Publishing relationships
Organizations using npm Trusted Publishing should audit publisher configurations against immutable repository identity, remove dormant relationships, investigate unexpected repository or publication changes, restrict release-token permissions, and verify unexplained downstream artifacts before restoring trust. The repository-reclamation exposure should be described as reported unless corroborated by an authoritative source.
Rescan Open VSX extension artifacts after fail-open scanning
Organizations should rescan exact approved Open VSX extension artifacts that do not have a verifiable successful post-fix scan. If the affected-period start is unknown, this fallback should cover every currently approved artifact without such verification. Remove exact versions when malware or integrity findings warrant it, and begin credential investigation only when a plausible activation path, confirmed execution, or suspicious endpoint behavior is present.
Containment of the reported Tensorlake SDK compromise
If your environment contains Tensorlake npm SDK version 0.5.144, which the reviewed reporting identifies as affected, pause installation and release activity, remove cached copies, isolate systems where installation hooks ran, rotate reachable developer and cloud credentials, investigate workflow propagation, and rebuild from reviewed source. Treat the precise release and provenance attribution as reported until confirmed by a primary source.
Independent verification of third-party patch completion
For critical third-party patches, require independent evidence of installation and external exposure closure. Contractor assignment or patch availability alone should not be treated as completed remediation.
Recovery after malicious pipeline workflow exposure
Recovery from malicious pipeline workflows should include evidence preservation, removal of attacker access, revocation of affected identities and sessions, restriction of exposed federation paths, rotation of reachable credentials, and investigation of downstream use. Signing credentials should be included only when runner access is established.
Inventory and conditional withdrawal of low-cost Android devices
Inventory employer-issued low-cost Android devices without treating the category itself as proof of compromise. Withdraw or quarantine a device only when validated firmware-level or privileged-persistence indicators establish compromise.
Response to suspected Tensorlake package execution
Block Tensorlake version 0.5.144 pending validation. If evidence indicates installation code may have run, freeze affected releases, isolate runners, preserve CI/CD evidence, and rotate reachable credentials from clean systems. Treat reported malware-family attribution and release-provenance details as unconfirmed unless authoritative evidence is added.
GhostAction repository and runner remediation
Organizations affected by the reported GhostAction campaign should audit each affected repository, revoke CI/CD secrets shown to have been exposed, review workflow and identity activity, and rebuild runners where malicious workflows executed or system integrity cannot be restored.
Containment of malicious package and developer-tooling exposure
Using an authoritative component and indicator inventory, block and remove identified malicious packages or tooling. Determine whether each component was downloaded, installed, or executed; quarantine hosts with execution evidence; investigate exposed credentials and repositories; and verify or rebuild downstream artifacts from a clean environment when propagation cannot be excluded. Do not treat download totals as compromise counts.
Publishing pause after release-pipeline trust failure
Organizations should consider pausing software publication and dependency intake when untrusted contributions may have reached privileged release workflows. Recovery should include revoking publishing and automation credentials, rebuilding from trusted commits on fresh infrastructure, verifying artifacts and provenance, and clearing affected caches and dependency trees. This is a conservative control threshold that each organization should validate against its own release architecture and risk tolerance.
Short-lived identities for software publishing
Software release workflows should avoid long-lived publishing credentials. Use supported short-lived, narrowly scoped, workflow-bound identities, or the narrowest and shortest-duration alternative available on each platform.
Harden hot-wallet authorization after third-party access
Organizations responding to similar hot-wallet incidents should revoke reachable privileged access, require independent multi-party authorization, use short-lived task-scoped identities, and enforce transaction safeguards. Third-party tooling should be isolated from wallet access when investigation confirms that it is implicated or has an unsafe access path.
Containment of suspected GitHub Actions compromise
Organizations using GitHub Actions reported as affected should pause those dependencies, preserve workflow and runner evidence, identify actual executions through mutable references, quarantine and rebuild self-hosted runners that processed suspect jobs, rotate credentials exposed to those jobs, and pin reviewed dependencies to immutable commits.
Characterizing reported MemOS propagation capability
Published reporting indicates that the malicious releases may contain propagation-related functionality, but the supplied evidence does not establish successful self-propagation. They should not be described as a confirmed worm without authoritative technical confirmation.
Precautionary controls for third-party SCADA access
As a precaution, affected SCADA customers should review every third-party access path, remove dormant or shared access, rotate potentially reachable secrets, require named accounts and multifactor authentication, and route approved sessions through a recorded jump host. Avoid implying confirmed credential or customer-system exposure without authoritative incident evidence.
Responding to GitHub App private-key exposure
Organizations affected by reported GitHub App private-key exposure should preserve audit and configuration evidence while revoking exposed keys. They should map each affected app to its installations, permissions, repositories, workflows, runners, environments, and reachable credentials; suspend high-impact installations where necessary; investigate execution paths; and validate repository and artifact integrity. Exposure alone should not be described as confirmed misuse.
Containing compromised industrial-control integrator access
When an industrial-control integrator is reported compromised, critical-infrastructure operators should suspend unattended, shared-credential, and engineering-capable access at the operational-technology boundary. Essential support should continue only through named accounts, operator-controlled jump hosts, multifactor authentication, least privilege, and recorded sessions. Preserve evidence without abruptly disconnecting controllers or conducting intrusive scans that could affect safe operations.
Response to compromised package execution
When a confirmed compromised package executes in a developer or CI environment, isolate the workload, block the implicated release, preserve evidence, eradicate malicious activity using validated procedures, and rotate credentials accessible to the execution context.
Containment after malicious Terraform provider execution
When a Terraform provider or module is confirmed to have executed malicious code, isolate the affected systems. As a precaution, rebuild affected execution environments from trusted media and invalidate credentials and sessions that may have been exposed.
Contain suspicious npm package execution
Organizations should hunt development environments and build systems for implicated package artifacts and install-time execution. If identified, isolate affected hosts and runners, pause publishing, revoke exposed tokens, rotate CI/CD secrets, inspect repositories and workflows, and rebuild from trusted dependencies and lockfiles.
Minimum response to suspected development supply-chain compromise
For suspected development supply-chain compromise, preserve volatile and provenance evidence before reimaging, quarantine potentially affected artifacts, audit build workflows and publishing identities, revoke reachable credentials and sessions, correct overbroad federation trust, and verify clean rebuilding and provenance before restoration.
Targeted containment for Ruby package and documentation-build activity
Use targeted package and account quarantine, investigate unsafe documentation-build behavior, and maintain unaffected publishing under heightened review. Isolate affected workers and rotate reachable credentials when execution or exposure is reasonably indicated.
Artifactory management-plane compromise response
For potentially affected self-hosted Artifactory deployments, restrict public administrative access, consult vendor guidance and upgrade to a verified fixed release, revoke unauthorized accounts and tokens, rotate reachable credentials, inspect repository changes, and verify downstream artifacts before deployment.
Organizations using self-hosted Artifactory should treat reported management-plane exploitation as grounds for urgent precautionary action. Restrict administrative exposure, apply vendor-verified remediation, review accounts and tokens, rotate reachable credentials, inspect repository changes, and independently verify downstream artifacts.
Release promotion after Artifactory administrator takeover
Immediately stop promotion through trust paths connected to the compromised Artifactory authority boundary, upgrade using vendor remediation, rotate reachable credentials, and reopen demonstrably isolated paths only after independent artifact, provenance, and log verification.
After an Artifactory administrator takeover, suspend release promotion through connected trust paths. Upgrade using vendor guidance, rotate reachable credentials, and reopen isolated paths only after independent artifact, provenance, and external-log verification restores confidence.
Reconnection conditions after a concealed system interface
Following public reports of unauthorized commands through an undocumented interface, keep the affected system isolated until evidence is preserved, access is revoked, a trusted rebuild is independently reviewed, and complete provenance and interface inventories are established.
Registry package trust after source divergence
When execution of an affected registry package is established, quarantine the environment and derived artifacts, verify registry contents against source-bound provenance, and assess accessible credentials for prompt rotation. Package presence alone should be treated as exposure rather than proof of execution.