Guide
How to read a jeerc finding
Every finding page has the same parts in the same order, from the severity at the top to the retest at the bottom.
The first line
Above everything else, a finding shows:
- Its severity.
- What found it: SAST, SCA, Secret Scanning, IaC Scanning, Agentic SAST, Agentic Pentest (Black Box) or Agentic DAST (White Box).
- How: rule-based, or AI with its confidence.
- Where: the repository and the file.
What it is, and how to fix it
The description of the issue, why it matters, how to fix it, its identifiers (a CVE, a CWE) and references. For a pentest finding the heading reads "What was exploited, and how to fix it", and the finding carries the agent's proof of concept.
Why this severity
The reasons behind the severity, when they are known:
- Whether the issue is known to be exploited in the wild (the CISA KEV list).
- Its EPSS percentile, written out: more likely to be exploited than a given share of vulnerabilities.
- The reason the enrichment gave for its rating.
Next step (Team)
The AI verdict says whether the finding is a real, exploitable issue, how confident it is, and why, for example that the vulnerable function is called with input from a request. The AI fix is a patch that has already passed a re-scan; approving it opens a pull request on your repository. You approve every verdict and every fix.
Retest after a fix
Retest runs the engine that found the issue again: a scan of the repository, or a targeted pentest run. It does not close anything by itself; you confirm the result. A pentest retest uses one of your monthly pentests and asks you to type the hostname first.
See one first
A new organisation can open a sample finding from setup, built from the same parts as a real one.