Security teams drown in scanner findings, most of them irrelevant, while developers lack time to fix the real ones. AI helps in three places: triaging and prioritising findings by actual exploitability and business context, explaining each issue in the developer's own code, and drafting a patch or upgrade pull request that a human reviews. Typical benefit: shorter time to remediate and a backlog that shrinks instead of growing.
Problem & value
- Today: SAST, SCA, container, IaC and secret scanners each produce long lists with many false positives and duplicates. Prioritisation by CVSS alone ignores whether the code path is reachable or the asset is exposed. Fixes queue behind feature work; mean time to remediate stays in weeks or months.
- AI value: (1) triage - LLMs read the surrounding code and judge whether a finding is a true positive and reachable; (2) prioritise - combine CVSS, EPSS, CISA KEV, exposure and asset criticality; (3) fix - generate a minimal patch plus tests as a PR; (4) explain - remove the "what does this mean" barrier for non-security developers.
- Evidence: GitHub reports Copilot Autofix generating fix suggestions for CodeQL alerts directly in pull requests, and Google DeepMind describes CodeMender, an agent that upstreams validated patches to open-source projects [1][2]. Vendor-reported speed-ups vary by language and bug class; measure on your own repositories before trusting any figure.
- Regulatory pull: the EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to handle vulnerabilities and report actively exploited ones, with reporting duties starting in September 2026; NIS2 and DORA demand vulnerability handling for essential/important entities and financial firms [3][4].
Variants
- SMB: dependency and secret scanning built into the git platform (Dependabot-style update PRs, AI autofix) plus a managed external vulnerability scanner.
- Enterprise: exposure-management platform across code, cloud, endpoints and OT, with risk-based prioritisation, ticketing integration and SLA tracking.
- Software vendors / CRA manufacturers: SBOM + VEX generation, coordinated disclosure workflow, reporting of actively exploited vulnerabilities to the CSIRT/ENISA platform.
- Open-source maintainers: AI-assisted triage of reports; beware low-quality machine-generated reports flooding maintainers.
- Public sector: same stack, hosted in EU/sovereign environments.
- Private use: developers of hobby projects use free repository scanning; not a consumer product.
How it works
- sources (repo, PR, container registry, IaC, SBOM, cloud inventory)
- scanners (SAST, SCA, secrets, IaC, container, DAST)
- normalise & deduplicate findings (SARIF, CycloneDX/SPDX)
- enrich (CVE/NVD, EPSS, CISA KEV, vendor advisories, asset criticality, internet exposure)
- AI triage (reachability, true/false positive, explanation, confidence)
- risk-based priority + owner assignment
- AI fix agent (patch + unit test, dependency bump)
- CI build/test/re-scan
- human code review & merge (mandatory)
- ticket closure, VEX statement, audit evidence
- Triage: an LLM or agent receives the finding, the code slice, call graph and dependency info and returns verdict, rationale and confidence; low confidence goes to a human.
- Fix generation: code LLM proposes a diff; the pipeline validates it with compile, existing tests, new tests and a re-scan, so a fix that does not remove the finding is discarded.
- Human-in-the-loop: developers review and merge every AI patch; security approves exceptions and risk acceptances. Auto-merge only for narrow, low-risk classes (patch-level dependency bumps with green tests).
Data preparation
Vulnerability management needs three inputs: an inventory of assets and software (servers, endpoints, containers, dependencies), scan results, and code repositories with working tests. In an SMB the inventory is often an outdated Excel list, scans run irregularly, and code lives in a mix of Git hosts and file shares.
Typical gaps: unknown or shadow assets, no owner per system, no software bill of materials (SBOM), missing automated tests (so fixes cannot be verified), duplicate findings from several scanners, and no record of accepted risks.
Preparation steps: - Build or refresh the asset inventory and assign an owner and criticality to each system (see PREP-003, PREP-004). - Generate SBOMs and connect scanners to one findings store (see PREP-005). - Add or repair automated tests for the code areas where auto-fix is planned. - Record accepted risks and past fixes in a structured form (see PREP-020). - Define which code may be sent to external models (see PREP-024).
Rough effort: about 25 percent of the project, mostly inventory and test coverage. Without owners and tests, AI-proposed fixes pile up unreviewed. See GUIDE-003.
Implementation paths
Which path for whom
- SMB: A - built-in scanners and auto-fix in GitHub, GitLab or a managed vulnerability scanner are mature and need little setup.
- Enterprise: B - code and asset context are strategic and diverse; building prioritisation and fix agents on cloud APIs and the own CMDB and pipelines gives control and scales over many repositories.
- Developer: C - open-source scanners with a self-hosted code model keep source code in-house and are easy to adapt.
- Public: C - source code and infrastructure details are sensitive and procurement rules favour sovereign or on-premises operation.
Path A - Buy (recommended)
- Git-platform native: GitHub Advanced Security (CodeQL + Copilot Autofix, Dependabot, secret scanning), GitLab Ultimate (Duo vulnerability explanation and resolution).
- Application security platforms: Snyk (DeepCode AI, Snyk Agent Fix), Semgrep (Assistant), Checkmarx One, Veracode Fix, Endor Labs (reachability), Aikido Security (Belgium, EU - popular with SMBs), SonarQube (Sonar, Switzerland; AI CodeFix), Mend.io.
- Exposure/vulnerability management: Tenable, Qualys, Rapid7, Wiz, Microsoft Defender Vulnerability Management; EU-based options include Greenbone (Germany, open-source OpenVAS core), Detectify (Sweden), Outpost24 (Sweden), Intruder (UK).
- Choose A when: you have no dedicated AppSec team; check EU data residency, whether source code is sent to a third-party model, training-on-customer-data opt-outs and SARIF/ticketing integration.
Path B - Build on cloud APIs
- Keep existing scanners; add an orchestration layer (CI job or agent service) that calls a code-capable model (Claude, GPT, Gemini, Mistral Codestral/Devstral as EU provider) for triage and patch drafts. Use EU-region endpoints (Azure OpenAI EU, Vertex AI EU, AWS Bedrock Frankfurt/Paris, Mistral).
- Feed findings as SARIF; give the agent read-only repository access plus a sandboxed test runner; output a PR via the git platform API. Structured outputs for verdicts.
- Enrichment from open data: NVD API, CISA KEV catalogue, FIRST EPSS, OSV.dev, GitHub Advisory Database [5].
- Choose B when: you want custom prioritisation rules or need to integrate home-grown tools.
Path C - Self-host (open source)
- Scanners: Semgrep CE, CodeQL (free for open-source use only), Bandit, Trivy, Grype/Syft, OSV-Scanner, Gitleaks, Checkov, OWASP Dependency-Track, Greenbone/OpenVAS, Nuclei, Renovate for update PRs.
- Models: open-weight code models such as Qwen3-Coder, DeepSeek-Coder-V2/V3 family, gpt-oss, Mistral Devstral, served through vLLM or Ollama; agent loop via OpenHands or a custom runner.
- Hardware: HW3 for 30-120B coding models giving usable patch quality; HW2 works for triage and explanation with smaller quantised models.
- Choose C when: source code must not leave the premises (defence suppliers, critical infrastructure).
Path D - Custom training
Rarely worthwhile. Fine-tuning on your own closed-fix history can improve patch style for a specific framework or language, and a classifier for false-positive suppression needs a few thousand labelled findings. Start with prompting and retrieval over past fixes.
State of the art (2026)
- Agentic patching: systems such as Copilot Autofix, Google CodeMender and the DARPA AI Cyber Challenge finalist systems (open-sourced after the 2025 final) show that LLM agents can find and patch real vulnerabilities, validated by tests and re-scanning [2][6].
- Reachability analysis combined with LLM triage cuts noise considerably, but figures are vendor-reported and depend on codebase.
- Prioritisation beyond CVSS: EPSS and CISA KEV are standard inputs; exposure management (attack-path context) is the 2026 product direction.
- Limits and failure modes: patches may fix the symptom but break behaviour; models hallucinate APIs or non-existent package versions (slopsquatting risk, see SEC-016); fix quality is weaker for logic flaws, authorisation bugs and cross-service issues than for injection or memory-safety patterns; AI-generated code itself introduces vulnerabilities; prompt injection via code comments or issue text can steer an agent that holds repository write access.
Shared resources & combinations
- Same stack (llm-code + agent-framework): CODE-003 AI code review, CODE-005 legacy modernisation - one self-hosted coding-model server (HW3) can serve all three.
- Upstream/downstream: SEC-016 supply-chain and malicious package detection, SEC-012 threat modelling and design review (finds design flaws scanners cannot), SEC-007 authorised penetration testing (validates exploitability), SEC-001 SOC triage (runtime signal for prioritisation), SEC-009 compliance automation (evidence for NIS2/DORA/ISO 27001), SEC-017 secrets and sensitive data discovery.
- Shared data: asset inventory/CMDB, SBOM store, ticketing system.
Effort, cost & KPIs
- Path A: days to weeks; per-developer or per-repository licences. GitHub/GitLab-native features are often the cheapest start.
- Path B: 1-3 months for a CI-integrated triage and fix pipeline; model token cost is small compared with developer time, but sandboxed test infrastructure is a cost driver.
- Path C: 2-4 months; GPU server plus maintenance of scanners and rule sets.
- KPIs: mean time to remediate by severity, share of critical/KEV findings fixed within SLA, false- positive rate, share of AI patches accepted unchanged vs. edited vs. rejected, regression rate of merged AI fixes, backlog age, scanner coverage (% repositories and assets).
People & change
Involve IT-security and IT operations first, as they own findings and patch windows. Department leads and system owners decide risk acceptance and downtime. Developers are the daily users of auto-fix suggestions and must be part of tool selection; management sets the policy on which fixes may merge automatically (recommended: none without review).
Works council: no, as a rule, because the tools analyse code and systems, not people. Check anyway if developer activity metrics (commits, fix rates per person) are produced - then §87(1) no. 6 BetrVG applies. Inform the council early under §90(1) no. 3 where it exists. Data protection: usually little personal data; the DPO should still check commit metadata and the AVV with the vendor (see GUIDE-005).
AI literacy: train developers on reviewing AI patches critically, hallucinated dependencies and secure prompting; the AI Act asks employers to support staff AI literacy (see GUIDE-006). Pilot on one non-critical repository, measure fix acceptance and regressions, then widen. Typical concern: noise and deskilling - address with severity filters, mandatory human review and CI tests as the gate. Humans approve every merge and every production change (see GUIDE-009, GUIDE-013).
Risks, regulation & compliance
- EU AI Act: minimal risk - a defensive developer tool outside Annex III; AI literacy (Art. 4) applies. The tool is not a safety component. Using it in a product that is itself high-risk does not change the tool's classification.
- GDPR: source code may contain personal data (test data, logs, secrets); vendor DPA, EU region and no training on customer code. Developer activity metrics are employee data - agree with the works council (Germany: Betriebsrat) before per-developer dashboards.
- CRA / NIS2 / DORA: CRA requires vulnerability handling, SBOM and exploited-vulnerability reporting for products with digital elements; NIS2 Art. 21 lists vulnerability handling and disclosure as a risk-management measure; DORA covers ICT risk for financial entities [3][4].
- Security risks of the tool itself: agents with write access are a supply-chain target; least-privilege tokens, sandboxed execution, no auto-merge of non-trivial changes, logged diffs.
- Mitigations: mandatory human review, CI gates, re-scan after fix, provenance of AI patches in the commit message, periodic sampling of accepted patches.
Getting started
- Inventory repositories, container images and internet-facing assets; enable free native scanning (dependency, secret, SAST) on the git platform.
- Add EPSS and CISA KEV to the prioritisation and define SLAs per priority class.
- Pilot AI autofix on 3-5 repositories; track acceptance and regression rates for a month.
- Generate SBOMs (CycloneDX) in CI and store them in Dependency-Track for fast CVE lookup.
- Restrict agent tokens, require review on every AI PR, and document the process for NIS2/CRA audits.
Sources
- GitHub Docs - Responsible use of Copilot Autofix for code scanning - https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/responsible-use-autofix-code-scanning
- Google DeepMind - Introducing CodeMender, an AI agent for code security - https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/
- Regulation (EU) 2024/2847 (Cyber Resilience Act) - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- Directive (EU) 2022/2555 (NIS2) - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- CISA Known Exploited Vulnerabilities Catalog - https://www.cisa.gov/known-exploited-vulnerabilities-catalog ; FIRST EPSS - https://www.first.org/epss/
- DARPA AI Cyber Challenge - https://aicyberchallenge.com/
- OSV.dev open-source vulnerability database - https://osv.dev/
- Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj