As reported by Dark Reading, analysis of Project Glasswing findings reveals a stark asymmetry between discovered vulnerabilities, disclosed flaws, and actual remediation — and the gap is widening. This is not a surprise to anyone running a security program at scale, but it deserves more than a knowing nod. It demands a frank conversation about why our entire vulnerability management posture is buckling under its own weight.
The Disclosure Pipeline Is Saturated
The core issue isn't that we're finding too many vulnerabilities — it's that the downstream processes for validating, prioritizing, disclosing, and patching them were designed for a volume era that no longer exists. Automated fuzzing, continuous code scanning, bug bounty programs, and AI-assisted discovery tools have dramatically expanded the top of the funnel. But the bottom of the funnel — human engineers making risk judgments, writing patches, testing changes, and coordinating disclosure timelines — has not scaled at all.
The vulnerability management problem has quietly become a workforce and workflow problem. No scanner, prioritization engine, or risk-score algorithm can patch code. People patch code.
What Project Glasswing Exposes
Project Glasswing's findings — only a fraction of identified vulnerabilities reaching formal disclosure, and an even smaller share actually fixed — illustrate what happens when discovery outpaces remediation by orders of magnitude. The traditional 90-day disclosure window, CVSS-based prioritization, and patch SLA frameworks were all built on assumptions of manageable inflow. When inflow is effectively unbounded, those frameworks don't fail gracefully. They create a false sense of process control while the backlog grows invisibly.
Who Bears the Real Cost
The human bottleneck does not distribute evenly. Several patterns are becoming clear:
Meanwhile, researchers face their own bottleneck: when disclosure channels are slow or unresponsive, the incentive to report responsibly diminishes. That creates a feedback loop where more vulnerabilities either go unreported or surface through less controlled means.
The Prioritization Fallacy
Many organizations respond to vulnerability volume by investing in better prioritization tooling — threat intelligence feeds, EPSS scores, context-aware scanning. These are valuable, but they address the symptom, not the disease. Prioritization helps you decide which 200 of 2,000 vulnerabilities to fix this month. It does not change the fact that 1,800 remain, and many of those will still be exploitable. The industry has optimized for decision speed while ignoring execution capacity.
The uncomfortable truth is that meaningful remediation requires engineering hours — and those hours are finite, expensive, and already over-allocated across feature work, technical debt, and operational incidents. Security teams that want to close the gap need to compete for engineering capacity that has other priorities, and that requires organizational leverage most CISOs do not fully wield.
What You Should Do: Shield53 Recommendations
- Shift from triage to capacity planning. Treat vulnerability remediation as a capacity allocation problem. Track fix velocity (vulnerabilities closed per engineering sprint) as a leading metric, not just backlog size as a lagging one. If velocity is flat and backlog grows, you have a staffing problem, not a tooling problem.
- Implement exploitability-weighted SLAs. Replace static CVSS-based SLAs with dynamic prioritization that incorporates EPSS scores, threat intelligence context, and asset criticality. A CVSS 6.3 on an internet-exposed production database may deserve faster remediation than a CVSS 9.8 on an isolated test environment.
- Formalize a vulnerability exception process. Not every vulnerability will be fixed. Accept that explicitly. Establish a risk acceptance framework with documented owners, review cadences, and compensating control requirements. Unacknowledged risk is worse than accepted risk.
- Negotiate remediation capacity at the leadership level. CISOs should work with engineering leadership and product owners to establish dedicated remediation sprints or a standing percentage of engineering capacity allocated to security debt. This is a governance conversation, not a tactical one.
- Push upstream on dependency hygiene. Reduce future inflow by enforcing SBOM requirements in procurement, evaluating upstream project security posture before adoption, and reducing unnecessary dependency sprawl. Fewer dependencies mean fewer future vulnerabilities entering your environment.
- Support the ecosystem you depend on. Organizations relying on open-source projects should contribute funding, engineering support, or vulnerability remediation assistance to maintainers of critical dependencies. The bottleneck in the open-source supply chain is ultimately your bottleneck too.
The Project Glasswing data is a mirror, not an anomaly. It reflects a structural mismatch between discovery capability and remediation capacity that every security program is already living with — some more visibly than others. The organizations that acknowledge this as a resource problem rather than a tooling problem will be the ones that build sustainable defenses. Those that keep buying prioritization engines while their engineers drown in queue will find that the backlog was never really about the vulnerabilities at all. It was about the people.
