Finding

A Finding is one vulnerability or concrete security hardening note that an Assessment produces. It is the unit of remediation. A localized finding covers one proved instance. A systemic finding combines at least four distinct instances of one failed security control and one shared remediation.

Identity

Each finding has a system-wide unique public ID of the form AIS-{ORG}-{ASSESSMENT}-{NNN} (e.g. AIS-ACME-TLP-001). The final segment is the finding's position within its parent assessment. These IDs are immutable and appear in reports, CSV exports, issue tracker exports, and webhook payloads.

When AISafe can prove that findings from separate scans share the same underlying remediation root, the finding also carries a root_cause_fingerprint. Project-level recurring finding views use this key to group the same unresolved root cause across assessments while findings without a fingerprint remain separate singleton rows.

When you open a finding from an assessment, AISafe keeps the assessment in place and opens the finding as a quick view. The address changes to /assessments/{assessment-code}/findings/{NNN}, so you can copy it or use your browser's Back and Forward buttons. The close button returns to the assessment.

Severity

The audit records an initial severity estimate, which the triage step confirms or refines:

Severity	Meaning
Critical	Exploitable with severe impact (RCE, auth bypass, data breach)
High	Exploitable with significant impact, may require some prerequisites
Medium	Exploitable under specific conditions, moderate impact
Low	Limited impact or requires unlikely conditions
Info	Concrete, non-exploitable security hardening note; not an ordinary bug or dead-code cleanup item

When severity is adjusted after assessment, AISafe keeps the current severity as the remediation and SLA authority while preserving the original AI rating and later changes in the finding's severity history. Organizations may require a justification for human severity changes; those adjustments are also written to the audit log.

Code-audit findings always include a CWE chosen by audit and confirmed by triage. When AISafe has enough evidence, a finding also includes a structured CVSS Base assessment: version, vector, base score, base severity, and source. Native findings use PoC-grounded AISafe assessments; historical SCA findings can carry an advisory CVSS vector from OSV. AISafe leaves the CVSS field empty when the evidence is insufficient, and the displayed severity remains the remediation SLA authority.

Status lifecycle

Findings move through a defined lifecycle:

open ──────────────┐
  └→ confirmed ────┴─ verify source ─→ fixed ⇄ not_fixed
                                          re-verify

open | confirmed | fixed | not_fixed
  └→ false_positive | accepted_risk | duplicate

Findings start as open on discovery. Open does not claim that a submitted fix was checked. After triage, they move to confirmed. Fixed means AISafe verified the finding against one exact submitted source revision. Customers do not set it by assertion. A later verification rechecks fixed findings and records a regression as not fixed. Not fixed also records that AISafe checked an open finding against the submitted revision and proved that it remains. It stays active in finding counts, SLA tracking, reports, filters, and external issue sync. A user cannot reset either verification result to Open or Confirmed; a later verification can replace the technical result, while risk acceptance, false-positive, and duplicate dispositions remain available. Clearing one of those dispositions restores the latest technical result instead of assuming the finding is Open. If a disposition is applied after a verification starts, it remains the visible status, but AISafe still records the completed technical result. Clearing the disposition later reveals that result with its original verification time. Attaching newer source marks an older result as not current; it does not erase the last verified technical status. Other terminal states are false_positive, accepted_risk, and duplicate. Marking a finding as false positive, accepted risk, or duplicate requires a reason.

Finding detail shows the latest source-verification verdict, exact revision/ref, freshness for the current candidate, justification, evidence-by-evidence outcome, test observations, and prior verification history.

Some organizations require a second approver before a finding or suppression rule can land as accepted_risk. When that policy is enabled, the original triage action creates a pending approval request and the finding keeps its current status until an eligible reviewer approves it.

Evidence

Findings carry rich structured evidence:

• Whitebox evidence. One source location, its exact snippet, and analysis. This is the authoritative source-location record.
• Blackbox evidence. Target endpoint, test case, payload, expected vs actual behavior, and response artifacts
• Taint flows. Ordered source → propagator → sink chains from static taint analysis

Additional context includes impact, remediation, proof of concept, steps to reproduce, CWE ID, and an affected URL for blackbox findings. The proof of concept is Markdown that renders natively in the dashboard and PDF report, with language-tagged code blocks for payloads and scripts. Raw HTTP requests and responses use an http code block, with explicit http-request and http-response variants when needed.

For code audits, the auditor must derive reproduction steps and proof-of-concept content from inspected source or a local reproduction. Triage verifies the supplied evidence and decisive premises; it does not fill missing candidate evidence or invent locations, flows, reproduction steps, or proof-of-concept material. Candidates without enough proof are rejected. The final report-writing pass preserves approved reproduction and proof-of-concept material unchanged. Severity, finding category, and CWE remain separate fields. The human-readable vulnerability type is report prose and does not replace the CWE.

The detail page and human reports present non-empty sections in this order: metadata, description, impact, taint flows, impacted code, blackbox evidence, steps to reproduce, proof of concept, and remediation. A systemic finding is labelled Systemic · N instances. Findings do not show a confidence score, a separate Locations section, or review history. Review history remains available in the product audit trail.

The source-evidence viewer highlights every whitebox range and shows its analysis on hover, keyboard focus, or click. It can open the same range in Code Explorer and falls back to the stored snippet when full source is unavailable. Every taint flow has its own accessible selector. Blackbox cards show the typed test data as recorded; AISafe does not turn free-form artifacts into invented requests or responses.

PDF reports render taint flows as diagrams and label whitebox evidence Impacted Code. Each impacted-code block uses its file and line range as the heading and applies syntax highlighting. The API field remains whitebox_evidence.

Finding sources

Findings are exploit- or proof-grounded issues promoted by AISafe agents from the assessment workflow. Exact-version OSV matches are audit leads, not findings: the code audit must establish applicability and reachability before the result enters normal triage and promotion. Historical finding_source="sca" rows remain readable and exportable, but new scans do not promote package presence directly into that source type.

Deduplication

AISafe removes exact duplicate candidates before triage while preserving their combined evidence. Four or more distinct instances of the same failed security control can become one systemic finding when they also share one remediation. Triage verifies each instance; if fewer than four remain valid, AISafe reports or rejects the instances separately.

For run-over-run tracking, findings are grouped by root_cause_fingerprint. Each group includes its occurrence count, first detected time, last seen time, assessments seen in, displayed status, and whether the issue was fixed and later reintroduced. Groups only include findings from assessments you can access.

External issue tracking

You can export findings as issues to GitHub, Jira, or Linear. The finding records each export attempt, tracking the issue number, URL, and status. See Integrations for setup details.

If a newer finding has the same non-empty root_cause_fingerprint as an earlier export to the same provider and target, AISafe reuses the existing external issue record instead of creating a duplicate tracker ticket. Findings without a fingerprint keep the existing per-finding export behavior.

Bulk export

You can download findings in machine-readable formats:

Format	Use case
SARIF 2.1.0	Ingest into GitHub Code Scanning, GitLab security dashboard, DefectDojo, or SIEM
OpenVEX 0.2	Pair with SBOMs to show whether known vulnerabilities are affected, fixed, or not affected
JSON	Custom pipelines and integrations
CSV	Spreadsheets and reporting

SARIF exports derive physical locations from whitebox evidence and carry CWE and OWASP tags as rule properties. When a finding has CVSS, SARIF includes security-severity from the CVSS Base score and a machine-readable cvss property; JSON and CSV exports include the same CVSS vector fields. When a finding has a source-to-sink taint flow, the SARIF result includes codeFlows so code-scanning tools can show the ordered data path. SARIF exports exclude false positives by default. Set include_false_positives=true to keep them. You can narrow the export to selected findings with finding_ids.

JSON and CSV also preserve taint flows, whitebox evidence, and blackbox evidence. Source locations remain nested in whitebox evidence rather than appearing as a second standalone Locations field. Issues created through bulk tracker export use the same human section order as the dashboard and reports.

OpenVEX 0.2 exports are available with format=vex and use the media type application/vnd.openvex+json. Open, confirmed, and verified-not-fixed findings export as affected; fixed findings export as fixed; false positives export as not_affected; accepted risk stays affected; and duplicates are omitted in favor of their canonical finding. Unlike SARIF/JSON/CSV, OpenVEX includes false positives by default because the not_affected statement is the customer-facing evidence.

A compliance report is available via GET /api/v1/assessments/{id}/findings/compliance-report, mapping findings against OWASP Top 10, CWE, SOC 2, ISO 27001, and PCI-DSS side-by-side with an executive severity distribution and per-control remediation rollup. Its CSV keeps separate counts for Open, Confirmed, Not fixed, Fixed, Accepted risk, False positive, and Duplicate findings, while outstanding_findings totals the three active states. For per-framework audit evidence, GET /api/v1/findings/stats/compliance?framework=... and /export?format=csv|jsonl support pci_dss.v4, soc2.tsc, iso_27001.2022, and owasp_asvs.v4; export rows include mapping_confidence and a source_reference citing the relevant standard section.

SLA tracking

Findings carry severity-based remediation SLA windows, with per-organization configuration. AISafe raises a finding.sla_breached webhook event when a finding remains open past its SLA window, so your team can respond. You configure SLA windows under organization settings. A window of 0 days disables SLA tracking for that severity.