Finding

A Finding is one vulnerability or observation that an Assessment produces. It is the unit of remediation. Each finding carries evidence, a severity, a lifecycle status, and a suggested fix. You triage findings, export them to your issue tracker, and track them to closure.

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.

Severity

The discovering agent assigns a severity, which the triage step 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	Observation worth surfacing but not a vulnerability

A confidence score (1–100) accompanies each severity, capturing the triager's certainty.

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.

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; SCA findings can inherit 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 → fixed
                 → false_positive
                 → accepted_risk
                 → duplicate

Findings start as open on discovery. After triage, they move to confirmed (a human validates the issue is real). Terminal states include fixed (the team has remediated and verified the vulnerability), false_positive (not a real vulnerability), accepted_risk (the team chooses to accept the risk), and duplicate (same root cause as another finding). Marking a finding as false positive, accepted risk, or duplicate requires providing a reason.

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:

• Locations. File, start/end line, and optional code snippet
• Whitebox evidence. Location plus optional taint flow, CWE, and analysis text
• 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
• Fix locations. File, lines, and optional suggested code with fix type (replace, insert, delete, wrap)

Additional context includes business impact, proof-of-concept (with language-tagged code blocks), steps to reproduce, CWE ID, OWASP category, and affected URL for blackbox findings.

Finding sources

Most findings are exploit- or proof-grounded issues promoted by AISafe agents from the assessment workflow. Code-shaped assessments can also produce SCA findings from OSV dependency advisories when the code graph contains an exact vulnerable dependency version. These findings carry finding_source="sca" and structured dependency evidence such as package URL, manifest or lockfile, direct/transitive status, advisory ID, fixed versions, and references.

SCA findings are first-class findings: they appear in severity rollups, reports, compliance mapping, exports, issue-sync, and the normal triage lifecycle. They are advisory-backed and presence-based, so AISafe does not claim runtime reachability or provide a fabricated proof of concept. Monitoring PoC replay does not enroll SCA findings; re-validation comes from re-scanning the dependency manifest on a later assessment. When a later exact-version scan no longer reports the advisory, AISafe carries the prior SCA finding forward as fixed so the resolution remains visible in finding lineage.

Deduplication

Findings auto-deduplicate during the triage stage. If the triage pass identifies a second instance of the same root cause, the triage pass marks it as duplicate and links it to the canonical finding.

For run-over-run tracking, GET /api/v1/projects/{id}/findings/recurring returns findings 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. The endpoint only includes findings from assessments the caller 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 via GET /api/v1/assessments/{id}/findings/export:

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 carry CWE and OWASP tags as rule properties so they ingest into security dashboards. 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 a hand-picked selection of findings via the finding_ids query parameter.

OpenVEX 0.2 exports are available with format=vex and use the media type application/vnd.openvex+json. Active 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. 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.