Inspect findings

Every finding carries the file, the line and the mechanism. Its remediation plan says what to change and how to test it.

A severity and a rule name tell you something is wrong. Fixing it needs the file, the line and the mechanism. Findings carry those. What to change, and how to test the change, is in the finding's remediation plan.

List a scan's findings

$ sentrasec finding list <SCAN-ID>

FINDING ID                              SEVERITY   RULE / CATEGORY         LOCATION89f6bb84-d79b-4caf-865d-87f0d7c146f5    critical   SAST-TAINT-CMDI         app.py:191e8f29fd-f137-490d-8a08-c02bf089f25b    high       SAST-PYTHON-SQLI-001    app.py:13

Narrow to what matters first:

$ sentrasec finding list <SCAN-ID> --severity high

Open one finding

$ sentrasec finding get <SCAN-ID> <FINDING-ID>

Prints the classification, the location, the snippet, why it matters and the technical mechanism.

Hand the remediation plan to an agent

Sentrasec writes a remediation plan and a test plan for a finding. It does not edit your code. Generate the plan from the finding's Remediation tab in the dashboard, then print it:

$ sentrasec remediation show <FINDING-ID>

The plan is prose, with no code or diff. Give it to your coding agent. The agent makes the change and runs the tests the test plan lists.

Check a fix

After the change, re-run the same scanner and compare. A finding that stops appearing shows the fix landed — lifecycle_status becomes fixed, and occurrence_count shows how many runs it survived.

$ sentrasec scan --kind sast --path .

Secrets need rotation, not just an edit

A committed credential is compromised the moment it reaches history. Removing it from the file is necessary but not sufficient: rotate it at its source, move it to an environment variable or a secrets manager, and remember it remains in git history. A secrets finding is not closed by an edit alone.

What a finding carries

Field	Meaning
`severity`	critical, high, medium, low or info.
`rule_id`	The rule that fired, e.g. SAST-TAINT-CMDI.
`file, line_start`	Where it is, for a code finding.
`url`	Where it is, for a DAST finding.
`snippet`	The offending line, redacted where needed.
`cwe, owasp`	Classification, for reporting and triage.
`business_impact`	What it means if exploited, in plain terms.
`technical_details`	The mechanism — how the input reaches the sink.
`confidence`	How sure the scanner is of the match.
`lifecycle_status`	open, fixed or reappeared, compared across runs.
`occurrence_count`	How many runs this finding has been seen in.

Use --format json on any of these commands for the full record. See the scanning guide for how to produce a scan in the first place.