Triaging findings
Deciding what to fix first, and recording decisions so they survive the next review.
A first review usually produces more than you want to read at once. This is the order worth working in.
1. Committed credentials, first and immediately
If a live key is in the repository, the exposure continues until you rotate the key — not until you delete the line. Removing it from the latest commit leaves it in history, where it remains readable by anyone who can clone the repository.
So: rotate first, then remove, then worry about history. Monterva stores matched secrets redacted — we record that a key was present without keeping the key itself — but the copy in your repository is the one that matters.
2. Anything marked critical or high with high confidence
These are the findings where the tooling is both sure it matched and sure it matters.
3. Dependency advisories with a fixed version available
Usually a version bump. Fast to do, easy to verify with a re-scan.
4. Everything marked as requiring human review
These need your judgement rather than a rule. Read the evidence and decide.
Recording what you decide
Each finding can be marked:
- Open — not yet dealt with.
- Resolved — you have fixed it.
- Ignored — a real match you have decided not to act on.
- False positive — not a real problem in this code.
Marking a finding changes only its status. Severity, confidence, file paths and rule identifiers stay exactly as the analysis produced them, and cannot be edited — a report you can rewrite is not evidence of anything.
Confirming a fix
Re-scan. A finding that no longer matches shows as resolved in the comparison against the previous review. That is the difference between believing a fix worked and seeing that it did.