Read and act on findings

A finding is one thing a scanner noticed in one place in your code. This page explains every part of a finding and what to do with it.

Get the full list

The terminal summary shows counts only. Use one of the full formats to see each finding:

sentinel scan . --format markdown --output report.md   # for reading
sentinel scan . --format json --output report.json     # for tools and scripts

You can turn a saved JSON report into another format later without scanning again:

sentinel report report.json --format markdown --output report.md

In a Markdown report, findings are sorted by severity, then by file, then by line.

The parts of a finding

Here is a finding as it appears in a JSON report:

{
  "id": "9f2c4a1b8d3e6f70",
  "ruleId": "S001",
  "title": "Hardcoded credential detected",
  "description": "A credential-like value was detected.",
  "severity": "critical",
  "confidence": "high",
  "category": "secrets",
  "file": "config/example.env",
  "line": 12,
  "column": 5,
  "evidence": "API_KEY=[REDACTED]",
  "recommendation": "Move the credential to a secure secret store.",
  "references": [],
  "scanner": "secrets"
}

Field	What it means
ruleId	The rule that fired. The prefix names the scanner: S secrets, D dependencies, C source, I infrastructure, A API, SC smart contract
title, description	What was found and why it matters
severity	How bad it would be if it is real
confidence	How sure the scanner is that it found the real thing
file, line, column	Where it is, relative to the scanned folder. Line and column are left out when the finding is about a whole file
evidence	A short extract of the matching text. Secret values are always replaced with [REDACTED]
recommendation	What to do about it
references	Links to more reading, when the rule has any
id	A stable fingerprint of this finding

Severity

Severity is the impact if the finding is real.

Severity	Typical examples
critical	A committed live credential, a pattern equivalent to remote code execution, a smart contract that could be drained
high	A known-vulnerable dependency in use, an SQL injection pattern, a privileged container
medium	Weak cryptography, TLS verification turned off, permissive CORS
low	A hardening gap: missing resource limits, an unpinned image
info	An observation with no direct risk, for example a check that was skipped

Confidence

Confidence is separate from severity. It says how certain the detection is.

• high: the pattern is unambiguous, for example a token in a known vendor format.
• medium: the pattern is strong, but the surrounding code could make it legitimate.
• low: a heuristic, for example a random-looking string or a suggestive variable name.

A critical finding with low confidence deserves a look, but is more likely to be a false alarm than a critical finding with high confidence.

Qualifier

Findings from the API scanner also carry a qualifier: confirmed, likely or potential. An API definition file cannot always show whether a problem is real on the running service, so the qualifier says how strongly the finding is asserted. Markdown reports show it as Assertion.

The stable id

The id is a fingerprint built from the finding's redacted fields. The same problem in the same place gives the same id on every run. DL Sentinel uses it to remove duplicates, and baselines and suppressions use it to recognise a finding again later.

Decide what to do

1. Check it. Open the file at the line given and read the code around it. Decide whether the finding is real.

2. Fix real problems. Follow the recommendation. For a committed secret, deleting it from the file is not enough: revoke or rotate the credential with the service that issued it, because it stays in your Git history.

3. Suppress reviewed false alarms or accepted risks. Add a suppress entry to sentinel.yml with a reason and, ideally, an expiry date. See Configure scans.

4. Baseline old findings you cannot fix yet. A baseline lets you fail only on new problems while you work through the old ones. See Baselines.

A found secret is already exposed

If DL Sentinel finds a real credential in a repository that others can read, assume it has been seen. Revoke it and issue a new one, then remove it from the code.

Attack paths

Add --paths to a scan to group related findings into candidate attack chains, such as a committed cloud key next to a public storage bucket, or a privileged container that also uses the host network:

sentinel scan . --paths

The terminal and Markdown reports get an extra Attack paths section, and JSON reports get an attackPaths list. SARIF output is unchanged. Each path is built only from real findings in the report and is marked likely (the findings are linked by the same service or file) or potential (they only appear in the same repository). Paths are suggestions to review, never proof that something can be exploited, and they never change the exit code.

Next steps

• The scanners
• Configure scans
• Baselines