How can artifact management and CI identify affected services and block deployments?
Tests supply chain forensics and CI gating. Strong answers hit: SBOMs mapping transitive blast radius; artifact metadata tracing deployed versions; scan gates and quarantine policies blocking promotion.
What's really being asked
Your ability to use artifact repositories and CI pipelines as security control planes rather than just storage and automation. The interviewer wants to know if you understand how to generate and query software bill of materials at build time, how immutable artifacts with provenance metadata enable forensic tracing, and how to implement automated gates that prevent vulnerable code from reaching production. It also tests whether you think in terms of blast radius and systematic quarantine versus one-off fixes.
The full answer
Four capabilities in order. First, SBOM generation during CI builds that captures the complete dependency graph including transitive libraries, making it possible to query which artifacts contain the vulnerable package. Second, a private immutable artifact repository that stores binaries alongside build provenance, vulnerability scan results, and dependency metadata, allowing reverse lookups from a CVE to every affected artifact and service. Third, automated pipeline gates including dependency scanning and policy enforcement that fail builds or block promotion when a quarantined dependency version is detected, stopping the vulnerability before deployment. Fourth, runtime inventory integration that correlates currently deployed container images or application packages with the artifact repository metadata to generate an instant list of affected production services.
The mistakes people make
Suggesting manual grep across source code repositories to find the dependency, which misses transitive relationships and is slow at scale. Proposing to update only the failing service without understanding the blast radius across the fleet. Describing artifact repositories as simple file storage rather than security metadata systems. Failing to mention SBOMs or provenance and relying solely on post-deployment runtime scanning, which detects issues too late. Saying you would block all deployments globally rather than targeting the specific vulnerable artifact.
What usually comes next
How would you handle a vulnerability in a dependency that is itself a dependency of a widely used internal shared library? What is your strategy when the vulnerable transitive dependency is two or three levels deep and not directly declared in any service? How do you balance deployment velocity with security gating when a critical CVE has no patch available yet? How would you verify that an artifact rebuilt after remediation is actually free of the vulnerable transitive path?
A concrete example
Suppose a critical CVE is published for log4j-core version 2.14.1, which is a transitive dependency pulled in by a popular Spring Boot starter across fifty microservices. During CI, each service build generates a CycloneDX SBOM and publishes it to Artifactory alongside the container image. The artifact repository indexes every dependency relationship. You query the repository for artifacts containing log4j-core 2.14.1 and receive a list of forty-seven affected services. Simultaneously, the CI pipeline has a quarantine policy that checks the repository vulnerability database; any new build attempting to package the banned version fails at the build stage, and existing builds with that version are blocked from promotion to staging or production. The artifact repository metadata also maps each deployed image to its SBOM, so your runtime inventory immediately shows exactly which production pods are running the vulnerable version.
Interview question
A transitive dependency two levels deep has a critical CVE. Which approach best identifies all affected production services and blocks vulnerable deployments?
- a.Rely on production runtime scanners to flag affected containers, then patch and redeploy only the services that trigger alerts
- b.Block every deployment pipeline globally while engineers manually grep source repositories for the vulnerable package
- c.Query the immutable artifact repository using build-time SBOMs to map the blast radius, enforce quarantine gates in CI, and correlate with runtime inventoryCorrect
- d.Rebuild the internal shared library that pulls in the dependency and redeploy all downstream services without artifact metadata verification
Why? this is the answer
Build-time SBOMs and immutable artifact metadata enable precise reverse lookup from a CVE to affected artifacts and automated CI gates that block promotion before deployment, whereas relying solely on runtime scanning detects the vulnerability too late and does not prevent initial rollout.
Just read this? Test yourself on what you have been reading.
Read the original → cheatsheetseries.owasp.org
- #ci/cd
- #supply chain security
- #artifact management
- #sbom
- #dependency management
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles