Can we just compute a CVSS score for a vulnerability in our own application?

You can, and some teams do, but a self-assigned score does not provide the same shared context as a score maintained across the wider vulnerability ecosystem. CVSS is valuable partly because it provides a standardised way to describe and compare vulnerabilities, while a vector you assign yourself depends on the person doing the assessment and the assumptions they make. There is also an important distinction in what Base scoring provides. The Base Score is intended to describe the vulnerability's intrinsic severity and assumes a reasonable worst-case impact across different environments, while CVSS Environmental metrics can be used to account for factors specific to your environment. For an application you own, that environment-specific knowledge is available directly, so it should remain visible rather than being reduced to a Base Score alone.

Why does a flaw in our own code have no EPSS score?

EPSS is scoped to publicly tracked CVEs. It uses exploitation-related signals to estimate the probability that a vulnerability will be exploited within the next 30 days, and its published data is keyed to CVE identifiers. A flaw that exists only in your application's code and has no published CVE therefore has no EPSS score. The important point is that this absence does not mean the vulnerability has a low probability of exploitation. It means the vulnerability is outside the scope of the EPSS dataset.

Does this mean we should stop using CISA KEV?

No. KEV provides a type of information that testing your own application cannot provide: evidence that particular vulnerabilities have been exploited in the wild. CISA describes the catalogue as an authoritative source of vulnerabilities that have been exploited in the wild and recommends using it as an input to vulnerability-management prioritisation. A vulnerability unique to your own codebase will not appear in KEV unless it becomes a publicly tracked vulnerability that meets the catalogue's criteria. Keep KEV for the vulnerabilities it covers, and use application-specific evidence for findings that fall outside it.

If there is no CVE, what should we rank on instead?

Rank on properties you can establish directly from your own application. Did an attempted exploit actually work against the system, and can someone reproduce it from the evidence provided? What level of access did the attacker need before they could begin? What data, money, functionality or administrative action did the successful path reach? And is the underlying defect limited to one handler or present in shared code used by multiple routes? Those four properties provide a practical basis for ordering findings without reducing them to a single composite score.

How do we compare an application finding against a dependency CVE when scheduling work?

A practical approach is to keep two ranked lists that meet when work is scheduled rather than forcing everything into one scoring system. Dependencies, base images, operating-system components and many managed services can have published CVEs, so CVE-based vulnerability intelligence can provide useful context there. Findings in code you wrote can instead be ordered using evidence from your own application. Forcing both types of work through the same scoring process can hide important differences, such as a verified authorisation bypass being ranked below a dependency advisory that does not affect a code path you actually use. Keeping the evidence behind each list visible makes the eventual scheduling decision a judgement about your own environment rather than simply a comparison of numbers.

Back on Articles page

24 September 2026

How to Prioritise Security Findings That Have No CVE

12 min. readBy Borg

A continuous testing programme changes the shape of your security work. Instead of a report twice a year, you get a queue that never empties. The first question every team asks once that queue exists is which item to pick up first.

Most teams reach for the scoring systems they already know. CVSS gives a number out of ten. EPSS gives a probability. CISA maintains a catalogue of what attackers are actually using. All three are good tools, widely adopted for sound reasons, but two of them are explicitly built around a published CVE: EPSS predicts exploitation for CVEs, and KEV catalogues exploited CVEs. CVSS is broader, but in practice its standardised scores are most commonly consumed through the CVE ecosystem.

The findings that come out of testing your own application are usually not that object. A tenant boundary that holds on the read path and not the write path has no CVE. Neither does an approval step that can be replayed, or an endpoint that authorises against a stale copy of the user's role. Nobody issues an advisory for your billing logic. So EPSS and KEV return nothing for a large part of the queue, while CVSS can still be calculated but loses much of the shared context and comparability that make it useful across organisations.

This is a practical guide to ranking findings that no external scoring system will score for you.

What the three standard systems actually measure

It is worth being precise about these, because the reason they do not apply is specific rather than general.

CVSS is a severity framework maintained by FIRST. Its specification is explicit that the Base group "represents the intrinsic qualities of a vulnerability that are constant over time and across user environments", and that the Base Score "reflects the severity of a vulnerability according to its intrinsic characteristics". Constant across environments is the load-bearing phrase. Base scoring deliberately assumes the reasonable worst-case impact across different deployments; environment-specific factors are handled separately through the Environmental metrics.

FIRST is also clear that a Base score on its own is not meant to be a risk decision. The specification tells consumers they "should enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system", which yields "a more comprehensive input to risk assessment specific to their organization". It lists regulatory requirements, the number of customers affected and monetary losses as outside CVSS entirely. In practice most teams never see the enriched score: the specification notes that assessment providers such as product maintainers and the National Vulnerability Database "typically provide only the Base Scores".

EPSS, also from FIRST, answers a different question. It is "a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days", published as a probability between 0 and 1 and refreshed daily. It is genuinely useful for the problem it targets, which is a backlog of thousands of CVEs where severity alone cannot tell you where attention is best spent.

The CISA Known Exploited Vulnerabilities catalogue takes the empirical route. CISA describes it as the authoritative source of vulnerabilities that have been exploited in the wild, and recommends feeding it into a prioritisation process. Every entry in the published catalogue is identified by a CVE.

Note what all three have in common. CVSS scores are supplied at scale by NVD and by product maintainers, against CVEs. EPSS is defined, in FIRST's own wording, over a published CVE. KEV is indexed by CVE. The apparatus is built on a shared identifier for a vulnerability in distributed software, and it works well because that identifier lets thousands of organisations pool what they learn about the same bug.

Why none of it reaches a bug in your own code

A finding in your own application often does not have the same public vulnerability record as a vulnerability in widely distributed software. It may exist only in your codebase, with no published CVE, shared exploitation data or external advisory. That has three consequences.

There may be no public CVE identifier, so there is often nothing to look up in the external vulnerability databases. You can still compute a CVSS vector for your own finding by hand, and some teams do, but you are then producing the score rather than consuming an externally maintained assessment. That can still be useful internally, but it loses much of the shared context and comparability that make the wider CVE ecosystem valuable.

EPSS only scores published CVEs, so an application-specific finding with no CVE has no EPSS score. EPSS learns from signals associated with published vulnerabilities, including observed exploitation activity. A flaw that exists only in your application and has never been assigned a CVE therefore does not receive an EPSS probability. Its score is not low. It does not exist.

And the worst-case assumption cuts the wrong way. CVSS Base deliberately assumes the worst reasonable deployment because the scorer cannot see yours. For a finding in your own application you can see yours, in detail, and the honest impact may be much smaller or much larger than a generic worst case would suggest. An IDOR on an endpoint returning a display name is not the same as an IDOR on an endpoint returning an export. CVSS can incorporate environment-specific factors, but it does not replace the application-specific context your own team has about the data, workflows and business impact involved.

None of this is a criticism of the three systems. They are solving the pooled-knowledge problem, and they solve it well. They are simply not addressed to the class of finding that offensive testing against your own application produces.

What to rank on instead

The useful properties of an application finding are the ones you can observe directly, because you own both the code and the running system. Four of them do most of the work.

Whether the attempt actually succeeded. A finding that records an attempt against the running application, with the steps to reproduce it, is a different object from a pattern match that suggests a problem might exist. This is one of the strongest ranking signals available, and it is available before any judgement of severity. If nobody has established that the path works, the first task is not to rank it, but to test it.

What the attacker needed to start. An unauthenticated path is generally easier to reach than one requiring an ordinary user account, which is generally easier to reach than one requiring an elevated role or restricted internal access. This is the closest analogue to CVSS Exploitability, and unlike a generic Base vector you can answer the authentication question exactly, because you know your own authentication model.

What the successful path reaches. Not the endpoint, the data or the action at the end of it. Another tenant's records, a payment path, a credential, an administrative function. This is where your own knowledge provides context that an external framework cannot supply on its own, because you know which data, actions and workflows actually matter to the application.

How much of the system shares the defect. A missing authorisation check on one handler is one fix. The same missing check in a helper used by forty handlers is a different piece of work with a different urgency, even though the individual finding looks identical.

A practical ranking can be built from those four properties without inventing a composite number. Findings where an attempt succeeded, from a starting position an attacker can plausibly reach, touching data or money, come first. Findings where the attempt succeeded but the starting position requires access an attacker is unlikely to have come next. Unverified suspicions get tested before they get argued about.

Why "verified" is doing so much work here

The first property deserves defending, because it is contested. HackerOne, announcing its own agentic testing product in January 2026, characterised the fully autonomous end of this market as producing "shallow, unverified results that create noise rather than insight". That is a fair warning and it is worth taking seriously rather than dismissing, because a queue of machine-generated maybes is genuinely worse than a shorter list of confirmed problems: it consumes the triage attention that prioritisation is supposed to save.

The answer that survives contact is not a confidence rating. A confidence rating is another number someone has to learn to trust. The answer is an attempt that was made and observed, with the reproduction steps attached, so the person receiving it can run the thing themselves and stop debating. That is what makes verification a prioritisation signal rather than a quality badge: it converts an argument about likelihood into a question of fact, and questions of fact can be settled in the time it takes to follow the steps.

It is also the property that most often reorders a queue. Under this approach, a finding described as medium severity that comes with a working reproduction can be placed ahead of a high-severity item nobody has confirmed, because one is a demonstrated problem and the other remains a hypothesis.

Comparing the approaches

Approach	What it ranks well	Where it does not reach	Limitation to keep in mind
CVSS Base	Published CVEs, comparably across organisations	Findings with no CVE; anything where your environment changes the impact	Base is severity, not risk. FIRST recommends Threat and Environmental enrichment that most teams never apply
EPSS	Large CVE backlogs where you need likelihood, not just severity	Anything without a published CVE, which includes most application-logic findings	Estimates probability of exploitation in the wild, so it says nothing about impact or about your specific controls
CISA KEV	Known real-world exploitation, as a strong signal for vulnerability-management prioritisation	Bugs unique to one application, which will never appear in a public catalogue	Records exploitation that CISA has determined is occurring or has occurred in the wild. Absence from the catalogue is not evidence that a vulnerability is safe or unexploited.
Manual severity triage	Context only your team has	Consistency, especially across reviewers and across months	Depends on who is in the room, and tends to drift toward whoever argues most confidently
Exploit-verified ranking (what Borg produces)	Findings in your own application, ordered by what an attempt actually reached	Known CVEs in your dependencies and infrastructure, which this does not attempt to cover	Only ranks what has been tested. Coverage gaps are invisible to it, so it should not be read as a complete picture of risk

Where the CVE apparatus is the right tool, and this is not

The case above is about a specific class of finding. It is not an argument that CVSS, EPSS and KEV are outdated, and a team that dropped them on the strength of this piece would be making a mistake.

For dependency and infrastructure vulnerabilities, they remain important instruments, and nothing here removes the need for them. Your third-party packages, base images, operating-system components and many managed services can carry published CVEs, and for those you genuinely want the pooled knowledge: a severity framework that lets you compare across vendors, a probability model trained on exploitation observed across the whole internet, and a catalogue telling you what is being used against people right now. No amount of testing your own application tells you that a widely deployed library has just started being exploited. KEV can provide that external exploitation signal, which is exactly the kind of information application testing cannot supply.

The two problems also fail differently. A missed dependency CVE is usually a patch you did not apply in time. A missed business-logic flaw is usually a design decision nobody revisited. They need different instruments because they are different work, and a team running only one of the two has a gap either way.

The practical arrangement most teams end up with is two ranked lists that meet at the point of scheduling: CVE-scored work for what you consume, evidence-ranked work for what you build. What you should not do is force the second list through scoring built for the first, which is how a verified authorisation bypass ends up sitting below a dependency advisory that does not reach any code path you actually run.

Making it work in practice

Three things make the ordering hold up once it leaves the spreadsheet.

Put the evidence where the fix happens. A rank that lives in a security tool and a fix that happens in an engineering tracker will drift apart within a week. Findings that arrive in Linear, Jira or GitHub with the reproduction attached keep the ranking and the work in the same place, which is also where the person who has to argue about priority already is.

Let the ranking change when the evidence changes. Ranking on observed properties means new observation can reorder the list. A finding that looked contained until testing found the same helper reachable from an unauthenticated route should move, and a process that cannot move it is not really ranking on evidence.

Close findings on verification rather than on a merged pull request. A fix marked done is a claim; a fix that has been re-examined against the change is a checked claim. We covered that mechanic in detail in how automatic retests verify a fix when your PR merges.

What this does not solve

Ranking is downstream of coverage, and that is the honest limit of everything above. An order over the findings you have says nothing about the findings you do not have. If testing has never reached a particular flow, that flow contributes nothing to your queue and it will look, from the queue, exactly like a flow with no problems in it.

So the ranking is only as good as what has been tested, and the useful discipline is to keep asking what is absent from the list rather than only working down it. Continuous asset discovery helps on the infrastructure side by telling you what exists. On the application side the equivalent question is which flows and roles have actually been exercised, and that is worth reviewing on the same cadence as the queue itself.

The second limit is that none of this produces a single number, and some organisations need one for reporting. Four observed properties are more defensible than a composite score and considerably harder to put in a board slide. If you need the number, derive it from the properties and keep the properties visible underneath, so that the ordering can still be interrogated when somebody disagrees with it.

Frequently asked questions

Can we just compute a CVSS score for a vulnerability in our own application?: You can, and some teams do, but a self-assigned score does not provide the same shared context as a score maintained across the wider vulnerability ecosystem. CVSS is valuable partly because it provides a standardised way to describe and compare vulnerabilities, while a vector you assign yourself depends on the person doing the assessment and the assumptions they make. There is also an important distinction in what Base scoring provides. The Base Score is intended to describe the vulnerability's intrinsic severity and assumes a reasonable worst-case impact across different environments, while CVSS Environmental metrics can be used to account for factors specific to your environment. For an application you own, that environment-specific knowledge is available directly, so it should remain visible rather than being reduced to a Base Score alone.
Why does a flaw in our own code have no EPSS score?: EPSS is scoped to publicly tracked CVEs. It uses exploitation-related signals to estimate the probability that a vulnerability will be exploited within the next 30 days, and its published data is keyed to CVE identifiers. A flaw that exists only in your application's code and has no published CVE therefore has no EPSS score. The important point is that this absence does not mean the vulnerability has a low probability of exploitation. It means the vulnerability is outside the scope of the EPSS dataset.
Does this mean we should stop using CISA KEV?: No. KEV provides a type of information that testing your own application cannot provide: evidence that particular vulnerabilities have been exploited in the wild. CISA describes the catalogue as an authoritative source of vulnerabilities that have been exploited in the wild and recommends using it as an input to vulnerability-management prioritisation. A vulnerability unique to your own codebase will not appear in KEV unless it becomes a publicly tracked vulnerability that meets the catalogue's criteria. Keep KEV for the vulnerabilities it covers, and use application-specific evidence for findings that fall outside it.
If there is no CVE, what should we rank on instead?: Rank on properties you can establish directly from your own application. Did an attempted exploit actually work against the system, and can someone reproduce it from the evidence provided? What level of access did the attacker need before they could begin? What data, money, functionality or administrative action did the successful path reach? And is the underlying defect limited to one handler or present in shared code used by multiple routes? Those four properties provide a practical basis for ordering findings without reducing them to a single composite score.
How do we compare an application finding against a dependency CVE when scheduling work?: A practical approach is to keep two ranked lists that meet when work is scheduled rather than forcing everything into one scoring system. Dependencies, base images, operating-system components and many managed services can have published CVEs, so CVE-based vulnerability intelligence can provide useful context there. Findings in code you wrote can instead be ordered using evidence from your own application. Forcing both types of work through the same scoring process can hide important differences, such as a verified authorisation bypass being ranked below a dependency advisory that does not affect a code path you actually use. Keeping the evidence behind each list visible makes the eventual scheduling decision a judgement about your own environment rather than simply a comparison of numbers.