Cyber Decision LedgerTechnology
DevOps supply chain
43 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
Private package namespace dependency-resolution freeze
For builds exposed to a reported private namespace dependency-confusion pattern, freeze dependency resolution, pin package managers to intended private registries, audit CI logs for unexpected public package fetches, compare lockfiles against approved internal names, and rotate CI/CD secrets exposed during suspicious builds.
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
Freeze and quarantine CI jobs, build runners, publish workflows, and developer workstations where suspect npm packages, WEL1DROPPER or Sliver activity, malicious VS Code extensions, or AI-tool impersonators were installed or executed. Preserve artifacts first, rotate repository, cloud, package, and wallet credentials, and rebuild from clean images when payload execution, persistence, Sliver, or secret exposure is plausible.
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.
Exposed AI and developer tools as control-plane credential risk
Remove public exposure from Langflow, Docker API, Jenkins, Ollama, and ComfyUI; isolate before routine patching; revoke before rotating cloud, Kubernetes, Jenkins, database, MinIO, deploy, and CI/CD credentials; sandbox untrusted repositories; require review for workflow changes; allowlist developer extensions; and move developer secrets to short-lived scoped credentials.
Treat internet-exposed AI, developer, and automation services as possible control-plane credential exposure. Remove exposure, isolate affected services, revoke or invalidate reachable secrets before rotation, and apply repository, workflow, extension, and short-lived credential controls. State the environment-specific scope only after inventory and telemetry confirm it.
Credential-exposure response for executed malicious npm packages
When malicious npm package lifecycle scripts ran where secrets were reachable, treat the event as a credential-exposure incident. Confirm execution, map reachable secrets, rotate only exposed secrets, freeze polluted rebuilds, pin known-good artifacts, and strengthen install-script and provenance controls.
If malicious package code actually executed in a developer or CI environment where secrets were reachable, handle the event as potential credential exposure. Confirm execution, identify which secrets were reachable, rotate only those at risk, stop polluted rebuilds, pin known-good artifacts, and add install-script and provenance safeguards. Lockfile-only presence should be treated as dependency verification rather than automatic broad rotation.
Developer supply-chain response scoped by execution and secrets
Scope response by execution and secret reachability: determine whether flagged packages or tooling ran, rotate only credentials those systems could access, and revoke abused signing or publishing trust.
For flagged npm packages or trojanized developer tooling, first determine whether the package actually executed on developer workstations or CI. Rotate only credentials reachable from affected contexts and revoke abused signing or publishing trust.
Credential-exposure response for malicious developer package installs
Validate developer workstations and CI runners for affected installs. If install-time execution and secret reachability are confirmed, rotate npm, GitHub, cloud, CI, signing, publishing, and wallet credentials; strengthen package-publishing controls and avoid blind enterprise-wide rotation.
For malicious developer package installs, validate developer endpoints and CI paths first. If install-time execution and secret reachability are plausible or confirmed, rotate reachable developer, cloud, CI, signing, publishing, and wallet credentials, and strengthen publishing controls without defaulting to blind enterprise-wide rotation.
Use scoped containment for developer supply-chain exposure
Scope exposure to affected jscrambler, ModHeader, and poisoned Go-module paths; rotate reachable developer, CI/CD, cloud, signing, registry, browser, and AI-tool secrets where malicious code executed; quarantine affected build paths; pin known-good versions identified by local inventory; rebuild artifacts from clean runners; and add provenance checks.
Developer supply-chain incidents should be handled by scoping actual execution paths, rotating secrets reachable from affected environments, rebuilding from clean runners, and adding provenance controls rather than freezing unrelated engineering activity.
Escalate GitHub ghost-account API reconnaissance to source-control response
Enable and stream GitHub api.request audit events, hunt dormant-account enumeration and unusual user agents, correlate enumeration with private-repository cloning or access anomalies, revoke abnormal PAT/OAuth tokens, expire stale PATs, review OAuth grants, and remove dormant external collaborators.
GitHub organizations should improve audit visibility for API-request activity and investigate dormant-account enumeration, unusual user agents, token or OAuth abuse, stale PATs, dormant external collaborators, and unexpected private-repository access; enumeration should not be described as confirmed source exfiltration unless clone or export evidence is found.
Quarantine affected Injective developer and crypto trust paths
Quarantine builds or applications using affected Injective-related packages, block confirmed risky package/version ranges at artifact proxies, rebuild from clean dependencies, rotate npm/GitHub publishing and reachable development credentials, and treat wallet or treasury material generated or imported through confirmed affected SDK paths as exposed by migrating to fresh signers.
Where Injective-related package exposure is confirmed, quarantine affected builds, rebuild from clean dependencies, rotate reachable development and publishing credentials, and migrate wallet or treasury material generated or imported through confirmed affected SDK paths before resuming normal operations.
Contain unverified internet-facing Gitea Docker deployments pending proxy-auth verification
For internet-facing official Gitea Docker deployments in the packet-described vulnerable set or with unknown reverse-proxy-auth or trusted-proxy configuration, block direct public access, allow only known reverse-proxy or VPN sources, preserve logs, upgrade after staging, and hunt for X-WEBAUTH-USER impersonation, repo changes, token creation, webhook changes, and CI/CD credential abuse.
For internet-facing Gitea Docker deployments with unverified proxy-auth or trusted-proxy configuration, restrict direct public access while configuration and exposure are verified, preserve logs, upgrade through a staged path, and hunt for account, repository, token, webhook, and CI/CD abuse indicators.
Sandbox privileged AI coding agents and MCP-connected tools
Disable or sandbox privileged AI coding agents and MCP-connected tools that can execute shell commands, write outside workspaces, auto-approve tools, reach networks, reuse browser sessions, access credentials, install packages, push or merge code, invoke cloud administration, or access secrets-bearing CI/CD contexts; restore only with sandboxes, ephemeral credentials, explicit high-risk approvals, and prompt-to-tool logging.
Privileged AI coding and MCP-connected tools should be disabled or sandboxed when they can execute commands, access secrets, write outside a workspace, use network egress, reuse sessions, install packages, alter repositories, invoke cloud-admin actions, or access CI/CD secrets. Restore capabilities only with project sandboxes, ephemeral credentials, explicit approvals, and complete prompt-to-tool logging.
Treat compromised Injective npm SDK exposure as key compromise
Stop using affected Injective npm SDK builds, move to verified clean releases, rotate related API and build secrets, and migrate funds to fresh wallets generated on clean machines when mnemonic or private-key exposure is possible.
Where an Injective npm SDK build may have exposed mnemonics or private keys, teams should treat it as key compromise: remove affected dependencies, use verified clean releases, rotate related secrets, and migrate funds to fresh wallets generated from clean systems.
Freeze affected package lanes and audit build pipelines for reported malicious packages
Freeze only affected npm, NuGet, and package-build lanes; verify SBOMs, lockfiles, package names, versions, hashes, publishers, source repositories, and provenance; remove or replace reported affected packages after registry or vendor validation; rotate exposed CI, GitHub, cloud, payment, and wallet-related secrets if affected packages ran in developer or build environments.
Engineering teams should freeze only package and build lanes that may have touched the reported affected packages, then validate SBOMs, lockfiles, artifact caches, CI logs, package provenance, and secret exposure. Remove or replace affected package versions after registry or vendor validation, and rotate secrets if those packages ran in developer or build environments. Exact version claims remain source-reported until primary registry or advisory evidence is attached.