Sixty criticals is not a plan
Sorting findings by severity produces a shorter list, not a sequence. Some of those criticals sit on an internal tool three people use. One of the mediums sits on the authenticated path to your customer data.
AIPTx ranks by exploitability, impact, asset value and exposure, and publishes the weights, so you can argue with the result on specifics.
Weights published · Exploitability weighted heaviest · CVSS 3.1 preserved unmodified
Overview
Every security team hits the same wall. The assessment finishes, the findings arrive, and now something has to be decided, because there are four hundred of them and capacity for a dozen this sprint.
The instinct is to sort by severity, and it does not work. CVSS is a property of the vulnerability, not of your situation. It was calculated once, by someone who has never seen your architecture, and it produces an identical number for every organisation running the affected component. That is the design, and it is the right design for a portable score. It is simply not a remediation order.
So the sorted list gives you sixty criticals, which is the same problem in a different arrangement. Meanwhile the finding that should be at the top is frequently a medium: a medium because in the abstract it is a medium, and the top of the queue because in your environment it is internet-facing, unauthenticated and one step from something that matters.
Prioritisation is the work of turning severity into sequence. AIPTx does it with weights you can see.
Ranking a finding
Findings are ranked by four weighted factors, heaviest first. The weights are published, so the arithmetic behind a position can be followed rather than taken on trust.
- Step 01
Exploitability: 40%
Can this actually be done?
Exploitability carries the heaviest weight, and AIPTx is in an unusual position to weight it that way. Most risk models estimate exploitability from attack complexity and public exploit availability, and arrive at a probability. AIPTx does not have to estimate, because it tried. A validated finding got there by having the attack performed and the request, response and reproducible curl command captured.
A predicted exploitability of 0.8 and a captured HTTP response proving the exploit are not the same evidence and should not produce the same score.
See AI Agent - Step 02
Impact: 30%
What does it cost if it is?
Impact is measured by what the exploit reaches, not by how alarming the vulnerability class sounds. The questions are whose data sits on the other side of it, how much of it, what the caller can do once they are there, and what has to be disclosed if it happens.
It is the difference between a flaw that returns aggregate statistics with no personal data in them and one that returns another customer's account records. Both can sit in the same severity band. Only one of them is a breach notification.
- Step 03
Asset value: 20%
What is the affected system worth to you?
Asset value is the factor only you can supply. No scanner knows that the low-traffic internal service holds your payment reconciliation logic. Setting it accurately is the highest-leverage configuration on the platform, because it is the input that most changes the ordering.
- Step 04
Exposure: 10%
How reachable is it?
Exposure asks what stands between an attacker and the affected path: whether the service is internet-facing or sits on an internal subnet, whether a session is needed to reach it at all, and whether the vulnerable route is called by something a user controls or only by a scheduled job.
It carries the lightest weight deliberately. Exposure rarely decides the top of the queue on its own, but it is what separates two findings that are otherwise identical, and it is the factor most likely to change without a line of code changing with it.
Scoring the environment
Ranked findings roll into a composite risk score from 0 to 100, derived from critical and high findings, exposure level and asset criticality weighting. The documented breakdown contributes up to 40 points for critical findings, up to 25 for high, up to 8 for exposure level and up to 5 for asset criticality, with the worked example in the documentation resolving to 78 out of 100, rated High.
That number is not a verdict handed down by a model. It is arithmetic from inputs you can see, and it appears in reports with the breakdown attached.
CVSS is preserved, not replaced
Every finding carries its CVSS 3.1 score and full vector string, unmodified, alongside the weighted ranking. Contextual weighting is applied as a separate layer and never by quietly editing the base score.
You always see both. A score you cannot trace back to CVSS is a score you cannot defend, and the CVSS value is also what keeps the finding portable to your other tooling and acceptable to an auditor.
The reasoning behind the model is set out on the AI Risk Engine platform page.
Capabilities
Weighted per-finding ranking
40/30/20/10Exploitability 40%, impact 30%, asset value 20%, exposure 10%, with weights published.
Exploitation-derived exploitability
EvidenceValidated findings carry the request, the response and a reproducible curl command, so the heaviest-weighted factor is observation rather than estimation.
Composite environment score
0–1000 to 100, from critical and high findings, exposure level and asset criticality, with the contribution breakdown visible.
CVSS 3.1 preserved
Unmodifiedcvss_score and full CVSS:3.1 vector on every finding, unmodified.
Severity tiers
Critical 9.0–10.0, high 7.0–8.9, medium 4.0–6.9, low 0.1–3.9, plus informational.
CWE classification on every finding
For comparability across tools and over time.
Compliance context
Findings carry a compliance object, so regulatory scope is visible while prioritising rather than discovered later.
Status lifecycle
Open, fixed, accepted, false_positive, with first_seen, updated_by, timestamps and notes.
Trend comparison across assessments
So the score is a tracked measurement rather than a snapshot.
Routing by priority
Findings into Jira and Linear with severity mapped to your scheme, and into pipeline gates by threshold.
Benefits
- 01
The queue becomes workable.
Four hundred findings resolve into an order someone can start at the top of, which is the only form in which a backlog gets worked.
- 02
The order can be defended.
Published weights mean a remediation sequence can be explained to engineering leadership on specifics rather than asserted. A prioritisation nobody can interrogate is one they will resist generally.
- 03
Exploitability is measured, not guessed.
The heaviest-weighted factor comes from an executed exploit, which is a categorically stronger input than a predicted likelihood.
- 04
Mediums that matter surface.
A finding is ranked by what it can actually do in your environment, not by what its class scores in the abstract.
- 05
CVSS keeps working.
Reports, tooling and auditors that expect it still get it, unmodified.
- 06
Progress is measurable.
A composite score tracked across assessments with a stable methodology turns activity into trajectory.
- 07
Accepted risk is visible.
A finding deliberately not fixed is recorded with a person, a date and a reason, rather than sitting in the queue looking like neglect.
- 08
Critical issues reach the front faster.
When impact, exploitability and business context are evaluated together, genuinely urgent findings rise above the noise instead of competing with hundreds of theoretically severe issues.
Two findings, identical CVSS, opposite priorities.
Illustrative example. Not a customer account.
Finding A. A deserialisation vulnerability in a reporting service. CVSS 3.1 base score 8.1, High. The service runs on an internal subnet, requires an authenticated administrative session, and holds aggregate statistics with no personal data. The affected code path is reachable only from a scheduled job.
Finding B. A broken object-level authorisation flaw on a customer API endpoint. CVSS 3.1 base score 6.5, Medium. Internet-facing. Reachable with any authenticated customer session. Returns other customers' account records. Validated: the agent performed the request and captured the response containing another account's data.
Sorted by CVSS, A is worked first. Every triage process built on severity alone produces that answer, and it is wrong.
- 01
Exploitability (40%): B was exploited with a standard customer session and the evidence captured. A requires administrative access on an internal network and could not be safely demonstrated. B scores far higher on the factor that carries the most weight.
- 02
Impact (30%): B returns customer records. A returns aggregate statistics.
- 03
Asset value (20%): the customer API is designated high criticality; the reporting service is not.
- 04
Exposure (10%): B is internet-facing; A is internal.
B ranks first, decisively, and the reason is visible on the finding rather than buried in a model.
What changes.
The team fixes the medium this week. The high goes into the normal cycle with a note explaining why. When someone asks why a High is not being treated as urgent, the answer is four factors and their weights, not "the tool said so."
FAQ
Frequently Asked Questions
How is the ranking calculated?
By four published weights — exploitability 40 percent, impact 30, asset value 20, exposure 10 — with findings rolling into a composite 0–100 environment score built from critical and high findings, exposure level and asset criticality.
Do you replace CVSS?
No — every finding carries its CVSS 3.1 score and full vector string unmodified, with weighted ranking applied as a separate layer on top so you always see both numbers.
Why does vulnerability severity vary between systems?
Because asset value and exposure differ, and an internet-facing production system holding customer data is not the same risk as an internal staging instance running identical code, which is precisely what a portable CVSS score cannot express.
Who sets asset value?
You do, because no scanner can know which of your systems matters most and the low-traffic internal service is frequently the one holding something critical.
How does exploitability get scored?
Primarily from whether the exploit succeeded, with conventional exploitability reasoning applied where a finding could not be safely exploited and proven kept distinct from predicted rather than blended into one number.
Are the risk tier thresholds published?
Yes — the CVSS severity bands are critical 9.0–10.0, high 7.0–8.9, medium 4.0–6.9 and low 0.1–3.9.
Is the scoring a black box?
No — the weights are published rather than described as proprietary, so where the model is wrong for your environment you can name the factor that is wrong instead of distrusting the number generally.
Does the ranking move as we fix things?
Yes, the composite environment score is built from what is currently open, so closing a critical finding moves the number and reports compare against previous assessments.
Features that work with this one
Nothing here is a separate product. One assessment feeds all of them, which is why the output is a single ranked plan instead of nine disconnected tools.
The fix arrives with the finding
Every finding arrives with the fix: a summary, the vulnerable and secure code side by side, and references. Not a link to a generic advisory.
An agent that changes its mind
Agents that read the response and decide what to try next, which is what makes access control and business logic testing possible at all.
Four audiences, four reports, one assessment
Four report templates for four audiences, five export formats, and a trend line that means something because the methodology does not change.
See the queue in order
Run an assessment and get findings ranked, with the factor breakdown visible on every one.
Weights published · CVSS 3.1 preserved