Finding

A Finding is one vulnerability or concrete security hardening note that an Assessment produces. Each finding is one unit of remediation work. A localized finding covers one proved instance. A systemic finding combines several distinct instances of one failed security control that share one 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 the assessment, AISafe uses the current severity for remediation and SLA tracking. It keeps the original AI rating and any 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 that the audit chooses and the triage step confirms. 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 still determines the remediation SLA.

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 when AISafe discovers them. The open status does not mean that AISafe has checked a submitted fix. After triage, findings move to confirmed. Fixed means AISafe verified the finding against one exact submitted source revision. You cannot set this status by declaring that the finding is fixed. 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 the issue remains. A finding that is not fixed 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. When you clear one of those dispositions, AISafe restores the latest technical result instead of assuming the finding is Open. If a disposition is applied after a verification starts, the disposition remains the visible status, but AISafe still records the completed technical result. When you clear the disposition later, AISafe shows that result with its original verification time. When you attach newer source, AISafe marks an older result as not current, but 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.

For historical dismissals without a recorded decision date, the one-year expiry starts from the finding's creation date. Recorded decision dates and inherited deadlines remain unchanged.

The finding detail page shows the latest source-verification verdict, the 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.

Ownership

A finding has at most one owner, assigned from the people who can see it. The row shows the owner's name as it was recorded at assignment time. If the person later changes their name, the organization still sees the name it saw when the finding was assigned.

Removing someone from the organization does not clear their assignments, because the record of who was responsible is part of the finding's history. Instead, AISafe marks that owner as no longer in the organization. The finding then appears effectively unassigned, while its history keeps the name. Reassign the finding to hand the work to someone who can act on it.

Evidence

Findings carry rich structured evidence:

• Whitebox evidence. One source location, its exact snippet, and analysis. This is the authoritative record of the source location. It contains selected code rather than a full transcript. Each block shows either a place where the code needs to change or the proof that the vulnerability is reachable. When AISafe writes the report, it can read the code around each range the assessment cited. It keeps the ranges a developer needs to act on and leaves out the rest, such as a handler that already performs the same check correctly, a constant that the fix reads but does not change, a README, or an import that only names code shown elsewhere. It can also narrow a wide range down to the lines that change. Expect two to four blocks on a finding, with the places to change first and the proof of reachability after them. Every finding has at least one place to change. AISafe shows overlapping citations of one region as one block. A finding that covers several instances of one failed control shows every instance, because each instance needs its own fix.
• Blackbox evidence. One request that the assessment actually sent. It includes the endpoint and the check it failed, the captured HTTP request and response in full, and a written explanation of the security behavior the target should have shown, what it returned instead, and why that difference proves this finding. A finding proved against a running system carries one entry per proved exchange; a finding confirmed both in source and against the live target carries whitebox and blackbox evidence together.
• 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.

A finding proved against your running system shows no proof of concept, because it does not need one. The assessment captured the request and the response as it sent and received them, and the blackbox evidence described above shows that capture exactly, header for header, together with the account used and the reasoning. AISafe uses a reconstructed exchange only where nothing was captured: in a code audit or a pull-request review. Code audits and pull-request reviews reason over source code and state that they do.

For code audits, the auditor must derive reproduction steps and proof-of-concept content from inspected source or a local reproduction. The triage step verifies the supplied evidence and the decisive premises. It does not fill in missing evidence for a candidate, and it does not invent locations, flows, reproduction steps, or proof-of-concept material. Candidates without enough proof are rejected. When AISafe writes the final report, it keeps approved reproduction and proof-of-concept material unchanged. Severity, finding category, and CWE remain separate fields. The human-readable vulnerability type is descriptive text in the report 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, steps to reproduce, proof of concept, blackbox evidence, 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 shows one piece of evidence at a time: its lines, highlighted, with a few lines of context on either side and an Expand control that reveals more around it. For whitebox evidence, you page between locations; for a taint flow, the viewer lists its steps beside the code. From the viewer you can open the same range in Code Explorer. When full source is unavailable, the viewer shows the stored snippet instead. Every taint flow has its own accessible selector. Blackbox cards show the request and response exactly as captured, with authentication headers redacted and long bodies marked where they were cut. AISafe never composes a request or a response it did not send or receive.

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 issues that AISafe agents promote from the assessment workflow, and each one is grounded in an exploit or a proof. AISafe treats an exact-version OSV match as an audit lead rather than a finding. The code audit must establish that the match applies and is reachable 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 duplicate candidates before triage. A duplicate is a candidate that reports a defect already found: the same root cause in the same code, even when it was described under a different weakness. The finding you read shows the source that the remaining candidate cited rather than every file that each duplicate mentioned. Two or more instances of one mechanism in different places, such as several handlers that each skip the same check, become one systemic finding. AISafe does not treat those instances as duplicates, and it shows every one of them. Triage verifies each instance; if fewer than two 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, GitLab, Jira, or Linear. The finding records each export attempt, tracking the issue number, URL, and status. After a successful export, Create issue becomes a link to the issue in that tracker. Existing tracker badges also link to the exported issue. See Integrations for setup details.

A dependency finding's full tracker body groups all advisory evidence by package, including installed and fixed versions. If the complete body is too large for the chosen destination, the preview asks you to select a summary with an evidence link. In the ticket, the summary names the sections it leaves out. Full exports do not silently omit advisories.

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.