Code Audit with a memory: what stayed, what came back

No, and it is not meant to. A penetration test thinks like an attacker from the outside: selective, creative, deep, with an eye on the running system. DELTA reads from the inside: without gaps across the agreed scope, repeatable, with a history. Anyone using both should aim the pentest at what is not visible in the code: runtime behavior, infrastructure, interaction with third-party systems. If you can only fund one: a pentest without a documented history gets paid for again every year and never answers the quarterly question.

Three things stand against that. First, the evidence requirement: no finding without a verbatim quoted, verifiable location — what cannot be evidenced does not exist. Second, the separate confidence: how certain it is that a finding is real stands beside it as a value of its own and is not mixed up with the severity. Third, the history: a one-off outlier stands out at the next scan and is visible as such. And the opposite case — a finding that gets overlooked — is the more important one — see the next question.

That can happen — with an AI-supported scan just as with a rule-based tool. Three things stand against it. First, a run only counts if it was complete: the pipeline rejects incomplete runs, and if a scope entry drops away compared with the last run, it raises an alarm before the data reaches the dashboard — a quietly reduced scope would otherwise “fix” everything nobody looks at any more. Second, an overlooked finding comes back and is visibly marked as a returning finding — a mistaken scan leaves a scar in the ledger, not a silent gap. Third, every fix stands on two legs: the verification criterion traceable in the code, and the absence across several runs, which the history table shows individually.

Because the two sit at different points in time. The verification criterion comes first and is addressed to your development team: it defines what counts as a remediation before anyone starts — a Definition of Done for this one vulnerability. The absence comes afterwards and is the proof that the change took effect. Without the criterion, “gone” would be arbitrary: a location can disappear without the cause being fixed — code renamed, call moved, symptom papered over. Both together are the evidence — one alone is not.

DELTA is not a release gate. It does not prove that your application is secure — no method can do that, neither rule-based nor AI-supported. It proves three things: what was found, what disappeared and what came back — each with a date and evidence. The fourth statement, “there is nothing left now”, appears nowhere on this page. It would be the only thing that would really reassure you, and that is exactly why we do not assert it.

From you. A code scan cannot see that, and we do not guess it. Before the first scan we record a short application profile: environment, reachability, business criticality, scope. This information is carried along with every scan, sits on every finding and is the reason the ranking holds up. If something changes — staging goes live, a service is sealed off — you change the application profile, and the prioritization follows. Which data classes hang on a location, by contrast, is what the auditor reads out of the code and evidences with the location.

We scan how you use your dependencies: outdated or redundant packages, risky integrations, call paths that are actually reachable. What we do not do is a comparison against a vulnerability database — that would need a feed updated daily, and we have not connected one. That monitoring belongs in your build pipeline anyway, where it runs daily instead of quarterly. We will tell you in the handover session whether it is missing on your side.

Because rule-based tools see what is in their rules. They find known patterns reliably and report everything that resembles a pattern — including what is harmless in your context. The AI auditor assesses the context on top of that: is this location reachable at all? Which data hangs on it? Is this running in production? That is the difference between 400 hits and 20 findings that hold up. Classic tools are not an opposite — their results can go through the same bookkeeping. Scanning uses the strongest model available. Not as a concession, but because the difference to the cheaper one is a single-digit euro amount and a missed finding is not. That decision is not negotiable, which is why it does not show up as an option in your quote.

Then we break the curve off instead of smoothing it. A new auditor, a new scope or a new model creates a new scan series: the line in the chart is interrupted and labeled, because the numbers before and after are not comparable. A jump from 5 to 23 findings sometimes measures the quality of the predecessor, not new gaps — a continuous line would claim the opposite. The old history stays fully visible.

For the scan the auditor needs read access to the code. That is the one unavoidable point, and we define in writing beforehand what it covers.

The models run exclusively in Azure, either in our tenant or in yours. Your code is processed there and is not used for training, contractually assured and processed within the EU. No provider outside that chain sees your source code.

If operation runs in your tenant, code, findings and dashboard stay entirely inside your own environment. We then only see what you show us in the handover session.

The dashboard itself calls nothing external at runtime. No interface, no fonts from third-party servers, no analytics services, no embeds. It is a static deployment and can sit behind your login, without internet access if it comes to that. Credentials and keys that are found are stored masked in the audit result, and the finding still remains complete. The dashboard has no write path, it cannot change anything, neither on our side nor on yours.

Yes — as a human assessment with a justification and a responsible person: false alarm, will not be fixed, cannot be fixed. This assessment is deliberately stored separately from the audit result and is never overwritten automatically. A scan is an observation; a judgment is not. That is why the one must not change the other.

Nothing you would have to work out beforehand. There is one price, and it is on this page. It does not change with the number of your applications, the number of findings or the number of runs. Before the quote we settle the cut of the scope and the rhythm together and put both in writing. That is an agreement about the work, not about the invoice. Your only choice on the price is monthly or annually in advance.

From the cut scope to the handover session, typically five to ten working days. The cutting itself is a conversation of about half an hour.