A withdrawn duplicate advisory still fails your build gate - how do you unblock the release?

Most people treat advisory data as a fixed reference. It is not. It is a living dataset maintained by humans under time pressure, and a mature programme is built around that fact rather than surprised by it. ## The states a record can be in **Published and current.** The normal case: a record with an affected range and usually a fixed version. **Withdrawn.** The record has been retracted by the database that owns it. The most common reason is duplication - the same flaw was already filed under another identifier, often in a different database - but a record can also be withdrawn when it turns out to describe no real flaw. The aggregating schema represents this explicitly with a `withdrawn` timestamp, and a well-behaved consumer treats a withdrawn record as reportable-no-longer. **Disputed.** Someone, typically the maintainer or vendor, contests the record: they argue the described behaviour is not a vulnerability, or is not reachable in any supported configuration. Crucially, a dispute is not a retraction. The record stands, the identifier stays live, and you have to decide on the technical merits and write down the reasoning. Treating disputed as equivalent to withdrawn is a real mistake - some disputes are wrong. **Rejected.** The identifier was assigned and then determined never to have been valid. **Corrected.** The record stays, but its data changes - most often the affected range, which is the field most likely to be wrong on first publication. A range that was too wide gets narrowed, or a fixed version that was listed incorrectly gets fixed. ## Working the incident When a gate fails on something you believe is retracted, work in this order. First, check data freshness. When did this pipeline's advisory data last update? A build that fails on a record withdrawn days ago is usually reading a cached mirror, and the fix is refreshing it, not overriding anything. This is the single most common cause and the cheapest check. Second, verify at the source rather than from the tool's rendering. Look at the owning database's record and read its status. If it is withdrawn, note the identifier it duplicates and check whether that identifier also matches your dependency - because if it does, the flaw is still real under a different name and unblocking the wrong one leaves you exposed. Third, if the data is right but your pipeline still fires, apply the narrowest possible override: keyed to that identifier and that package, with an expiry date and a reason recorded in the change. Expiry is what stops a suppression outliving its justification; a permanent ignore is how a genuine finding sits unnoticed for a year. Reviewing expired suppressions should be routine work, not an exception path. ## When the record is wrong rather than withdrawn A harder version of this: the advisory is live and not disputed, but its affected range is simply wrong - a version listed as vulnerable that actually contains the fix. Your gate is red on data that no refresh will change. Do both halves. Locally, the same narrow expiring override, with your evidence attached: the commit or release that contains the fix, and the reasoning. Upstream, submit a correction to the database that owns the record - and if it originates from the central record, to the authority that assigned it. This is not altruism. Every consumer of that feed is failing the same build, your customers are among them, and next quarter's questionnaire will cite the same wrong range back at you. A suppression fixes one repository; a correction fixes the input. ## Why interviewers like this question It separates people who consume a scanner's output from people who understand the data behind it. The weak answer is *add an ignore and move on*, which happens to unblock the release and teaches the team that the gate is negotiable. The strong answer treats a red gate as a claim to be verified: check freshness, verify at the source, check the alias the withdrawal points at, then override narrowly with an expiry, and push the correction back where the error lives. That answer also shows you know a gate is only as trustworthy as the data feeding it, and that keeping it trustworthy is ongoing work rather than a one-time configuration.