What is the difference between time-boxing a dependency finding's suppression and ignoring it permanently?

## Why suppression exists at all A dependency scanner reports what your artifact contains that matches a published advisory. Some of those matches are wrong, some are right but irrelevant to how you use the component, and some are right and relevant but cannot be fixed today. If every finding blocked the build with no escape hatch, teams would either stop scanning or route around the gate — so a suppression mechanism is not a compromise of the program, it *is* the program's pressure valve. The engineering question is what that valve records and whether it ever closes again. ## The two shapes of "not now" It helps to separate the reason classes before arguing about duration: | Reason class | Example | Right treatment | |---|---|---| | Wrong match | The component identity in the report is not the package you ship, or the match is on a name rather than a package identity | Permanent — there is no risk decision here, just a data error | | True but not currently exposed | The vulnerable function is never called; the component is a test-only dependency | Time-boxed — the code changes, so the premise expires | | True, exposed, not fixable now | The fix is a major version with breaking API changes | Time-boxed and short — this is a scheduling decision, not a verdict | Only the first is a candidate for permanence, and even then a re-check when the scanner's data changes is cheap insurance. The other two rest on facts about your code and your calendar, and both move. ## What a time box actually buys An expiry converts a silent state into a scheduled conversation. Three things follow. First, the queue self-cleans: a suppression made under release pressure gets a second look when nobody is under pressure. Second, the backlog becomes measurable — you can count active suppressions, chart their age, and see the ones that have been renewed four times, which is usually a signal that the real answer is "replace this dependency". Third, the record becomes defensible: at expiry someone either re-affirms the reasoning or fixes the thing, and either way there is a dated trail. The classic failure is auto-renewal. If an expiring suppression quietly extends itself because nobody triaged it, a 30-day time box is a permanent ignore with extra paperwork. Expiry should fail loudly: the finding reappears, blocks the same gate it blocked before, and needs the same approval to be suppressed again. ## The 6pm problem The scenario every program eventually hits: an engineer is trying to cut a release, a blocking finding appears, and the fastest path to green is a permanent ignore added to the scanner's configuration. Nobody is acting maliciously — the shipping deadline is real and the finding may well be irrelevant. But the artifact of that evening is a rule that suppresses the finding for every future build, in a configuration file nobody reads, with no reason, no approver and no date. Six months later the same component becomes genuinely exploitable in your code path and the scanner stays green. The control that changes this is not "forbid suppressions" — that just pushes the pressure somewhere worse. It is making the *time-boxed, attributed* suppression the fastest path: a one-line entry that requires a reason class, an approver and a maximum duration, and that is easier to add than editing scanner configuration. Make the safe move the cheap move. Pair it with a rule that suppressions live with the finding record rather than in build configuration, so they are visible on a dashboard instead of buried in a repository. ## What the record must carry A suppression that cannot be explained later is worth very little, so capture at the time of the decision: - the exact component identity and the affected version range, not just an advisory number; - which service or artifact the suppression applies to — never a blanket estate-wide rule; - the reason class and one sentence of specific reasoning; - the named human who approved it, distinct from the one who requested it; - the expiry date, and what fact would invalidate the decision before then. That last item is the one people skip and the one that matters most: "this expires early if the component starts being called from request-handling code" turns a static note into a condition someone can check. ## Anti-patterns worth naming out loud Suppressing by severity threshold rather than per finding — that is not triage, it is turning the scanner down. Suppressing at the tool's global configuration level so the finding never reaches the queue. Treating a suppression as equivalent to a fix in reporting, so the compliance number looks identical whether you patched or hid. And using a suppression to stop a remediation clock: hiding a finding does not reduce exposure, and a program that lets suppression reset the clock will always report excellent numbers and carry terrible risk.