The Framework Selection Gap Enterprise Reviews Are Missing
GitHub Copilot, Amazon Q Developer, Gemini Code Assist, and Cursor each draw on partially undisclosed training corpora — repositories, documentation, StackOverflow, and in some cases web-crawled code; composition varies by vendor. For tools trained primarily on repository data — a category that includes GitHub Copilot, trained on GitHub's public code index — the corpus weight of established frameworks is structural, not incidental. When a developer prompts any of these tools to scaffold a content management system, implement an authentication flow, or handle file uploads, suggested patterns reflect the statistical weight of whatever frameworks dominate that particular training corpus. The risk this creates is specific, and it operates before standard security tooling engages. GitHub Dependabot, Snyk, OWASP Dependency-Check, npm audit, pip-audit, Trivy, and Renovate are designed to flag known CVEs at dependency installation and during CI/CD pipeline execution. These tools work — when they are in place and when developers review what they flag. But they operate after a framework has been selected. If an AI coding assistant normalizes a CVE-dense framework as the default scaffolding answer, the selection decision precedes the tooling designed to catch it. The residual risk scenario is specific: organizations without SCA integration in their CI/CD pipelines, developers who accept AI scaffolding outputs without reviewing the dependency manifest, or deployments built on version-pinned configurations that bypass incremental scanning.
The Deployed-Web Risk Surface
WebPulse scan data across 466K+ sites and 100+ TLDs characterizes what is deployed on the public web — a distinct dataset from AI training corpus composition, and not a proxy for it. These are not correlated: deployed-web distribution reflects years of accumulated decisions by millions of developers; what dominates GitHub training corpora reflects code committed to repositories, where Next.js, React, and Python frameworks are disproportionately represented relative to their deployed-web share. If anything, deployed-web data overstates WordPress's footprint relative to its GitHub presence, where it competes with far more repository-active frameworks. The scan data answers a different, equally important question: what is the CVE exposure surface among CMS-class frameworks already running in production? Detection carries methodological constraints that matter for any quantitative reading. Framework identification relies on HTML signatures and response headers; approximately 35% of scanned sites yield a detectable signature. WordPress carries the strongest HTML fingerprint and is over-represented among detected sites. Django, Spring Boot, and Rails are systematically undercounted because they frequently omit identifying headers. Enterprise and CDN-fronted deployments are largely invisible to signature-based detection. The figures below describe detected frameworks among CMS-identifiable sites, not the full web.
The zero-KEV figure requires architectural context. Several platforms in that group — Hugo, Astro, and Eleventy — are static site generators with no server-side execution surface by design. Their absence from the CISA KEV catalog reflects architectural difference as much as security posture: they cannot host the server-side vulnerabilities that KEV entries typically describe. AI coding tools do not generally suggest static generators in response to CMS scaffolding prompts, making the implied contrast a partial false choice. For organizations evaluating CMS-class frameworks with runtime execution, the relevant comparison is among dynamic platforms, where the CVE distribution across the WebPulse-tracked set is materially wider.
What the Research Establishes — and What Vendors Haven't Disclosed
The security implications of AI coding tool outputs have been studied extensively. Pearce et al.'s 'Asleep at the Keyboard?' (ACM CCS 2022), Perry et al.'s 'Do Users Write More Insecure Code with AI Assistants?' (2023), Sandoval et al.'s 'Lost at C' (2023), and publications from GitHub Security Lab, Snyk, and Veracode all address code-level vulnerability patterns in AI-generated snippets — buffer overflows, SQL injection, path traversal in generated code. The GitHub Copilot team has published on safety tuning specifically against CVE-pattern reproduction in generated snippets. These studies address code-generation quality — a distinct problem from framework selection bias, with different mitigations. Pearce et al. found that roughly 40% of AI-generated code snippets contained CWE top-25 vulnerabilities in adversarial security-sensitive testing scenarios, establishing a 2022 baseline before GPT-4-class models with improved RLHF tuning shipped. That is a code-quality finding; it does not measure which frameworks AI tools recommend when scaffolding projects. No published research as of mid-2026 directly quantifies framework suggestion frequency across AI coding tools or maps training corpus weight by framework across tool generations. The gap is not a research gap — it is a vendor transparency gap. What enterprise architecture reviews have not yet standardized is asking AI coding tool vendors directly: which frameworks does your tool suggest by default when scaffolding common project types, and what drives those defaults?
The Decision That Precedes AI Assistance
A structural risk hypothesis describes how current conditions could compound over successive training generations. If AI tools disproportionately surface established frameworks during scaffolding, and developers accept those suggestions without reviewing the dependency manifest, concentration of those frameworks in new deployments could grow. Growing deployment could expand the code corpus available for the next training cycle, potentially reinforcing the pattern. This is explicitly a hypothesis: no AI vendor has publicly disclosed that live-web crawl data feeds coding assistant training in this feedback-loop way, and the mechanism is unconfirmed as practice. It is a forward-looking risk scenario that warrants vendor transparency on training corpus composition and default framework weighting — not a claim about an established dynamic. What is documented is the starting condition: 76% of professional developers now work with AI coding tools whose training data composition is largely opaque to the organizations deploying them. Framework selection — made before AI assistance begins, and before any SCA scanner is engaged — determines which vulnerability surface a project starts with. For budget-signers, the architecture review cycle now has an upstream question to add: what does the AI coding tool your development team uses suggest by default when scaffolding a new project, and does that default align with your organization's security posture?
