Solutions · Vulnerability Assessment
Assessment that ends in evidence, not a spreadsheet
Most assessment programmes produce a document nobody finishes reading and a backlog nobody finishes working. The scan runs, findings arrive, and the team spends longer establishing which ones are real than fixing the ones that are. The problem is not the assessment. It is what the assessment hands over.
- Coverage
- Applications, APIs and networks under one scope
- Validation
- Request, response and curl command on every confirmed finding
- Scoring
- CVSS 3.1 with full vector, CWE class, compliance mapping
- Lifecycle
- open, fixed, accepted, false_positive, with first_seen
- Reporting
- PDF, HTML, JSON, CSV, SARIF
Overview
- What it is
- Why it stalls
Is the finding real, and can that be shown rather than asserted?
Is it reachable in your environment, or only in the abstract?
Is it worth the engineering time the fix will cost?
Assessment is the most practised security activity and the least satisfying to run
Vulnerability assessment is the most widely practised security activity and one of the least satisfying to run.
The mechanics are straightforward: examine systems, identify weaknesses, report them, track remediation. The difficulty is entirely in the middle. A finding is only useful if someone can establish that it is real, that it is reachable in your environment, and that it is worth the engineering time it will cost. Answering those three questions is manual work, it is repeated per finding, and it is where assessment programmes quietly fail.
The volume makes it worse. A tool that reports everything it notices is easy to build and produces a backlog that grows faster than the team can service it. After two or three cycles the programme becomes ritual: the scan runs because it must, the report is filed because it must be, and the findings are worked in whatever order someone had time for.
An assessment worth running is one where the questions have been answered before the findings arrive, and where what you learned last quarter is still present this quarter.
Key Challenges
- Failure modes
Where assessment programmes quietly fail
Seven failure modes, none of them about detection. Each one is a reason a programme produces documents instead of progress.
The problem is not the assessment. It is what the assessment hands over.
- Volume without resolutionHundreds of findings, no indication of which are genuinely exploitable in your specific environment, and no way to tell from the report.
- Triage consumes the remediation budgetThe hours that were meant for fixing go to reproducing, confirming and dismissing. In most programmes this is the single largest cost and it is invisible in every business case.
- No continuity between cyclesEach assessment starts from zero. Whether last quarter's findings were fixed, accepted or forgotten is a separate research exercise, usually conducted in a spreadsheet by whoever inherited it.
- Duplicate findings across tools and endpointsThe same underlying flaw reported eleven times because it appears at eleven endpoints, and again under three different names by three different tools.
- Compliance evidence assembled by handThe audit asks for proof of regular assessment and remediation, and someone spends two weeks building a document from scan exports and ticket histories.
- Coverage stops where the tooling stopsApplications get assessed thoroughly, APIs partially, internal infrastructure occasionally, and the boundaries between them not at all.
- Progress is unmeasurable"We closed 340 findings" describes activity. Whether the organisation is more secure than last quarter is a different question, and most programmes cannot answer it.
- Findings arrive disconnected from deliveryThe report lands in one system, remediation happens in another, and verification in a third. Every handoff introduces delay, duplication and the risk that a critical issue simply falls between the gaps.
Outcomes
What changes when the evidence arrives with the finding
Triage becomes verification
Evidence converts an afternoon of reconstruction into a two-minute confirmation, and that single change is what determines whether a backlog moves.
The programme remembers
Status carries between cycles, so progress is visible and accepted risk is a recorded decision rather than a gap in the record.
One report instead of three
Applications, APIs and infrastructure assessed under one scope, with one severity scheme and one set of controls to reconcile.
Audit evidence is a download
Control mapping, gap analysis and retest history are generated per assessment rather than assembled before a deadline.
Progress becomes measurable
Trend comparison against previous assessments turns activity reporting into something a board or an auditor can actually interpret.
Remediation is verified
Findings close when the exploit stops working, which is a different and stronger claim than a closed ticket.
The AIPTx Solution
- How it works
- Coverage
One scope, one engine, one report
Across applications, APIs and networks. Assessment does not stop at a surface boundary because your attack surface does not.
- 01
Findings are checked before they reach you
Where a finding can be safely exploited, it is. What arrives carries the exact HTTP request, the response proving it worked, and a reproducible curl command. The first and most expensive triage question (is this real) has already been answered.
- 02
Correlation before reporting
Findings sharing a root cause are grouped, so eleven instances of one missing authorisation check arrive as one piece of work with eleven locations rather than eleven tickets for three engineers to investigate separately.
- 03
The programme has a memory
Every finding carries a status: open, fixed, accepted or false_positive, with updated_by, timestamps and notes on every change, and a first_seen date. Next quarter continues the conversation instead of restarting it.
- 04
The accepted state deserves attention
Some risk is accepted deliberately and that is legitimate. Recorded with a name, a date and a reason, it is a governance artefact. Unrecorded, it is indistinguishable from something that was missed.
- 05
Scored consistently
CVSS 3.1 with the full vector string on every finding, plus a CWE class and compliance mapping. Findings ranked by weighted factors (exploitability 40%, impact 30%, asset value 20%, exposure 10%) and the environment scored on a published 100-point scale.
- 06
Evidence generated rather than assembled
Reports carry an executive summary with risk scoring, business impact and trend comparison against previous assessments; a detailed findings summary; and risk analysis. Control mapping covers PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS with gap analysis. Exports run to PDF, HTML, JSON, CSV and SARIF.
- 07
Remediation arrives with the finding
A summary, a code example showing vulnerable and secure patterns side by side, and references, so the handoff to engineering does not require translation.
| Surface | How it is reached |
|---|---|
| Web applications | Over HTTP and HTTPS |
| REST APIs | From an OpenAPI or Swagger specification |
| GraphQL | Schema introspection |
| gRPC | Proto files |
| External networks | IP ranges and CIDR blocks |
| Internal networks | Docker-deployed agent, outbound connectivity only |
Key Capabilities
- What it does
Key capabilities
Thirteen capabilities, one scope. Coverage detail lives on the Vulnerability Discovery platform page; this is what the assessment itself does.
Coverage
Seven vulnerability classes and 245+ active tests, with full OWASP Top 10 2021 category coverage.
CVE detection
Version fingerprinting from live behaviour rather than a declared inventory, with CVE matching against detected versions.
Network assessment
Port scanning, service detection, version detection, CVE matching, SSL/TLS analysis and default credential testing across IP ranges and CIDR blocks; SSH, MySQL and Redis service-specific checks.
Internal assessment
Docker-deployed agent, outbound connectivity only.
Application and API assessment
Web applications, REST via OpenAPI or Swagger, GraphQL with introspection, gRPC with proto files.
Authenticated coverage
Bearer, basic, cookie, custom headers, OAuth2/OIDC, scripted login with token extraction, multi-role configuration.
Confirmed findings
proof_of_concept containing request, response and curl_command.
Scoring and classification
cvss_score and CVSS:3.1 vector, cwe_id, compliance object.
Persistent lifecycle
open, fixed, accepted, false_positive, with first_seen, updated_by, timestamps and notes.
Retest
Re-runs the specific exploit; closes on evidence.
Reporting
Executive summary, findings summary, risk analysis, trend comparison; PDF, HTML, JSON, CSV, SARIF.
Compliance mapping
PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS, with control assessment and gap analysis.
Delivery
Jira, Linear, Slack, Microsoft Teams, webhooks, REST API, CLI.
Use Cases
- Where it fits
Where the assessment earns its place
Seven programmes that run on the same engine and the same record, from a quarterly cycle to a pre-audit evidence pack.
Quarterly assessment cycle
Scheduled Standard runs across the estate, reported by environment, with trend comparison against the previous quarter.
Pre-audit evidence
A Deep assessment before a SOC 2, ISO 27001 or PCI DSS window, with control mapping and retest history attached to the evidence pack.
Post-acquisition baseline
Establishing what an acquired estate contains and what condition it is in, before integration decisions are made.
Internal infrastructure sweep
Agent-based assessment of internal ranges, the part of the estate external scanning cannot reach and most programmes assess least often.
Customer or vendor assurance
Producing a current assessment report on request rather than on a schedule.
Continuous programme baseline
A full assessment to establish the starting position, with pipeline scanning between cycles.
Remediation verification cycle
A scheduled retest pass across everything marked fixed since the last assessment.
FAQ
Vulnerability assessment questions
How is this different from a vulnerability scanner?
Scanners report matches and leave verification to you. Assessment here includes exploitation wherever it can be performed safely, so a confirmed finding arrives with the request, the response and a reproducible curl command rather than a signature match to investigate. It also covers classes a scanner structurally cannot reach: access control and business logic have no signature.
What is your false positive rate?
We do not publish a percentage, because a rate without a published methodology is a number rather than a measurement. What can be described is the mechanism: findings are validated by exploitation, correlated by root cause before reporting, and anything dismissed is recorded as false_positive with a name and a date rather than silently dropped. No tool can honestly promise zero.
Does it cover internal networks?
Yes. Deploy the AIPTx agent via Docker with outbound connectivity only, and assessment runs against internal IP ranges and CIDR blocks: port and service detection, version detection, CVE matching, TLS analysis and default credentials, plus SSH, MySQL and Redis specifics.
Which compliance frameworks are supported?
PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS, with control assessment and gap analysis included in reports.
How often should we assess?
Change rate matters more than policy. A monthly or quarterly cadence suits most estates, with Quick Scans in the pipeline between cycles and a Deep run before an audit window. An estate that changes weekly needs something continuous underneath the cycle.
Can findings feed our existing risk register or GRC system?
Findings export as JSON and CSV and are available through the REST API, and route into Jira and Linear as tickets. Each carries CVSS 3.1 with the vector, a CWE class, compliance mapping and full status history.
What happens to findings we accept?
They move to accepted with the person, date and reason recorded. When an audit asks why a high-severity finding from two quarters ago is still open, that record is the answer.
Do you deduplicate across assessments?
Findings carry a first_seen timestamp and persistent status, so a finding present in consecutive assessments is the same finding rather than a new one. Within an assessment, findings sharing a root cause are correlated and reported once with their locations attached.
Assess everything, not the part that fit the budget
One scope across applications, APIs and infrastructure, with evidence on every finding and a record that carries into next quarter.
Where this connects
Vulnerability Discovery
Coverage and classification mechanics behind the seven vulnerability classes and 245+ tests.
AI Penetration Testing
How validated exploitation works, and where it goes further than assessment.
Continuous Security Validation
Covering the gap between assessment cycles with pipeline scanning.
AI Risk Engine
The scoring model and the published weights behind finding prioritisation.
Continuous Exposure Management
Running assessment as a standing programme rather than a scheduled event.
View all solutions
Every assessment, penetration test and managed programme we run.