A dependency patch campaign identifies affected artifacts, replaces the vulnerable component, verifies behavior, and confirms that old artifacts are no longer running. A lockfile update changes future builds; it does not patch already deployed images or retained worker processes. The required urgency depends on exploitability, exposure, and service impact.
Make this comfortable
Dependency patch campaigns: update, test, and prove the running image
Operational decision
A document renderer uses a library with a disclosed parsing flaw. Query the build inventory for images containing the affected package, identify which are reachable by untrusted PDFs, and prioritize those services. Update the lockfile and base image as needed, build once, run malformed-file regression tests, and record the new digest. The shell block shows package verification and test commands, not the inventory query or deployment gate. Roll out the digest through a canary and read back each running Pod's image ID. If the flaw can be reached from a queue, include workers that are not behind the public API. Keep the old digest in a quarantine list; do not delete it before rollback planning is complete, but do not allow accidental redeployment. Verify that the runtime package version changed, not only the manifest text.
npm ci
npm ls pdf-parser --all
npm run test:malformed-documents
npm run buildCost and verification
A rushed patch can break parsing or increase CPU cost. A staged rollout uses extra capacity and time but provides evidence of impact. Inventory errors are common when transitive dependencies, base images, or background workers are omitted. Scanners can disagree on package metadata, so inspect the built artifact and actual runtime when the decision matters. Keep a record of affected services, deployed digests, and exceptions with an expiry; a ticket closed at merge time does not prove risk has left production.
Common Mistakes
- Do not confuse a lockfile change with a deployed fix.
- Do not ignore background workers that process the same untrusted input.
- Do not close the campaign before checking running image IDs.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- CI dependency caches: speed without hidden build inputs
- Software supply chain: SBOM and provenance at admission
- Immutable artifacts and release provenance
- Canary analysis: compare a small cohort without hiding its failures
Practice and check
Supply evidence follow-up
- Package identity: verify advisory matches before changing a release
- Base-image refresh: rebuild and retest when inherited bytes change
Linux host change follow-up
Continue with: Dependency upgrade prompts: trace behavior, not only versions.
devops
operations