Identify impacted artifacts — what used the bad version

A malicious dependency in the lockfile produces suspect artifacts. Every container image, build artifact, and deployable built from a lockfile that resolved to the malicious version is suspect: a backdoored binary, a credential exfiltrator, a deployable whose install hook ran the attacker’s payload. The inventory is built from the build provenance and used to scope the rebuild.

The artifact classes

A build that resolved the malicious version produces four classes of artifact:

flowchart LR
    A["lockfile with malicious version"] --> B["container images"]
    A --> C["build artifacts"]
    A --> D["release tarballs"]
    A --> E["signed attestations"]
    B --> F["registry scope"]
    C --> G["artifact store scope"]
    D --> H["deployable scope"]
    E --> I["trust scope"]

• Container images. Pushed to the registry during docker build and docker push. The image digest is the artefact consumers reference.
• Build artifacts. Uploaded to the workflow artifact store during actions/upload-artifact steps.
• Release tarballs. Packaged by the release workflow and uploaded to the release page.
• Signed attestations. Cosign signatures, in-toto attestations, SLSA provenance. The signature was made by a build that resolved the malicious version.

Building the artifact inventory

The inventory is built from two sources and reconciled:

gh api /repos/OWNER/REPO/actions/runs \
  > workflow-runs-$(date -u +%FT%TZ).json
gh api /orgs/ORG/packages/container/IMAGE/versions \
  > registry-versions-$(date -u +%FT%TZ).json
git log --all --oneline -- package-lock.json \
  --since "$MALICIOUS_PUBLISH_TIMESTAMP"

The reconciliation cross-references every workflow run that resolved the malicious version against a registry version. A mismatch is the highest-priority finding.

The decision rule

Every artifact built from a lockfile that resolved the malicious version in the compromise window is suspect. The window starts at the publish timestamp and ends at the moment the lockfile pin is committed. The rule is unconditional: a build that ran before the publish is not in the window. The lockfile diff against the publish timestamp is the mechanical gate:

trivy fs --security-checks vuln .

Invalidation versus deletion

For each artifact, the team chooses between invalidation and deletion:

• Invalidation marks the artifact as compromised. Consumers see a warning when they pull. The bytes remain for forensic analysis. The default for container images that may still be running.
• Deletion removes the bytes. Consumers fail when they pull. The default for build artifacts already consumed and for confirmed-backdoored images.

Production discipline

1. Inventory before action. The artifact inventory drives the rebuild scope; missing an artifact means missing a backdoor.
2. Lockfile as the gate. The publish timestamp and lockfile diff are the mechanical gate.
3. Reconcile the three sources. The workflow run history, the registry metadata, and the lockfile history must agree.
4. Invalidate by default. Destructive actions are reserved for confirmed-backdoored artifacts.

Cross-course references

• Git, CI/CD & GitOps — Part LXVII-06 (Package Pinning and Lockfiles) covers the lockfile shape the inventory reads.
• Git, CI/CD & GitOps — Part LXXI-04 (Dependency Compromise Attack) covers the four shapes of dependency-compromise attack.
• Container Security for Production Sysadmins — Part V (Image Scanning) covers the registry-side validation patterns the invalidation action requires.

Quiz