Work with findings
Read a Veriom finding, triage it, mark false positives, accept a risk, merge duplicates, and ask Veriom to open a fix pull request.
This page is for the developer or security engineer who acts on audit results. A finding is one problem an audit found, with the evidence for it. This page shows how to read a finding and move it to done.
Find what matters first
- Open Findings and select the All findings tab.
- Choose a view. Confirmed architecture impact shows only findings the agents confirmed affect your architecture. All scanner observations shows everything the scanners reported.
- Sort by Critical to low to start with the most severe.
Other views:
| View | Shows |
|---|---|
| Architecture relevant | Findings that affect the architecture |
| Needs architecture review | Findings the agents could not decide on. A person should look |
| Excluded by evidence | Findings the evidence shows do not affect the architecture |
| Awaiting agent review | Findings the agents have not reviewed yet |
The Structural risk, Root causes, and Ownership tabs group findings by architecture weakness, by shared cause, and by owner.
Read a finding
Click a finding to open it. It shows:
- Severity: Critical, High, Medium, or Low, from a 0 to 100 risk score or the CVSS score;
- Architecture impact, and how confident the agents are about it;
- the scanner and rule that reported it;
- Evidence: each file and line, with a short excerpt. Secrets are masked;
- the owner and the due date, when set.
Change a finding's state
| State | Meaning | Can move to |
|---|---|---|
| New | Newly found | Confirmed, False positive, Accepted risk |
| Confirmed | Someone agreed it is real | In remediation, False positive, Accepted risk |
| In remediation | A fix is in progress | Fixed, Reopened |
| Fixed | The fix is done | Reopened |
| False positive | Not a real problem | Reopened |
| Accepted risk | Real, but the team accepts it for now | Reopened |
| Reopened | Back for review | Confirmed, In remediation, False positive, Accepted risk |
To change it, open the finding, choose the new state from Allowed next states, add a Decision reason, and click Save status.
Who can do it:
- A Developer or above can change most states.
- Marking a finding False positive needs an Analyst or above and a reason.
- Accepted risk needs an Owner's approval. See below.
Accept a risk
Accepting a risk always needs a second person: an Owner who did not request it.
- An Admin turns on policy exceptions once, under Settings → Automation.
- On the finding, choose Accepted risk under Needs an Owner's approval.
- Enter a Decision reason of at least 10 characters and a Review date in the future.
- Click Send for approval. Veriom shows Accepted risk sent for an Owner's approval.
- Another Owner approves it.
On the review date, the finding goes back to Reopened automatically.
Merge duplicate findings
Different scanners can report the same issue. Veriom suggests pairs that look the same.
- Open Overview and select the Posture tab.
- Under Possible duplicate observations, open a pair. View comparison report shows them side by side.
- Click Confirm same issue, Keep separate, or Review later.
You need the Analyst role or above. Confirming marks the second finding as a duplicate.
Ask Veriom to fix it
Veriom can write a fix and open a pull request for you to review. It never merges.
- On the finding, click Request remediation. You need the Developer role or above.
- Veriom writes a patch and checks that it applies and passes verification.
- An Analyst or above reviews the patch and approves it.
- Veriom opens a draft pull request through the GitHub App.
- You review and merge the pull request on GitHub.
- After the merge, Veriom checks that the finding is gone.
Follow each fix on Audits → Remediations. A fix waiting for a person says so: Waiting for your approval before Veriom opens the pull request, then Waiting for review on GitHub with a link to the draft pull request. If a step fails, the remediation says why and offers Retry remediation. Fix pull requests need the GitHub App's Contents and Pull requests write permissions.
Veriom can also prepare and approve small fixes on its own if an Admin allows it. See Autopilot and autonomy.
Other actions on a finding
Click Request action on a finding to:
- Create a Jira ticket, if Jira is connected with ticket creation on;
- Route ownership to a person or team;
- Request a policy exception.
An Admin must allow each action under Settings → Automation first. Requests need a Developer or above. Approvals need someone other than the requester.
You can also comment on a finding and mention teammates with @.
Was this guide useful?
Your response stays in this browser unless you open a GitHub issue.