Vulnerability Discovery that tells you what's actually 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.
CVE Detection: 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.
Misconfiguration Detection: 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 traditional vulnerability scanner only reports the matches to a signature database and leaves the verification task to your team. AIPTx's discovery engine is unique in that it tests its own hypothesis and only confirms a finding if the exploit attempt succeeds and evidence was captured. This is particularly valuable for categories that do not have a well-defined signature, such as business logic testing and access control flaws, which are found through reasoning about how the application behaves, rather than pattern matching.
What vulnerability classes do you cover?
AIPTx includes more than 245 active tests across seven vulnerability classes: injection, authentication, access control, business logic, client-side, cryptography, and configuration/misconfiguration detection. The coverage of the OWASP Top 10 2021 categories is available for the platform, with different testing depths (Quick, Standard, and Deep scan modes).
How do you handle CVEs in dependencies?
The discovery of a CVE starts with a fingerprint of the frameworks, libraries, and server software actually running in the target application (not what is declared to be running). AIPTx then analyzes the complete dependency tree (including transitive dependencies) and applies reachable analysis to assign a severity before even attempting to exploit it; this prevents critical CVEs on unreachable code paths from wasting your team's time. When appropriate, the CVE is then also tested (exploited) to confirm that it can actually be triggered.
What is your false positive rate?
AIPTx does not publish a false positive reduction percentage since publishing a number without explaining the methodology would constitute misleading the user. Instead, each finding is always confirmed by an exploit attempt (with the request and response captured as evidence), logically grouped by root-cause analysis, and filtered with reachability analysis. The result is a significantly reduced surface of findings to review, where each finding is a minutes-long verification task.
How does severity get decided?
Finally, the finding's initial CVSS 3.1 score serves as a baseline for its severity (Critical: 9.0–10.0, High: 7.0–8.9, Medium: 4.0–6.9, Low: 0.1–3.9), but that baseline does not consider your application's environment. AIPTx adds context-specific risk assessment by analyzing the finding's reachability, the assets and data the vulnerable component can access, and the component's criticality. That information is then used to define the actual remediation priority within your environment.
Do you map to MITRE ATT&CK?
At the moment, AIPTx does not natively support MITRE ATT&CK technique mapping, but every finding is mapped to a relevant CWE and OWASP Top 10 2021 category and ties to a supported CVE and CVSS 3.1 standard for compliance reporting (PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST).
Explore the Rest of the AIPTx 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