DevOps supply chain

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.

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.

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.

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 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.

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.

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.

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.

Response to a credential-stealing npm package

Organizations should inventory development and build environments for the malicious package and investigate whether it executed. Confirmed execution should trigger rotation of potentially exposed developer and cloud credentials and invalidation of affected sessions.

Contain suspected malicious npm package execution

Where affected package execution is possible, pause installation, build, release, and publication workflows. Preserve evidence, rotate exposed credentials, use verified-clean versions, and rebuild on fresh infrastructure before publication resumes.

Private package namespace dependency-resolution freeze

Teams with private package names that may overlap public registry namespaces should temporarily freeze dependency changes, force builds to intended private registries, review CI logs and lockfiles for unexpected public fetches, and rotate build secrets if a suspicious build ran. Do not state that every named package or build is compromised without package-level evidence.

Freeze executed developer-trust paths after malicious packages or extensions

When a validated malicious package, extension, or developer-tool impersonator may have executed, freeze and quarantine the affected developer-trust path, preserve artifacts, rotate exposed repository, cloud, package, and wallet credentials, and rebuild from clean images where payload execution, persistence, or secret exposure is plausible. Use trusted indicator lists for exact package and extension scoping.

CI/CD release freeze for exposed TeamCity and risky npm changes

→Pause release builds triggered by exposed or suspect TeamCity infrastructure and apply risk-based holds on high-risk npm dependency changes until the build path is investigated, dependencies are pinned, and build-job credentials are rotated.

Engineering teams with exposed or suspect TeamCity infrastructure should pause affected release builds, preserve and investigate CI evidence, pin high-risk dependencies, and rotate credentials available to build jobs. npm dependency holds should remain risk-based unless package-specific evidence is added.

npm supply-chain credential exposure response

→Freeze affected npm promotion paths, block verified affected package versions, rebuild CI runners where install scripts may have executed, audit lockfiles and publish history, and rotate npm, GitHub, cloud, Kubernetes, and vault credentials where exposure is plausible.

Engineering teams should separate clean build paths from npm paths that may have installed verified affected malicious versions. For exposed paths, pause promotion, rebuild potentially affected runners, audit dependency and publish history, and rotate credentials that may have been accessible during install-time execution.

Separate tracking for distinct incident classes

→Do not treat the discussed incidents as one homogeneous campaign on the current packet evidence. Track separate evidence classes for CI/CD control-plane abuse, water-sector operational control exposure, identity trust abuse, cloud malware, SaaS or token exposure, and supply-chain activity until shared technical pivots justify merging them.

On the current packet evidence, do not merge the discussed activity into one broad campaign. Track the incident classes separately and revisit the linkage decision if credible shared technical pivots are attached.

Clean rebuild and secret rotation after developer or CI exposure

→When indicators or confirmed exposure show malicious packages or trojanized installers touched developer workstations, CI runners, or publishing paths, rebuild affected systems from clean sources, rotate npm, Git, cloud, package-publishing, signing, and service-account secrets, and review artifacts and release logs before normal release activity resumes.

Where local telemetry or confirmed exposure shows malicious package or installer activity in developer, CI, or publishing environments, rebuild affected hosts or runners from clean sources, rotate reachable development and publishing secrets, and review build artifacts and release logs before returning to normal release operations.

Developer-tool one-click execution patching

→Engineering fleets, especially privileged developer workstations, should patch vendor-confirmed fixed releases immediately. Review telemetry for editor-launched shells or credential tooling after commit-link activity, and rotate GitHub, npm, cloud, CI, or signing credentials only where execution is suspected or privileged telemetry is missing.

Engineering teams should update Cursor, VS Code, and Google Antigravity to vendor-confirmed fixed releases and review privileged developer telemetry for signs of editor-launched execution after suspicious commit-link activity. Credential rotation should be targeted to suspected execution or missing privileged telemetry.

Shai-Hulud npm publishing and CI/CD containment

→Do not reopen npm publishing and CI/CD normally after Shai-Hulud package cleanup. Freeze risky publishing and dependency updates, identify affected direct and transitive paths from local lockfiles and inventories, hunt build hosts and developer endpoints, rotate reachable developer, cloud, and CI secrets, rebuild runners, and restore release authority only from clean credentials and verified packages.

Teams recovering from the Shai-Hulud npm compromise should keep risky publishing and dependency updates frozen until package inventory, developer and build-host review, secret rotation, and runner rebuilds are complete. Precise affected-version claims should come from authoritative package evidence or local verification.

Govern privileged AI agents as untrusted automation

→Yes. Treat AI agents with CI/CD, cloud, browser, or internet authority as untrusted automation by removing long-lived secrets, using least-privilege tokens, separating read-only from write-capable agents, requiring human approval for privileged actions, blocking production credentials, filtering egress, logging tool calls, and alerting on unexpected workflow or secret-handling behavior.

Treat AI agents that can touch CI/CD, cloud, browser, or internet workflows as untrusted automation: remove long-lived secrets, use least privilege, require human approval for privileged actions, block production credentials, control egress, log tool calls, and monitor unusual workflow or secret-handling behavior.

AI-mediated CI privileged automation controls

→Treat AI agents and AI-mediated CI workflows as untrusted automation principals. Do not allow untrusted issues, comments, model output, or agent messages to directly drive privileged CI/CD or cloud actions; disable autonomous merge, deploy, and remediation authority until reviewed; use least-privilege short-lived credentials, deny-by-default sandbox egress, and human approval for privileged steps.

Treat AI agents and AI-mediated CI workflows as untrusted automation. Keep untrusted content and model output from directly triggering privileged build, deploy, cloud, or remediation actions. Require human approval for privileged steps, use short-lived scoped credentials, isolate secrets, and deny sandbox egress by default.

ChainDrop npm credential-compromise response

→Treat ChainDrop exposure as developer and CI/CD credential compromise rather than simple package cleanup. Revoke and recreate package, source-control, cloud, Vault, Kubernetes, federation, registry, and build-system credentials; disable affected runners and publishing paths; rebuild clean workspaces; and block dependency versions identified by validated intelligence before restoring trusted publishing.

Treat the ChainDrop npm exposure as a developer and CI/CD credential-compromise event. Rotate automation and publishing credentials, rebuild affected runners from clean images, pause risky publishing paths, and block affected package versions using validated inventory sources.

Provenance is not enough after malicious package reports

→Do not accept signed provenance or attestations alone as a release gate after reported malicious packages. Pause upgrades along suspect dependency paths, revoke reachable developer and CI/CD tokens, pin known-good versions by digest, quarantine builders and caches that pulled suspect artifacts, and require independent source-to-artifact review.

Where inventory shows suspect packages or dependency paths, do not rely on provenance alone. Pause affected upgrades, rotate reachable developer and build credentials, pin known-good artifacts by digest, quarantine systems and caches that consumed suspect packages, and require independent review from source to artifact before release.

Compromised build response for affected TanStack installs

→Teams that confirmed installation of affected TanStack npm packages should treat the relevant build and release environment as potentially compromised: freeze affected releases, preserve package and CI evidence, pin known-good versions by digest, rotate or revoke credentials reachable from affected contexts, invalidate CI caches, review publishing workflows, and rebuild CI/CD trust roots before normal releases resume.

For confirmed affected TanStack npm installs, pause affected releases, preserve dependency and CI evidence, pin known-good package versions, rotate or revoke credentials reachable from the affected developer, build, publishing, deployment, or workload contexts, invalidate caches, and rebuild clean release trust before resuming normal activity.

Same-day controls for TeamCity On-Premises

→Treat affected TeamCity On-Premises instances as a same-day CI/CD emergency: freeze sensitive releases, restrict network access, upgrade to vendor-fixed releases, then rotate build credentials and secrets exposed to the orchestrator.

Teams running affected TeamCity On-Premises environments should treat the issue as an urgent CI/CD control-plane matter, restrict exposure, apply vendor-fixed releases, and rotate exposed build secrets after patching.

AsyncAPI package supply-chain containment

→For projects with affected AsyncAPI tooling in the build or runtime path, freeze npm installs and releases, remove malicious versions, rebuild on clean runners, rotate reachable npm and CI secrets, and verify lockfiles and SBOMs.

If your project uses AsyncAPI tooling reported as affected, pause installs and releases, remove affected package versions, rebuild on clean runners, rotate reachable npm and CI secrets, and verify lockfiles and SBOMs. Name exact affected or fixed versions only after confirming primary package or maintainer guidance.

Build-and-publish trust response for npm and CI exposure

→Treat confirmed npm package compromise or build-server exposure as a build-and-publish trust failure. Freeze affected releases, rotate CI, package-registry, cloud, signing, and deployment tokens, audit publish rights and workflow permissions, rebuild important artifacts on clean runners with pinned dependencies, and use SBOMs and lockfiles to identify direct and transitive exposure.

When a package or build system is confirmed affected, teams should freeze affected releases, rotate publishing and deployment credentials, audit publish rights and CI workflows, rebuild important artifacts from clean runners, and use SBOMs or lockfiles to find direct and transitive exposure. Avoid precise package or actor claims unless separately sourced.

Joyfill supply-chain CI/CD trust reset

→Freeze reported affected Joyfill prerelease consumption and high-privilege deployments; remove malicious packages or workflows where verified; isolate build runners; rotate CI/CD, repository, cloud, registry, and package-publishing secrets from clean systems; and seek vendor provenance assurance before promotion.

For reported affected Joyfill prereleases or related workflows verified in an environment, pause consumption and high-privilege deployments, contain build infrastructure, remove confirmed malicious artifacts, rotate exposed build and cloud secrets from clean systems, and wait for authoritative package scoping before promotion.

CI/CD audit for GitHub Actions and npm supply-chain exposure

→Platform teams should audit repositories using GitHub Actions and npm in pull-request or release workflows, including dependency lockfiles, CI logs, runner secret reachability, release tokens, package publish tokens, and credential rotation where untrusted code may have executed near sensitive authority.

Platform teams should audit repositories where GitHub Actions workflows install npm dependencies or handle releases, checking whether untrusted code could have run near secrets or publishing authority and rotating credentials when exposure is plausible.

RubyGems SleeperGem secret-exposure triage

→Treat affected RubyGems execution paths as possible secret-exposure paths across CI, build, release, and developer environments. Inspect dependencies, lockfiles, cached gems, build images, bootstrap scripts, and internal templates; review telemetry; restrict build egress; add package-change gates; and rotate credentials that were confirmed or likely exposed.

Treat affected RubyGems execution paths as potential secret-exposure paths where code ran near secrets. Inspect dependencies and build or developer environments, review telemetry, restrict build egress, add package-change gates, and rotate credentials that were confirmed or likely exposed.