Vulnerability discovery that tells you what's real
Seven vulnerability classes. Static analysis, dynamic testing and AI-directed probing across every one of them. Findings that survive validation arrive classified, scored and mapped to the standards you already report against.
The rest arrive labelled as what they are.
- 245+
- Active tests across 7 vulnerability classes
- OWASP Top 10 2021
- Full category coverage
- CVSS 3.1
- Severity scored on every finding
Detection was never the hard part
Point enough tools at an application and you will get findings. Thousands, if you want them. The industry solved volume a decade ago.
What it did not solve is the question that follows every finding: is this real, is it reachable, and does it matter here? That question is answered by a person, one finding at a time, and it is where security teams lose their week. A queue of four hundred items is not coverage. It is a backlog of unanswered questions wearing coverage's clothes.
So the useful measure of a discovery engine is not how much it finds. It is how much of what it hands you has already been answered.
Known vulnerabilities, matched to what you actually run
A CVE only matters if the vulnerable component is present, reachable, and running in a configuration where the flaw applies. AIPTx checks all three before it puts a finding in front of you.
- Precise fingerprinting
- Detection starts with identification. AIPTx fingerprints frameworks, libraries, server software and versions from live behaviour (response signatures, header artefacts, bundled client code, dependency manifests) rather than from a declared inventory that drifted six months ago. A version guess produces a CVE guess, which is the origin of most of the noise in vulnerability management and worth getting right before anything else happens.
- Dependency and supply chain depth
- Direct dependencies are the easy part. Most real exposure sits one or two levels down, in a transitive package nobody chose and nobody is tracking. AIPTx analyses the dependency graph rather than the top-level manifest, so a vulnerable library pulled in by something you did install is visible.
- Reachability before severity
- A vulnerable package in your dependency tree is not automatically a vulnerability in your application. If the affected function is never called, or the code path cannot be reached from an entry point, a CVSS 9.8 on paper may be unreachable in practice. AIPTx factors reachability into how a CVE-derived finding is presented, so your team is not spending its Friday on a critical that no request can ever touch.
- Then it tries it
- Where a CVE-derived finding can be safely tested, AIPTx tests it. A confirmed exploit is a different object from a version match, and only one of the two is worth waking someone up for.See how exploitation and evidence capture work
Version matching tells you a component is a known risk.
Exploitation tells you your instance of it is.
The flaws that were never a CVE
Nobody files a CVE for an S3 bucket left open, a session cookie without Secure, or an admin panel reachable from the internet. These are not defects in software anyone shipped. They are decisions, and they cause a great deal of what actually goes wrong. AIPTx tests configuration as its own vulnerability class, with 45+ checks alongside the application-layer testing.
Authentication and session
Session fixation, missing rotation on privilege change, tokens that outlive their usefulness, cookie flags absent or wrong, password and lockout policy that exists in documentation but not in the running application.
Access control
Default credentials still live. Administrative interfaces reachable from networks they were never meant to face. Permission models that are correct in the UI and absent at the API, which is where most access-control failures actually live.
Cloud and storage
Publicly readable object storage, over-permissive IAM policy, metadata services reachable from application code, and network boundaries that were correct when they were written and have quietly drifted since.
Transport and headers
TLS versions and cipher suites past their useful life, certificate problems, HSTS missing, and the security header set that costs nothing to add and is missing more often than not.
Exposed services
Management ports, debug endpoints, admin consoles, staging environments indexed and answering. Almost always an oversight rather than a decision, which is precisely why nobody is looking for it.
Secrets and data exposure
Credentials in repositories, tokens in client bundles, keys in build artefacts, verbose errors returning stack traces and internal paths to anyone who sends a malformed request.
Application hardening
Directory listing enabled, dangerous HTTP methods answering, CORS policies wide enough to defeat their own purpose, debug modes running in production.
Container and orchestration
Privileged workloads, over-broad RBAC, registry exposure, and container configuration that turns one compromised pod into a cluster-level problem.
Monitoring gaps
The failure that shows up only during an incident: an attack path with no logging on it. AIPTx flags where an exploited path would have produced no evidence at all.
What gets tested
Seven classes, 245+ active tests. Depth varies by scan type, so the second grid shows what each mode reaches.
Injection
- Tests
- 50+
- What it covers
- SQL, NoSQL, command, LDAP, template and header injection
Configuration
- Tests
- 45+
- What it covers
- The misconfiguration surface in the section above: authentication, access control, cloud, transport, exposed services, secrets and hardening
Authentication
- Tests
- 40+
- What it covers
- Login flows, session handling, token lifecycle, MFA bypass
Access control
- Tests
- 35+
- What it covers
- IDOR, privilege escalation, horizontal and vertical authorisation
Business logic
- Tests
- 30+
- What it covers
- Workflow abuse, race conditions, state manipulation, price and quantity tampering
Client-side
- Tests
- 25+
- What it covers
- XSS, CSRF, clickjacking, DOM-based flaws, postMessage abuse
Cryptography
- Tests
- 20+
- What it covers
- Weak algorithms, poor key handling, insecure randomness, transport crypto
OWASP Top 10 2021 is covered in full, from broken access control through SSRF, including IDOR, SQL and NoSQL injection, insecure deserialisation and server-side request forgery.
OWASP Top 10
- Quick
- Yes
- Standard
- Yes
- Deep
- Yes
Business logic
- Quick
- –
- Standard
- Yes
- Deep
- Yes
Cryptographic analysis
- Quick
- –
- Standard
- Yes
- Deep
- Yes
Race conditions
- Quick
- –
- Standard
- –
- Deep
- Yes
Complex attack chains
- Quick
- –
- Standard
- –
- Deep
- Yes
A Quick Scan is built for a pull request, so it covers the classes that can be tested fast and honestly. It does not pretend to cover business logic. That testing needs session state, multiple roles and time, and any tool claiming to do it in a merge gate is not doing it.
Reasoning over findings, not just collecting them
Detection produces raw signal. What turns signal into a finding a person can act on is the analysis in between, and this is the part that is genuinely different from running three scanners and merging the output.
- Contextual payload generation
- Generic payloads test generic applications. AIPTx builds payloads shaped by what it observed: the framework in use, how the parameter is handled, what the last response revealed about the parser behind it. An input that rejected one encoding is a hint about what to try next, not a closed door.
- Anomaly detection
- Not every vulnerability announces itself with an error message. Behavioural analysis catches the response that is subtly wrong: a timing difference, an inconsistent status code across roles, an object returned that should not exist for this user.
- Context reconstruction
- A finding is meaningless without its surroundings. AIPTx assembles the context around each one: which role reached it, what state the session was in, what preceded it, and what the application appears to be trying to do at that endpoint.
- Correlation and deduplication
- The same underlying flaw surfaces at eleven endpoints because they share a helper function. Three tools each report it under a different name. AIPTx groups related detections into one finding with its instances attached, so remediation targets a cause instead of eleven symptoms.
- Impact reasoning
- Class alone does not determine impact. The same reflected XSS is a different problem on a marketing page and inside an authenticated admin console. Analysis considers what the affected component has access to and what an attacker would gain.
- Remediation guidance
- Each finding carries the specific change (the parameter to validate, the policy to tighten, the version to move to) rather than a link to a generic advisory the engineer must translate into their own stack.
Confirmed means it was exploited
Every tool in this category promises fewer false positives. Almost none of them will tell you what 'fewer' means or how it is achieved. Here is the mechanism.
- Validation by exploitation
- A finding reaches confirmed status when the attack is performed and the request and response that prove it are captured. Not when a version matched. Not when a heuristic scored above a threshold. The evidence travels with the finding, which is what lets someone else verify it without repeating the work.
- Correlation before reporting
- Findings are grouped by root cause before they are shown to you. Eleven instances of one flaw arrive as one finding with eleven locations, not as eleven tickets that three different engineers will investigate separately.
- Reachability filtering
- A detection on a code path nothing can reach is not a finding. Reachability analysis removes matches that are technically present and practically irrelevant, which is a large share of what makes dependency scanning exhausting.
A confirmed finding
Evidence attached to every one
- RequestThe one that worked
- ResponseWhat it returned
- ReproductionStep by step
- InstancesGrouped by root cause
- ReachabilityPath from an entry point
- ClassificationCWE · OWASP · CVSS
Triage becomes verification.
What we will not claim
No security tool can promise zero false positives, and a specific percentage without a published methodology is a number chosen by a marketing team.
What changes here is the cost of being wrong. When a finding arrives with the request, the response and the reproduction steps, confirming or dismissing it takes minutes rather than an afternoon of reconstruction. That is a real improvement and it can be stated honestly.
Every finding, classified against the standards you already use
A finding needs to mean the same thing to your engineer, your auditor and your risk register. Classification is what makes that possible.
- CWE
- Each finding carries the weakness class behind it. CWE is what makes findings comparable across tools and across time. It is how you answer 'are we getting better at this category' rather than 'did this scan find more things than the last one'.
- OWASP Top 10 2021
- Full category coverage, mapped per finding. The common language between security and engineering, and usually the framework a developer already knows.
- CVE
- Where a finding derives from a known vulnerability, the identifier travels with it, along with what AIPTx observed in your environment specifically.
- CVSS 3.1
- Severity scored consistently: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9. A shared baseline, though the baseline is the beginning of the prioritisation conversation, not the end of it.See how context adjusts what the score means
- Compliance frameworks
- Findings map to PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR and NIST, with control assessment and gap analysis in the reports. The audit question (which control does this affect) is answered before anyone has to ask it.
Why mapping is not paperwork
Classification looks like an administrative feature until the first time you need it.
It is what lets you tell an auditor which control a finding touches without a spreadsheet exercise. It is what lets you say 'broken access control is down forty percent this quarter' and have the sentence mean something. And it is what lets a developer recognise the class of mistake rather than just this instance of it, which is the only mechanism by which a team stops reintroducing it.
FAQs
Vulnerability discovery questions
How is this different from a vulnerability scanner?
A scanner reports what matches its signatures and leaves the verification to you. AIPTx tests its own hypotheses and confirms a finding only when the attack succeeds and the evidence is captured. The difference is most visible in the classes that have no signature at all (business logic, access control, workflow abuse), which are found by reasoning about what the application is meant to do, not by pattern matching against it.
What vulnerability classes do you cover?
Seven: injection, authentication, access control, business logic, client-side, cryptography and configuration. 245+ active tests in total, with full OWASP Top 10 2021 category coverage. Depth varies by scan mode; the table in the Coverage section shows exactly what each mode reaches.
How do you handle CVEs in dependencies?
By fingerprinting what is actually running rather than reading a declared inventory, analysing the full dependency graph including transitive packages, and factoring reachability into how the finding is presented. Where a CVE-derived issue can be safely tested, it is tested. A confirmed exploit and a version match are different objects and are not presented as the same thing.
What is your false positive rate?
We do not publish a percentage, because a rate without a published methodology is a number, not a measurement. What we can describe is the mechanism: findings are confirmed by exploitation with the request and response captured, correlated by root cause before reporting, and filtered by reachability. That makes verification a minutes-long task rather than an afternoon of reconstruction.
How are findings classified?
Every finding carries a CWE weakness class, an OWASP Top 10 2021 category where applicable, a CVE identifier where one exists, and a CVSS 3.1 severity score. Findings also map to PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR and NIST controls for reporting.
Do you map to MITRE ATT&CK?
Findings map to CWE, OWASP Top 10 2021, CVE and CVSS 3.1 today. ATT&CK technique mapping is not currently part of the product.
What formats can we get findings in?
PDF for reporting and compliance, interactive HTML with navigation and search, JSON for machine consumption, CSV for tracking systems, and SARIF for CI/CD and IDE integration. SARIF is the one that matters most day to day: it puts findings directly into the developer's editor and pull request.
How does severity get decided?
CVSS 3.1 provides the baseline: Critical 9.0–10.0, High 7.0–8.9, Medium 4.0–6.9, Low 0.1–3.9. But a CVSS score is calculated without any knowledge of your environment, so it is a starting point. Contextual factors (reachability, what the affected component has access to, asset criticality) are what determine the order you should actually work in.
The rest of the platform
Discovery is one view of one engine. Each capability feeds the next.
Autonomous Pentesting
AI agents that map the surface, exploit what they find and prove it, the testing that produces everything on this page.
See how testing runsAI Risk Engine
CVSS is a shared baseline calculated without ever seeing your environment. This is what happens after context is applied.
See how risk is scoredAttack Chain Analysis
Four medium findings in the right order is a breach. This is the view that shows which four.
See the attack pathsSee what it finds in your environment
Run an assessment and get findings classified, scored and validated, with the evidence attached to each one. No credit card required.
Scope verified before any test runs · Destructive actions off by default