How do you know if a vulnerability disclosure programme is working?

Why This Matters for Security Teams

A vulnerability disclosure programme is only useful if it turns external reports into measurable risk reduction. Security teams often focus on volume, but that can hide the real question: are reporters getting a usable intake path, are duplicates being collapsed quickly, and are valid findings actually getting fixed? Guidance from CISA cyber threat advisories and the operational patterns highlighted in Top 10 NHI Issues both point to the same practical truth: intake without response discipline creates noise, not resilience.

For NHI-heavy environments, the stakes rise quickly because disclosures often involve API keys, service accounts, tokens, or exposed automation paths. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 91.6% of secrets remain valid five days after notification, which means disclosure quality and remediation speed are tightly linked. If the programme cannot separate credible reports from clutter, the queue becomes a storage location for unresolved exposure rather than a control that reduces it. In practice, many security teams encounter programme failure only after maintainers stop accepting reports or attackers exploit a disclosed weakness before remediation is complete.

How It Works in Practice

Working programmes are observable at each stage of the disclosure lifecycle. Intake should be simple and specific enough for reporters to submit reproducible evidence, while triage should rapidly separate duplicates, low-signal submissions, and reports that require escalation. The programme then needs a clear remediation path with ownership, severity rules, and feedback loops back to the reporter. External guidance such as CIS Controls v8 and ENISA Threat Landscape both reinforce the importance of repeatable handling, timely response, and traceable corrective action.

In NHI and agentic environments, programme health is not just about the bug itself. A report may expose a hardcoded token, a weak offboarding process, or an over-permissioned integration that can be chained into broader access. That is why NHIMG’s Ultimate Guide to NHIs is useful here: it frames disclosure as part of identity hygiene, not just application security. Operationally, teams should track:

• Time to acknowledge, time to triage, and time to remediation.
• Percentage of valid reports accepted without back-and-forth clarification.
• Duplicate rate, false positive rate, and reporter re-engagement rate.
• Whether disclosed secrets are revoked, rotated, or invalidated before reuse.
• Whether fixes are verified in the affected environment, not just marked complete.

It also helps to treat high-confidence reports as a governed workflow, not an inbox task. When a report exposes a live NHI credential, response should include containment, revocation, impact analysis, and confirmation that dependent systems still function. These controls tend to break down when reports arrive through fragmented channels across product, security, and operations teams because ownership becomes ambiguous and no one is accountable for closure.

Common Variations and Edge Cases

Tighter intake and verification often increases operational overhead, requiring organisations to balance reporter friendliness against the cost of deep triage. Best practice is evolving here: there is no universal standard for how much evidence must be required up front, and the right answer depends on system criticality, reporter maturity, and the volume of submissions. The main tradeoff is speed versus certainty, especially when reports involve active exploitation risk.

Some programmes appear healthy because they produce many submissions, but high volume can mask weak signal handling. Others look quiet because they are inaccessible, intimidating, or too slow to reward good-faith reporting. In NHI-rich estates, the most important edge case is a disclosure that reaches beyond a single product bug and exposes a shared secret, a CI/CD token, or a third-party integration path. Those incidents should be measured as cross-system identity events, not ordinary defect tickets. For practitioners looking at disclosure from an identity-risk perspective, the patterns in the JetBrains GitHub plugin token exposure case and the Microsoft Entra ID Flaw analysis show how quickly a single disclosure can become enterprise-wide if secrets are not revoked and scoped correctly. A programme can look successful on paper while still failing if it does not force measurable containment after each valid report.

Related resources from NHI Mgmt Group

• How do you know if an access review programme is actually working?
• How do you know a passwordless programme is actually working?
• How do you know if a CIAM programme is working?
• How do you know if an airport biometric programme is actually working?