You're about to renew a critical software contract. The vendor promises faster patch cycles, better support, and more frequent updates. But none of that addresses the real question: are they still shipping the same categories of flaws they sold you three years ago?
CISA recently highlighted a significant issue: 41.5% of exploited vulnerabilities in their Known Exploited Vulnerabilities catalog map to weaknesses that have appeared on MITRE's CWE Top 25 nearly every year since 2019. The problem isn't that vendors can't patch fast enough. It's that they keep building the same structural defects into new code.
For procurement leaders, this creates a decision point. Do you continue accepting reactive patch commitments, or do you start requiring vendors to eliminate entire classes of vulnerabilities as a condition of doing business?
The Decision You're Facing
When evaluating software vendors, you need to determine whether to:
Accept traditional vulnerability management: Vendor identifies and patches individual CVEs as they're discovered.
Require vulnerability class elimination: Vendor demonstrates they've removed entire categories of weaknesses from their development process and provides a roadmap for remaining classes.
This isn't just a technical preference. It's a risk transfer decision with direct implications for your incident response costs, compliance posture, and board reporting.
Key Factors That Affect Your Choice
Criticality of the system. If the software handles authentication, processes untrusted input, or sits in your attack path, you're exposed to the weakness classes CISA identifies: memory safety failures, injection flaws, improper input validation, path traversal, and broken access control. A breach here doesn't just create an incident; it creates a disclosure obligation.
Your patching capacity. Be honest about your mean time to remediate. If you're still patching critical CVEs 45 days out, you don't have the operational margin to absorb another three years of the same vulnerability classes. You need vendors who stop creating the problem.
Vendor market position. A dominant platform vendor with 80% market share has less incentive to rewrite their codebase than a challenger trying to win enterprise deals. Your leverage varies accordingly.
Contractual renewal timing. You have maximum negotiating power at contract inception and renewal. Mid-contract requests for vulnerability class elimination roadmaps rarely succeed without consideration.
Regulatory trajectory. If you're subject to NIS2 Directive, Digital Operational Resilience Act, or SEC Cybersecurity Disclosure requirements, your obligation to demonstrate due care in vendor selection is growing. "They promised to patch faster" won't satisfy a regulator asking why you accepted a vendor still shipping memory-safety flaws.
Path A: Require Vulnerability Class Elimination
Choose this path when:
- The software is mission-critical or processes regulated data
- You're entering a new contract or renewal negotiation
- The vendor has credible competition you can switch to
- You have executive support to walk away from vendors who won't commit
- The vendor has publicly pledged Secure by Design principles
What to demand in the contract:
A written commitment identifying which CWE Top 25 classes the vendor has eliminated from their development process. Don't accept vague promises. Ask which specific weaknesses (memory safety, SQL injection, path traversal) they've addressed and how (migrated to memory-safe language, implemented parameterized queries, adopted input validation frameworks).
A roadmap with dates for eliminating remaining classes. If they can't eliminate a class immediately, you need visibility into when they will. "We're working on it" is not a roadmap.
A machine-readable Software Bill of Materials (SBOM) delivered with each release. You can't verify their claims without transparency into components and dependencies.
Security capabilities included in the base license, not sold as add-ons. CISA's Secure by Demand guidance specifically calls this out: security logs, phishing-resistant authentication, and automatic updates should not be premium features.
The economic reality:
Vendors will resist. Eliminating memory-safety flaws often requires rewriting C/C++ codebases in Rust or another memory-safe language. That's expensive and time-consuming. Your job is to make it more expensive to lose your business than to fix their development process.
If enough procurement teams make the same demand, the market shifts. Vendors who move first gain competitive advantage. Vendors who wait lose deals.
Path B: Accept Traditional Vulnerability Management
Choose this path when:
- The software is low-risk or isolated from critical systems
- You have no viable alternative vendor
- The vendor is a monopoly platform where switching costs exceed risk costs
- You lack executive support to enforce security requirements in procurement
- Your organization's patching process is mature enough to handle ongoing CVE remediation
What to demand instead:
Even if you can't require class elimination, don't accept a status-quo contract. Negotiate for:
Guaranteed patch delivery timelines tied to CISA KEV listings. If a vulnerability appears in the KEV catalog, you need a patch within a defined window (7 days for critical, 14 days for high).
Contractual liability for unpatched KEV vulnerabilities that result in a breach. If the vendor ships a flaw CISA has flagged as exploited and you're compromised before they patch it, that's a vendor failure, not a customer failure.
Regular third-party security assessments with results shared under NDA. You're entitled to verify their claims.
The trade-off you're accepting:
You will continue to patch the same types of flaws indefinitely. Your security team will spend cycles on remediation that could have been spent on threat hunting or control improvement. Your Total Cost of Risk includes not just the license fee but the operational cost of managing their technical debt.
Make sure your executives understand that trade-off before you sign.
Path C: Phased Transition with Vendor Partnership
Choose this path when:
- You have a long-term relationship with a vendor who's willing to improve but can't eliminate all classes immediately
- The vendor has begun adopting Secure by Design practices but needs time to complete the transition
- You're willing to provide detailed feedback to help them prioritize which classes to address first
What this looks like:
Year one: Vendor commits to eliminating one or two high-impact classes (typically memory safety or injection flaws) and provides quarterly progress reports.
Year two: Vendor expands to additional classes based on your threat model and their exploitation data.
Year three: Full elimination of CWE Top 25 classes or a documented technical justification for any that remain.
This path requires trust and transparency on both sides. It works best with vendors who have already made public Secure by Design pledges and need customer pressure to prioritize the work internally.
Summary Matrix
| Factor | Require Elimination | Accept Patching | Phased Partnership |
|---|---|---|---|
| System criticality | High | Low | Medium to High |
| Vendor competition | Multiple options | Monopoly/near-monopoly | Limited but present |
| Your leverage | New contract or renewal | Mid-contract | Long-term relationship |
| Vendor maturity | Has Secure by Design program | Traditional SDLC | Improving but incomplete |
| Your patching capacity | Limited | Strong | Moderate |
| Risk tolerance | Low | Higher | Medium |
| Contract term | Include elimination roadmap, SBOM, base security features | Demand KEV patch SLAs, liability clauses | Phased commitments with quarterly milestones |
The question isn't whether vulnerability class elimination is technically possible. MITRE documented "unforgivable vulnerabilities" in 2007, and three of today's ten most common weaknesses would have qualified. The question is whether you'll use your procurement authority to make it commercially necessary.
CISA has given you the framework. The leverage is in your contract negotiations. Use it.
