Reports and findings

Every scan in every pillar produces a named Security Report. This page explains how to read a report, work on findings, export evidence and use AI to triage and fix.

#The Reports list

Results → Reports lists every report with its pillar, asset, state and time. A running report shows its current stage, each scanner's state and the elapsed time, and refreshes itself. States are explained in Repository scans; the same words are used in every pillar.

A partial report means some checks did not complete. The coverage section names each one and the reason (timed out, not applicable, unavailable, unsupported, prerequisite missing). Missing coverage is never shown as clean.

#Report tabs

Resilience reports have their own tabs: Test Run, Application Behaviour and Signed Evidence.

#A finding

A finding opens to its location (file and line, URL, cloud resource), evidence, severity, scanner and rule, exploit context (CISA KEV and EPSS for dependencies, reachability level), and fix guidance. The same issue found by two scanners is merged into one finding with "N locations agree".

#Finding states

Example: assign a finding and mark it fixed through the API (scope findings:write):

curl -sS -X PATCH "$DVSENTRY_URL/v1/security-reports/$REPORT_ID/findings/$DEDUPE_KEY" \
  -H "Authorization: Bearer $DVSENTRY_TOKEN" -H "Content-Type: application/json" \
  -d '{"workflow_status":"fixed","assignee":"dev@acme.example","workflow_note":"Bumped lodash to 4.17.21"}'

Setting accepted_risk or suppressed directly answers 422: request an exception instead.

#Security Regression

The regression tab compares a report with the previous completed report of the same asset (same repository and branch, target or cloud account): new, fixed, reopened and unchanged findings. When nothing is new it says "no new findings since scan X" and names that scan, rather than showing an empty table. API: GET /v1/security-reports/{id}/regression and GET /v1/repositories/{id}/regression.

#AI triage and AI remediation

Two different AI helpers live on the AI Remediation tab. They are coloured differently on screen (triage amber, remediation green) so they are never confused.

Both use the same provider choice:

• Managed AI (Cloud & AI and above): DVSentry's own provider key, no key needed. Each call uses one unit of the plan's monthly managed_ai_calls allowance, shown on Billing.
• Bring your own key: OpenAI, Google Gemini, GroqCloud, Anthropic, an OpenAI-compatible endpoint or Ollama. Paste the key for one request or pick a Secret Vault entry. Calls go from DVSentry to that provider under your account and its data terms.

#Risk inbox

Results → Risk inbox (Governance plan and above) is one prioritised list of open issues across all pillars plus active cloud threat detections. Each row has an owner (the assignee, else the asset owner an Admin named, else the repository's team) and a due date from the remediation SLA. It is a working view; it never changes report scores or gates.

#Exports

From a report's export menu, or through the API (scope reports:export):

curl -sS -o report.sarif -H "Authorization: Bearer $DVSENTRY_TOKEN" \
  "$DVSENTRY_URL/v1/security-reports/$REPORT_ID/export?format=sarif"
curl -sS -o sbom.cdx.json -H "Authorization: Bearer $DVSENTRY_TOKEN" \
  "$DVSENTRY_URL/v1/security-reports/$REPORT_ID/sbom?format=cyclonedx"

Signed evidence. GET /v1/security-reports/{id}/signed-evidence and the evidence pack are signed with DVSentry's Ed25519 key, so an auditor can verify them without trusting DVSentry. Large exports run as export jobs (POST /v1/export-jobs) and are downloaded from artifacts.

#Notifications about reports

Finished scans, new or reopened findings and blocked release gates can be sent to email, Slack, Teams or a signed webhook: see Notifications and integrations.

Something missing or unclear? Tell us with Feedback in the app.