The Challenge of Open Source Security
IBM and Red Hat have launched Project Lightwell, a $5 billion initiative involving 20,000 engineers to create a "security clearinghouse" for open source software. This project aims to enhance vulnerability discovery and remediation using AI, focusing on integrating patches into enterprise software supply chains. IBM revealed it uses more than 62,000 open source packages internally, facing the same challenge as every enterprise: nearly 50,000 CVEs were published in 2025 alone.
This initiative is not a response to a specific incident but an acknowledgment of the systemic failure in managing vulnerabilities at scale. The investment reflects the need for a new approach to vulnerability management.
The Growing Technical Debt
The timeline of this issue spans years of accumulated technical debt:
- Ongoing: Enterprises consume open source packages at scale (IBM's 62,000 is typical, not exceptional).
- 2025: Nearly 50,000 CVEs published, overwhelming security teams.
- Present: IBM and Red Hat commit $5 billion and 20,000 engineers to Project Lightwell.
- Future: AI-assisted vulnerability discovery and patch integration into enterprise supply chains.
The gap between vulnerability disclosure and remediation has widened, and simply adding more security engineers is no longer effective. This investment acknowledges that reality.
Identifying the Gaps in Controls
The issue isn't failed controls but controls that never scaled. Consider these challenges:
Vulnerability Identification: Your team runs dependency scanners that flag CVEs, but they don't indicate if the vulnerable function is reachable in your build. Alerts for transitive dependencies may never execute in your environment.
Patch Prioritization: Your scanner reports a critical CVE in a logging library. Is it exploitable in your configuration? Does the patch introduce breaking changes? You need human analysis, but you have 200 similar alerts this week.
Supply Chain Visibility: You know your application's declared dependencies but not what those packages pull in or what build tools inject at compile time.
Remediation Velocity: Even when you identify a real vulnerability and a stable patch exists, testing and deploying it takes weeks. Multiply that by thousands of packages.
The missing control is economic. The open source ecosystem relies on volunteer maintainers and corporate contributions, but vulnerability management requires sustained engineering effort that most organizations can't or won't fund.
Standards and Their Requirements
Let's map this to actual requirements your auditors will check:
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
You need an SBOM (Software Bill of Materials). But an SBOM alone doesn't tell you which vulnerabilities matter or how to prioritize remediation.
NIST 800-53 Rev 5, SI-2 (Flaw Remediation): Organizations must install security-relevant software updates within the time period specified in policy. The control enhancement SI-2(2) requires automated patch management tools.
Automation can deploy patches, but it can't decide which patches are safe to deploy or which vulnerabilities are exploitable in your context. That requires analysis — exactly what Project Lightwell aims to scale with AI.
ISO 27001, Annex A.8.8: Technical vulnerabilities must be identified and appropriate measures taken. The standard assumes you have a process, not that the process is physically possible.
OWASP Top 10 2021, A06:2021 – Vulnerable and Outdated Components: The risk is well-documented. The guidance is to "continuously inventory the versions of both client-side and server-side components and their dependencies" and "only obtain components from official sources over secure links."
The what is clear, the how at scale is not.
Actionable Steps for Your Team
Project Lightwell doesn't solve your immediate vulnerability backlog, but it shows what enterprises are willing to invest to fix the problem. Here's what you can do now:
1. Implement Dependency Tracking with Reachability Analysis
Don't just scan for CVEs — determine which vulnerable code paths your application actually executes. Tools like GitHub's dependency graph with Dependabot, Snyk, or OWASP Dependency-Track can help, but you'll need to configure them to reduce false positives. Document your reachability criteria for auditors.
2. Establish a Patch Review Process
Create a triage matrix:
- Critical CVE + reachable code path + exploit available = immediate patch
- Critical CVE + unreachable code path = monitor, patch in next sprint
- Low/Medium CVE + no known exploit = quarterly review
Document your criteria to satisfy SI-2 policy requirements.
3. Build SBOM Generation into Your CI/CD Pipeline
Use tools like Syft, CycloneDX, or SPDX generators to create SBOMs automatically on every build. This satisfies PCI DSS Requirement 6.3.2 and provides a foundation for vulnerability tracking. Store SBOMs in a searchable repository to quickly answer "which applications use package X?" when a new CVE drops.
4. Track Your Mean Time to Remediation
Measure how long it takes from CVE publication to deployed patch for critical, high, and medium vulnerabilities. If your MTTR for critical CVEs is over 30 days, you have a process problem, not a tooling problem. Use this metric to justify headcount or process changes.
5. Participate in Open Source Security Funding
If your organization depends on open source, budget for OpenSSF, Tidelift, or direct maintainer support. This isn't altruism — it's supply chain risk management. A maintained package with active security response is cheaper than forking and patching internally.
Project Lightwell highlights that vulnerability management at enterprise scale requires dedicated engineering investment, not just better tools. Your team won't get 20,000 engineers, but you can adopt the same principle: vulnerability management is ongoing engineering work, not a compliance checkbox.
The standards tell you what to track. The economics tell you that you can't track everything manually. Build automation that reduces noise, document your triage process, and measure your remediation velocity. That's how you'll explain to auditors — and your CISO — why you're still shipping software despite 50,000 CVEs per year.
