Your vendor security questionnaires ask about patch cycles and incident response plans. But you're missing the foundational question: Does this vendor build software that creates the same vulnerabilities we've been fighting since 2007?
These myths persist because they let procurement teams check boxes without confronting an uncomfortable truth: most vendor assessments measure reactive security theater, not whether the vendor writes exploitable code in the first place.
Myth 1: Patch Speed Is the Primary Vendor Security Metric
Reality: If your vendor needs constant patches for injection flaws and input validation bugs, their development culture is broken.
CISA's 2024-2025 vulnerability analysis found that seven of the 10 most frequent weaknesses in the Known Exploited Vulnerability catalog were classified as "stubborn weaknesses" in MITRE's 2023 report. More damning: three of the top five KEVs stemmed from flaws MITRE deemed "unforgivable" in 2007.
These aren't zero-days requiring sophisticated research. Improper input validation (CWE-20), the single most-common weakness across the KEV catalog, exists because developers didn't implement basic controls. Path traversal (CWE-22) and OS command injections (CWE-78) round out the top exploited flaws, all preventable with established practices.
Your SIG Core questionnaire should ask: "What percentage of your CVEs in the past 24 months were injection-related or input validation failures?" A vendor releasing quarterly patches for SQL injection isn't demonstrating strong patch management. They're demonstrating they don't know how to write secure code.
Myth 2: Security Is Too Complex for Vendors to Build In From the Start
Reality: The most exploited vulnerabilities have obvious attack paths that attackers locate in minutes.
CISA's definition of "unforgivable" vulnerabilities includes four criteria: they result from common, well-documented mistakes; they have an obvious attack path; the exploit is simple; and attackers can find them in minutes. Cross-site scripting (CWE-79), OS command injections (CWE-78), and SQL injections (CWE-89) all meet these criteria.
These aren't sophisticated supply chain compromises requiring nation-state capabilities. They're the software equivalent of leaving the back door unlocked because no one made door-locking part of the construction process.
When vendors claim Secure by Design practices are too resource-intensive, they're asking you to accept that basic input sanitization and memory safety are beyond their engineering capacity. That's not a technical constraint; it's an organizational choice to externalize security costs onto your team.
Myth 3: Our Vendor Assessment Catches Development Practice Gaps
Reality: Standard questionnaires don't reveal whether vendors eliminate vulnerability classes or just patch individual instances.
Your due diligence likely asks about SDL frameworks and security training. But do you ask for the vendor's CWE distribution over time? If they're patching CWE-79 (XSS) vulnerabilities every quarter, they haven't fixed the root cause; they're playing whack-a-mole with symptoms.
Request the vendor's CVE history filtered by weakness type. Look for patterns:
- Are injection-related CVEs clustered in legacy products but absent from recent releases? (Suggests improved practices.)
- Do the same CWE categories appear across product lines and versions? (Suggests systemic gaps.)
- Has the vendor published guidance on eliminating specific weakness classes from their codebase?
CISA's Risk and Vulnerability Assessments found that memory safety and improper input validation vulnerabilities accounted for 16.7 percent of KEV entries in 2025. If your vendor's recent CVEs fall into these categories, their security posture is indistinguishable from the industry's worst performers.
Myth 4: SBOMs Are Primarily a Compliance Artifact
Reality: SBOMs are your only scalable tool for tracking whether vendors use components with stubborn weaknesses.
You can't assess Fourth and Nth Party Management if you don't know what's in the software. When your vendor incorporates a library with known input validation failures, that's your risk surface, not just theirs.
An SBOM requirement in your contract should include:
- Machine-readable format (SPDX or CycloneDX)
- Component-level vulnerability mapping to CWE categories
- Update frequency tied to component changes, not just major releases
- Sub-processor disclosure for any third-party components handling your data
Then cross-reference SBOM components against the KEV catalog filtered by weakness type. If a vendor's dependencies include libraries with active KEVs for CWE-20, CWE-22, or CWE-78, you're inheriting decades-old risk.
Myth 5: This Is a Technical Problem, Not a Procurement Lever
Reality: Vendor selection is the most effective intervention point, and you have the contractual authority to demand better.
CISA's analysis explicitly states: "The problem is not technical complexity: it is organizational culture, developer workflows, and systemic gaps in Secure by Design adoption."
Your procurement requirements should include:
- Demonstrated elimination of at least two stubborn weakness categories from the vendor's CWE distribution year-over-year
- Contractual commitment that no CVEs for unforgivable vulnerabilities (as defined by MITRE 2007 criteria) will be issued for net-new code
- Right to audit development practices, including code review processes for input validation and memory safety
- Termination rights triggered by repeated CVEs in the same weakness category
When vendors claim these requirements are unprecedented, remind them that three of today's top 10 CWEs were considered unforgivable 19 years ago. The precedent is two decades of vendors externalizing security costs.
What to Do Instead
Build vendor Criticality Classification criteria that weight development practices as heavily as incident response capabilities:
Tier 1 (Critical): Require annual attestation that no stubborn weakness categories appear in CVEs for products you consume. Mandate SBOM updates within 48 hours of component changes. Include audit rights for development pipeline security controls.
Tier 2 (Important): Require disclosure of CWE distribution trends and remediation timelines for any KEV-listed vulnerabilities in their software or dependencies.
All tiers: Make Secure by Design practices a scored evaluation criterion, not a pass/fail checklist item. Award points for:
- Published elimination roadmaps for specific CWE categories
- Use of memory-safe languages for new development
- Automated input validation in CI/CD pipelines
- Third-party attestation of secure development practices (not just penetration test reports)
CISA's recommendation is unambiguous: software buyers should only choose vendors that meet Secure by Design requirements. That's not regulatory guidance; it's risk management. When seven of 10 exploited flaws have been on the "fix this" list since 2007, vendor selection is your most powerful control.
The patches will keep coming until procurement teams stop rewarding vendors who build the same exploitable code, quarter after quarter, year after year.
