Vulnerability intelligence
Understand CVSS, CISA KEV and EPSS data on Security findings, including policy settings and update timing.
What the values mean
- CISA KEV marks a CVE that CISA lists as known exploited. The badge shows the date CISA added it. This status does not change finding severity.
- EPSS estimates the chance that a CVE will be exploited in the next 30 days. The table shows its percentile. The score and date are in the tooltip. EPSS covers CVE IDs only.
- CVSS is the base score from the advisory's vector. It can differ from the scanner score and does not replace the finding's severity.
- Fix available is shown in finding details and filters. For dependency findings it uses a reported fixed version or a matching advisory package fix. Other finding types show unknown.
The Security page adds Exploited and EPSS columns. Use Filters to filter by known exploited status, EPSS percentile or fix availability. These values are available wherever the Security page is available.
Sources and updates
Advisory records come from OSV.dev and include records from the GitHub Advisory Database. KEV status comes from CISA's Known Exploited Vulnerabilities catalog. EPSS comes from FIRST.
Prodgator looks up supported public vulnerability IDs named by findings. Finding text, file paths, package names and repository names are not sent to these feeds. Advisory data is refreshed daily, KEV every six hours, and EPSS daily. If a feed is unavailable, Prodgator keeps its last stored data and shows its data date when it is stale.
Current feed values can change after a finding is first seen. Finding details show current values and, when available, the CVSS value recorded at detection. Recorded when this data was added marks a snapshot created for an existing finding after intelligence was introduced. It is not a historical record of what a gate used at detection.
Advisory data from OSV.dev and the GitHub Advisory Database is licensed under CC BY 4.0. Exploited status comes from CISA KEV. Exploit prediction comes from FIRST EPSS.
Security policy settings
The Security findings rule can optionally fail when a new finding is on KEV, or when any open finding in the repository is on KEV. It can also fail when an introduced finding's EPSS percentile meets or exceeds a threshold from 1 to 100. Both settings are off by default.
Custom rules and Rego can read these fields from . contains up to 50 of the worst introduced findings. The aggregate counts cover all introduced findings:
| Field | Meaning |
|---|---|
| Canonical public vulnerability ID, when available. | |
| and | Whether it is on KEV and the date added. |
| and | EPSS score and percentile, from 0 to 1. |
| Current advisory CVSS score, or null. | |
| True, false or null when unknown. | |
| , | Counts of introduced findings and open issues on KEV. |
| Highest introduced percentile, from 0 to 1, or null. | |
| Counts of introduced findings at or above each integer percentile threshold. | |
| , | Whether intelligence is current or partial, and public IDs with no fetched entry. |
For example, a custom rule in a mixed policy can block an introduced KEV finding when no fix is available:
package prodgator.custom.kev_without_fix
blocked := [i |
some i in input.security.issues
i.kev
i.fixAvailable != true
]
result := {
"status": "pass",
"blocking": true,
"reason": "no introduced finding is on KEV without a fix",
} if count(blocked) == 0
result := {
"status": "fail",
"blocking": true,
"reason": sprintf("%d introduced finding(s) are on KEV and have no known fix", [count(blocked)]),
} if count(blocked) > 0The policy input stored with each evaluation records the values used for that decision. See Pull request input document for the full shape.