AI Code Security · AI SAST · Exploit validation

Code security in the age of AI

Rule-based scanners still reliably find what they were built for: syntax flaws. What hurts today — broken authorization, business logic, wrongly assumed permissions — has no signature. We bring rules, AI reasoning and exploit validation into an order your team can actually operate.

Book an intro call See our services

Assessment in two weeks, defensible results in 90 days
Tool-neutral: we assess your stack, we don't sell one
Evidence that holds up in CRA, NIS2 and customer audits

Four numbers that describe the situation

All from publicly available primary and operator sources. Together they explain why volume and speed became a problem at the same time.

45%

of AI-generated code fails the security test

Tested across more than 100 models and 80 coding tasks. For Java the failure rate reaches 72 percent.

Veracode GenAI Code Security Report

A01

Broken Access Control remains number one in the OWASP Top 10

The 2025 edition explicitly covers BOLA and BFLA — precisely the flaws no pattern can express.

OWASP Top 10:2025

23%

of known exploited flaws are attacked on publication day

Share of KEV entries with exploitation on or before the CVE publication date, first half of 2026.

CISA KEV catalog

15–20%

of incoming CVEs still receive full enrichment

The NVD has been operating in triage mode since April 2026. Waiting for complete databases is no longer a strategy.

NIST on the NVD transition

A scanner reads syntax. An attacker reads intent.

The difference is not a tooling problem, it is a class problem. Both examples come from the same application.

pythonDETECTED

1# Findet jede Regel-Engine seit 20052query = "SELECT * FROM users WHERE id=" + req.id3db.execute(query)4# → CWE-89 · SQL Injection · deterministisch erkennbar

A concatenated SQL query has a stable shape. That is exactly what rules are built for: fast, reproducible and cheap enough to run on every commit. Nobody replaces this layer.

That is why we replace nothing. We add a second layer on top that can reason about intent.

Three layers instead of one tool

Each layer has its own class of flaws, its own cadence and its own price. Select a layer to see the deployment rule.

Layer 2

AI SAST with semantic reasoning

What it finds: Intent-dependent flaws: broken authorization, IDOR and BOLA, business logic, missing tenant isolation.
Where it runs: Targeted at high-value repositories: internet-facing services, authentication, anything holding personal or payment data.
What it costs: Moderate cost. The effort is justified by the class of flaw, not by volume.

Faster, cheaper, syntacticSlower, costlier, deeper

The question is never “which layer”, it is “which layer on which repository at which cadence”. We derive exactly that mapping with you — from exposure and data class, not from gut feeling.

Reachability is a hypothesis. Exploitability is proof.

Four steps separate a flagged piece of code from a real risk. Skip them and you are prioritising by feeling.

01
Finding
A rule or a model flags a location in the code. At this point, that is all it is.
02
Reachability
The flagged location sits on a path that can be invoked from outside.
03
Exposure
The service really is reachable: network path, identity, configuration.
04
Exploitability
The attack was executed against the running environment and it worked. From here it is no longer a suspicion.
05
Impact
What sits behind the path decides the order in which things get fixed.

What we take off your plate

We do not build a parallel organisation. We bring your existing toolchain into an order that holds — and take on the parts that need specialist knowledge.

Scanning architecture & tool assessment

Before another tool joins the stack, we clarify which layer makes sense on which repository at all.

Classify repositories by exposure and data class
Tool-neutral review of your existing stack
Cadence and cost model per layer

Introduce and calibrate AI SAST

Semantic code analysis is only as good as its acceptance criteria. We define them before the first run.

Pilot on defined repositories
Calibration against known, already-fixed findings
Acceptance criteria instead of vendor metrics

Exploit validation & counter-check

We test against the running system whether a finding really leads to an attack path.

Proof against the system, not against a diagram
Chain of evidence per confirmed path
Handover to engineering with reproduction steps

Secure code review for AI-generated code

Assistant-written code fails in predictable classes. That is exactly where the review starts.

Authorization, tenant isolation, error handling
Review guide for your code owners
Agent and prompt risks inside the repository itself

Remediation & ownership

The most mature finding goes nowhere if nobody is named. We close the gap between discovery and fix.

Code owner mapping down to the individual
Fix proposals as pull requests
SLAs by exploitability rather than CVSS alone

Evidence for CRA, NIS2 and customer audits

The same artefacts carry the audit, the customer questionnaire and the incident record — if they are produced that way from the start.

Test and assessment reports for the technical documentation
Security debt with a due date instead of an exception list
Metrics that show effect rather than activity

Four phases to a defensible result

No platform migration, no big bang. The path works with what most organisations already have in place.

Phase 1 · 2 weeks
Assessment
We review repositories, existing scanners, finding history and ownership. The result is a classification by exposure and data class — and an honest baseline.
Phase 2 · 4 weeks
Pilot
AI SAST on the most critical repositories, calibrated against known findings. In parallel the first validations: which paths are actually reachable?
Phase 3 · 6 weeks
Anchoring
Gates in the build, fix proposals to the code owners, SLAs by exploitability. Exceptions get documented and receive an expiry date.
Phase 4 · ongoing
Operation
Periodic frontier analysis for the most critical applications, metrics reporting, course correction. As a managed service on request.

What ends up on the table

Artefacts you can keep using — in the sprint, in the audit and in the customer questionnaire.

Repository risk register

All repositories by exposure, data class and ownership — the basis of every cadence decision.

Scanning target picture

Which layer on which repository at which frequency, including a cost and runtime estimate.

Validated findings list

Confirmed attack paths with chain of evidence and reproduction steps — cleanly separated from unconfirmed leads.

Fix packages

Root-cause fix proposals, delivered as pull requests to the responsible code owners wherever possible.

Test and assessment reports

In a form that fits the technical documentation required by CRA Annex I.

Metrics report

Share of validated findings, time from discovery to fix, ownership coverage and security debt by age.

How this connects to standards and regulation

We work along established references — so results convince internally and can be evidenced externally.

EU Cyber Resilience Act

Annex I Part II requires effective vulnerability handling across the support period; test and assessment reports belong in the technical documentation.

Regulation (EU) 2024/2847