Application security
Which security risks are real — and what it takes to close them
Scanners flag thousands of lines. CodeDD reads the business logic across the estate — every repository in scope — verifies each finding, and gives you the short list: severity, location, and hours to fix.
86
Flagged in the code
23
Valid after verification
7
Critical or High
~41h
To close those 7
| Finding | Area | Severity | Conf. |
|---|---|---|---|
| Missing authorization on invoice export | Billing | Critical | 92% |
| Hardcoded API key in billing config | Billing | Critical | 95% |
| SQL injection in report filter | Reporting | High | 88% |
| IDOR on invoice PDF download | Billing | High | 86% |
| Path traversal in file upload | Documents | High | 81% |
Selected · Missing authorization on invoice export
Any signed-in user can export any customer's invoices. Confirmed against the code at 92% confidence. About 3h to fix.
Trusted by
Beyond SAST
A thousand alerts is not a risk picture.
You cannot price a deal, set a 100-day plan, or prepare an exit from scanner output. You need the findings that are real, and what they cost to close.
Find what rule-based SAST misses
The costly flaws depend on intent: a missing authorisation check, an invoice anyone can fetch by ID. Rules do not see them — and more of that code is now AI-written and unreviewed.
Only verified findings count
A second pass re-checks every finding against the code. Only Valid findings at 80% confidence or above reach the report, so no one spends engineering time on false alarms.
Sized for a decision
Each finding carries severity, OWASP class, business area, and an hour estimate — a number you can put in a memo, a price discussion, or a plan.
The verdict
One view for the deal team and the CTO.
Verified exposure by OWASP class, severity, and business area, with the fix time next to it. Narrow it to what matters for this decision — access control in billing, or everything Critical.
From verdict to fix
The same list becomes the work.
Save the slice that matters: the pre-close list, or the next sprint. Engineers pull it into their coding assistant with the CodeDD CLI and resolve it finding by finding, and progress is recorded against the audit.
9
Valid in this slice
3
Repositories
~27h
To fix the slice
Saved viewPre-close — access control · 9 findings
$ codedd fix selections use 1
using saved slice · 9 findings
$ codedd fix flags next
[+] Critical · invoice export
no role check · 92% · ~3h
$ codedd fix resolve
resolved 4 of 9 · next: IDORCodeDD Advisor
Ask what the deal team will ask
The Advisor answers from this audit's data — verified findings, fix estimates, and who wrote the code — and lays the answer out as a chart or a table.
Across the investment cycle
One verified list, three moments that need it
The question changes from before signing to after close to before exit. The evidence does not.
Pre-deal tech DD
Know the real exposure and the hours to close it before signing — early enough to shape price, conditions, or the SPA.
Hold period
Make the verified list the security part of the value-creation plan. Re-audit to show exposure closing, not just tickets moving.
Pre-sale preparation
Find and close what a buyer's technical DD would find, before the data room opens — and leave less room to negotiate the price down.
Data handling
The target's source stays under control
Code access is the first objection in a technical DD. The answer should not depend on trust.
Erased after the audit
Cloud audits send scoped files for analysis, encrypted in transit and at rest, then overwritten. CodeDD keeps structured findings, not source.
Or run it inside the target
The audit can run in the target's own environment. Only structured results sync to CodeDD for reporting.
Never used for training
Customer source does not train CodeDD models. Inference providers process it transiently under the DPA and sub-processor terms.
FAQ
Questions
How is this different from SAST?
Rule-based SAST matches known patterns. It misses flaws that depend on intent — a missing authorisation check, an object anyone can fetch by ID — and it reports a large share of false alarms. CodeDD reviews the code in context, then verifies each finding against the evidence. What reaches you is the verified list, not a raw scanner export.
How is this different from a penetration test?
A penetration test attacks a running system from the outside, within a time box. This reviews the source code of every repository in scope, including paths a tester never reaches. They answer different questions and work well together: the verified list shows a tester where to look.
What does the confidence score mean?
Every flagged finding is re-checked against the code and gets one of three verdicts: Valid, Not vulnerable, or Inconclusive. Valid findings at 80% confidence or above are ready for a deal memo or a sprint. Inconclusive findings are held back and listed separately, with the next steps that would settle them.
What does the target company need to provide?
Read access to the repositories, through a GitHub, GitLab, Azure DevOps, or Bitbucket connection — or a local run in its own environment. The analysis works from the code, not from interviews or questionnaires.
Does CodeDD change the code?
No. CodeDD produces the verified list and the estimates. Engineers decide what to fix and when. The CLI hands findings to their coding assistant one at a time and records progress; it does not write or apply the fix.
See the verified exposure on a codebase you are evaluating
Run it on a repository yourself, or book a walkthrough of the findings, the severity, and the cost to close.