Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: Ghost CVEs are publicly disclosed vulnerabilities that can surface in commits and advisories hours or days before NVD records them, leaving teams exposed if they depend on a single lagging source, according to Intruder. Container registry risk and delayed vulnerability visibility both point to the same operational problem: security programmes need faster intake, prioritisation, and remediation loops than traditional record-based processes provide.
NHIMG editorial — based on content published by Intruder: issue #4 of The Vulnerabulletin, covering Ghost CVEs, container registry security, and security habits
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when teams rely on NVD as their only vulnerability signal?
A: They inherit a visibility delay that can leave exploitable issues untriaged for hours or days.
Q: Why do container registries matter to security governance?
A: Container registries control which artefacts move into build and production environments, so they sit on the path from code to runtime.
Q: How do security teams know whether their vulnerability response is fast enough?
A: Measure the time between first external signal and defensive action, not just the time from ticket creation to patching.
Practitioner guidance
- Broaden vulnerability intake beyond NVD Wire GitHub commits, vendor advisories, and threat feeds into triage so teams can act before a record appears in the database.
- Treat container registries as governed trust points Restrict who can push, pull, and promote images, and require provenance checks before deployment.
- Create a fast lane for high-confidence exposures Define an escalation path for disclosures that appear in commits or advisories before database publication.
What's in the full article
Intruder's full issue covers the operational detail this post intentionally leaves for the source:
- A practical breakdown of how the team tracks vulnerabilities before they reach NVD, including the sources and timing considerations used in triage.
- A three-tier container registry security strategy with implementation detail for teams securing build-to-runtime artefact flow.
- The full conversation on making security a daily habit, including the operational behaviours the CTO recommends for engineering teams.
- Additional product and industry updates, including the upcoming automated container image vulnerability scanning release.
👉 Read Intruder's issue on Ghost CVEs, container registry security, and daily security habits →
Ghost CVEs and container registry risk: are your controls keeping up?
Explore further
19/08/2026 4:17 pm
Ghost CVE lag is a governance failure, not just a data-source problem. The issue is not that NVD is wrong, but that it is too slow to serve as the sole operational trigger for risk response. Modern vulnerability governance needs parallel intake from advisories, repositories, and exploit telemetry. Practitioners should therefore measure time-to-awareness, not just time-to-patch.
A question worth separating out:
Q: Who is accountable when exposure remains open after a vulnerability is disclosed?
A: Accountability should sit with the asset or service owner, but only if ownership records are current and tied to privileged access paths. In practice, that means IAM, infrastructure and security teams need a shared operating model for assigning remediation, approving exceptions and proving closure. Otherwise, gaps linger because no one can act decisively.
👉 Read our full editorial: Ghost CVEs show why NVD lag leaves security teams exposed
