A large-scale analysis of AI-generated code in public GitHub repositories, published in late 2025, found that AI coding assistants introduce security vulnerabilities at rates that consistently exceed human-written equivalents across injection, authentication, and data handling categories. A peer-reviewed study accepted at IEEE-ISTAS 2025 found that critical vulnerabilities increase by 37.6% across just five iterative AI refinement cycles without human intervention at each step. Engineering teams shipping AI-assisted code at scale are not facing a simple quality gap — they are facing a systematic risk classification problem that scanner-only approaches cannot solve.
What FMEA Is and Why Code Review Needs It
Failure Mode and Effects Analysis (FMEA) is a structured methodology for identifying how a system, product, or process can fail, estimating the consequences of each failure mode, and prioritizing corrective action by calculated risk. Originally codified for aerospace and defense applications and embedded in standards from automotive to medical devices, FMEA has a direct software analog: Software FMEA applies the same three-dimensional scoring model to potential defects in code, interfaces, and system interactions.
The core calculation is the Risk Priority Number (RPN):
RPN = Severity (S) × Occurrence (O) × Detectability (D)
Each dimension is scored on a 1-to-10 scale. Severity measures the impact if the failure reaches production. Occurrence scores how frequently the failure mode appears in the given class of code change. Detectability is inverse: a score of 10 means existing tools are nearly certain to miss the defect; a score of 1 means detection is virtually guaranteed. RPNs above 200 conventionally trigger mandatory remediation action before a component ships. The same threshold logic applies directly at the PR gate.
The AI Code Risk Profile Makes Traditional Review Insufficient
A November 2024 issue brief from Georgetown University's Center for Security and Emerging Technology identified the structural mechanism behind AI code quality risk: AI models trained on public code repositories systematically replicate known vulnerability patterns because vulnerable code is prevalent in training data. The result is not random defects distributed across a codebase — it is predictable failure mode clusters that recur across teams, projects, and languages.
A formal verification study titled "Broken by Default," published in April 2025, applied proof-based methods to AI coding assistant outputs in security-sensitive domains. The study found that AI assistants produce exploitable code even when the security requirement is explicit in the prompt — demonstrating that instruction-following and secure code generation are not equivalent properties. An academic evaluation of AI model security awareness against the Common Weakness Enumeration (CWE) framework, published by the West Virginia Academy of Science, found consistent gaps between model comprehension of security concepts and the ability to generate secure implementations in practice.
The iterative refinement risk adds a compounding dimension. The 37.6% increase in critical vulnerabilities observed after five AI refinement cycles stems from models optimizing for the most recently stated instruction while degrading boundary-condition handling established in earlier iterations. Multi-turn AI coding workflows without a fixed human checkpoint accumulate security debt iteration by iteration.
Mapping FMEA Dimensions to AI Pull Requests
Translating FMEA to code review requires grounding each dimension in signals available at PR submission time.
Severity (S) scores the blast radius if the failure reaches production. The scoring hierarchy mirrors established security impact frameworks:
Score 9–10: Authentication bypass, remote code execution, privilege escalation, data exfiltration paths
Score 7–8: Injection vulnerabilities, broken access control, sensitive data exposure in transit
Score 5–6: Business logic errors, improper error handling, data integrity failures in non-critical paths
Score 3–4: Performance degradation, functional defects with limited user impact
Score 1–2: Style and documentation issues, cosmetic changes
Severity scores should be anchored to the service context of changed files. A PR touching authentication middleware scores materially differently from one updating a display string in a static component.
Occurrence (O) measures how frequently a given failure mode appears in AI-generated code of the type being reviewed. Published academic analysis of AI code in public repositories provides empirical starting priors across injection, authentication, and data handling categories. Teams should calibrate occurrence scores against their own PR outcome history as data accumulates; published academic benchmarks provide a defensible starting point before that history exists.
Detectability (D) is inverse: how likely is the existing pipeline to miss the defect? Static analysis tools achieve high detectability — low D score — for known vulnerability signatures. The challenge is AI-generated code that is syntactically valid and passes linters while embedding security failures in semantic logic: a function that handles expected inputs correctly but silently drops exceptions on boundary inputs, or a cryptographic implementation using a deprecated parameter combination that appears standard at a glance. These failure modes score high on D because no automated scanner flags them, elevating the overall RPN regardless of occurrence rate.
Common AI PR Failure Modes and Illustrative RPN Ranges
Based on published security research and academic telemetry, five failure mode categories appear consistently in AI pull request analysis.
Injection failures — SQL injection, command injection, cross-site scripting — show elevated occurrence in AI-generated code relative to human-written equivalents across published academic studies. Severity is high across this category. Detectability by established scanners is moderate for known patterns but low for novel or obfuscated variants. Typical RPN range: 300–600.
Authentication and authorization flaws carry high severity and moderate occurrence. Detectability is low when authorization logic is distributed across multiple files or involves implicit state that spans the call graph. Typical RPN range: 250–500.
Data handling violations — insecure deserialization, improper input validation, weak cryptographic parameter selection — show moderate-to-high severity and elevated occurrence documented in formal verification literature. Typical RPN range: 200–450.
Logic correctness errors have variable severity depending on business context. Occurrence is difficult to score without domain knowledge. Detectability by automated tools is low — this is the failure mode class most likely to be entirely invisible to a scanner-only review process, regardless of how comprehensive the scanner coverage appears.
Supply chain and dependency risks are a growing category as AI-assisted tooling increasingly suggests dependency additions and version changes. A 2025 arXiv study models supply chain vulnerabilities as cascading multi-vulnerability chains, where a single AI-suggested dependency introduces a connected attack surface that is difficult to assess at PR time without a structured framework.
Building the FMEA-Based PR Gate
A practical FMEA-based PR gate operates in four steps.
Step 1 — Classify the PR. Label each PR as AI-assisted or human-written. The label determines which baseline occurrence table is applied to the change. Labeling can be automated by detecting AI tool commit metadata, or enforced through policy declaration in PR templates.
Step 2 — Score severity and occurrence automatically. Map changed files to their service tier and apply severity scores from a pre-built table maintained by the security team. Apply occurrence rates sourced from published academic benchmarks, adjusted by team-specific calibration data as PR outcome history accumulates.
Step 3 — Score detectability from pipeline coverage. For each failure mode category applicable to the change surface, assess whether the existing automated pipeline has active coverage. Document coverage gaps as elevated D scores. This step makes invisible risk visible without requiring manual security review of every PR.
Step 4 — Compute RPN and route. PRs with RPN above a defined threshold — 200 is the conventional starting point in FMEA practice, with 400+ treated as critical — route to mandatory human security review before merge. PRs below threshold proceed through standard review. Thresholds should be recalibrated as outcome data accumulates.
A 2026 study in Springer Nature describes a framework for automating FMEA using large language models and retrieval-augmented generation, maintaining the analytical structure of FMEA while reducing the manual burden of per-change assessment. As AI-generated code volume scales, the hybrid model — automated scoring, human review for high-RPN submissions — becomes the only operationally sustainable approach.
The Governance Layer
PR-level FMEA scoring is a tactical tool. The governance layer answers the strategic questions: who owns the scoring tables, how frequently are they recalibrated against observed outcomes, and what remediation is required when a failure mode reaches production despite clearing the gate?
The iterative refinement risk identified in published research points to a specific governance rule: any workflow in which AI models iterate on their own output requires an explicit human checkpoint before the result can merge, regardless of RPN score. The model's self-assessment of its own output is not a detectability signal — it is part of the occurrence risk. Treating AI self-review as a gate is equivalent to asking the component to certify its own reliability.
Research on AI and ontology-enhanced FMEA for complex systems demonstrates that the analytical structure of FMEA scales when paired with systematic knowledge organization — a principle directly applicable to building a durable, recalibrable PR governance framework rather than a one-time scoring table that drifts as AI model behavior evolves.
Engineering teams that formalize this structure report a practical benefit beyond security: the RPN score creates a shared vocabulary between security and engineering. The conversation shifts from "this PR is blocked" to "this change has a calculated risk score of 380 — here is why, and here is what would bring it below threshold." That conversation is repeatable, auditable, and improvable over time. An ad hoc review policy is not.
For a worked RPN scoring table — five common AI PR failure modes with severity, occurrence, and detection values assigned from 2026 vendor telemetry — see FMEA for AI Pull Requests: How to Score Risk Before It Ships, which applies this same framework to hardcoded secrets, OWASP Top 10 vulnerabilities, and unauthorized agent scope expansion.
Re-entry.ai automates the classification, scoring, and routing layer of this process — identifying AI-assisted PRs at submission, applying configurable RPN scoring tables to each change surface, and surfacing high-risk submissions to the appropriate review tier before they merge. If your team is shipping AI-generated code at scale, request a demo at re-entry.ai to see how the FMEA-based gate works in practice.