Release and respond
Respond to a dependency incident
Identify affected releases, stop new exposure, replace or remove the component, rotate reachable credentials, and communicate from verified facts.
8 minute lesson
A malicious or compromised dependency can affect source, build, artifacts, credentials, and users. Scope each layer.
Freeze releases, preserve logs and artifacts, query SBOMs, identify when the component entered builds, and inspect what authority it had. Rotate exposed credentials, produce a clean release from trusted inputs, and notify affected users with specific actions.
A package maintainer account is compromised and a malicious postinstall release runs in CI. It may affect developer clones, build logs, registry credentials, released artifacts, and users at different times.
Deleting the dependency stops future execution but does not revoke credentials already copied. Scope every release and authority the package could reach before declaring recovery complete.
Write a first-hour incident timeline for a malicious package version and identify affected builds through lockfiles, SBOMs, logs, and artifact digests. Save the queries or commands that produce the affected-release list. Then include a build where the package was installed but its script was disabled and show how the impact assessment changes.
Lesson completed