Findings

A Sentinel finding is a candidate or reviewed security issue linked to affected files and supporting evidence. The current loaders work with CandidateFinding records and may return durable records or demo data depending on the environment. Reviewers must keep severity, confidence, classification, and status separate. A complete severity rubric, confidence scale, suppression workflow, and durable status-mutation contract are not yet verified.

Finding structure

Use the fields independently. The finding ID identifies the record; the title and summary describe the suspected issue; affected files locate the relevant code; evidence references connect the claim to scanner or source material; severity communicates recorded impact; classification captures review interpretation. Created time describes the record, not necessarily the moment the underlying code was introduced.

A data-source label is essential when demo or fixture records are available. Store-backed findings may correspond to an executed supported scan, while demo and fixture records exist to exercise the interface. The same visual layout does not make those records equivalent.

A candidate finding can include an identifier, title, severity, summary, affected files, evidence references, creation time, and classification. These fields help a reviewer understand what was detected, where it appears, and why the scanner or analysis considered it relevant.

The exact schema remains under review. Do not invent required fields, remediation states, ownership, deadlines, or a complete API object from the loader summary alone. Always check whether the record is store-backed or demo-backed before using it in a repository report.

A candidate finding combines a concise issue description with affected files and evidence references. Candidate findings can include an ID, title, severity, summary, affected files, evidence references, creation time, and classification. Findings may load from durable records or fall back to demo data in demo environments. A severity label communicates potential impact or urgency but is not the same as confidence in the detection.

Candidate findings can include an ID, title, severity, summary, affected files, evidence references, creation time, and classification; confirm the data-source label before treating a finding as a customer scan result. Classification describes review interpretation and should not be collapsed into status; evaluate severity and confidence independently. Demo findings are examples and must not be reported as vulnerabilities in a real repository.

The exact field schema and allowed status transitions require review against modules outside the supplied bundle; read the summary and affected files, then follow the evidence reference to the relevant code or scanner output. Findings may load from durable records or fall back to demo data in demo environments; record a review conclusion only through controls whose persistence is verified in the current environment. Treat demo findings as examples, never as vulnerabilities in a real repository.

Severity

Severity communicates the potential impact or urgency of a candidate issue. It does not measure how certain the detector is, whether the issue is exploitable, or whether the affected code is reachable in production. Those questions belong to evidence and human review.

The finding contract does not define a complete public severity rubric. Avoid publishing fixed mappings between labels and business impact. When a severity appears, describe it as the value recorded by the current finding and review it against the code context.

A high-severity demo finding is still demo data. A low-severity store-backed finding can still matter to the repository owner. Provenance and evidence should guide the review alongside the label.

Severity communicates potential impact and must not be confused with detection confidence. Classification describes review interpretation and should not be collapsed into status. Evidence references should identify the scanner, file, rule, summary, or timestamp that supports the candidate issue. The exact field schema and allowed status transitions require review against modules outside the supplied bundle.

A severity label communicates potential impact or urgency but is not the same as confidence in the detection; read the summary and affected files, then follow the evidence reference to the relevant code or scanner output. The exact field schema and allowed status transitions require review against modules outside the supplied bundle; record a review conclusion only through controls whose persistence is verified in the current environment. A candidate finding is not proof of exploitability, and Sentinel does not authorize offensive validation.

Evidence

Evidence references connect the finding to files, scanner or rule identifiers, summaries, and timestamps. Open the evidence and verify that it belongs to the authorized repository and scope. Compare the cited source with the finding summary rather than accepting the title alone.

Evidence can be incomplete or stale when code changes. Record uncertainty when the cited context no longer matches the repository snapshot. Do not perform live-target testing or credential use to strengthen a finding. Sentinel’s supported boundary is repository-focused and read-only.

Confidence is not severity. A potentially serious issue can have weak evidence, while a well-supported observation can have limited impact. Keep those dimensions separate in review notes.

Evidence provides the traceable support needed to assess a candidate issue. False-positive handling can be described as review classification, but persistent suppression is not verified. Record a review conclusion only through controls whose persistence is verified in the current environment. When a candidate is not applicable, describe the reasoning without promising durable suppression.

Evidence references should identify the scanner, file, rule, summary, or timestamp that supports the candidate issue; evaluate severity and confidence independently. Candidate findings can include an ID, title, severity, summary, affected files, evidence references, creation time, and classification; when a candidate is not applicable, describe the reasoning without promising durable suppression.

Status

Status describes where the record sits in the review process; it is not a statement of exploitability or business impact. A candidate can remain open while evidence is incomplete, and a reviewed classification can change without altering the stored severity. Because the complete mutation contract is not verified, describe only the status value and transition behavior demonstrated by the current environment.

Status represents where a finding is in the review process. Allowed values, state transitions, permissions, and persistence guarantees require further implementation review. A visible status control is therefore not enough to claim that a change survives reloads or is enforced across environments.

Use status only as shown by the current record and product. When persistence is uncertain, document the reviewer’s conclusion separately through the organization’s established process. Do not invent states such as resolved, accepted risk, suppressed, or reopened unless the current source defines them.

Status also remains separate from classification. Classification expresses what the reviewer believes the finding represents; status expresses workflow position.

Status represents review state, but the complete mutation contract is not established. Treat a finding as a customer scan result only after checking its data-source label. Read the summary and affected files, then follow the evidence reference to the relevant code or scanner output.

False-positive handling can be described as review classification, but persistent suppression is not verified; record a review conclusion only through controls whose persistence is verified in the current environment. A severity label communicates potential impact or urgency but is not the same as confidence in the detection; confirm the data-source label.

Triage

Triage compares the finding summary, affected code, severity, evidence, classification, and source provenance. Start by confirming whether the record came from a store or demo fallback. Demo records are examples and must not be reported as vulnerabilities in the selected repository.

Review the affected files and evidence within the authorized scope. Determine whether the issue is applicable to the code, whether the evidence supports the claim, and whether additional defensive review is needed. Sentinel does not authorize exploit execution or live-target validation.

Prioritization should consider potential impact and repository context, not only the severity label. Assignment, comments, notifications, and durable status changes remain separate collaboration questions.

Triage compares code context, impact, evidence, and classification before reaching a conclusion.

Findings may load from durable records or fall back to demo data in demo environments; when a candidate is not applicable, describe the reasoning without promising durable suppression. Evidence references should identify the scanner, file, rule, summary, or timestamp that supports the candidate issue; read the summary and affected files, then follow the evidence reference to the relevant code or scanner output.

False positives

A false-positive decision should explain which evidence or code context changed the reviewer’s interpretation. A durable suppression list, automatic rule tuning, and propagation to later scans are not verified. Treat the classification as a review outcome for the current record unless persistence is demonstrated.

A false positive is a candidate finding that does not apply after review. Explain the reason using repository context and evidence. For example, the cited pattern may be unreachable, protected by another control, generated code, or misclassified by the rule.

Durable suppression and rule-tuning behavior are not verified by the current finding sources. Do not promise that marking a finding will prevent similar results in future scans. Preserve enough review context for the organization to understand the decision, while avoiding unnecessary sensitive snippets.

A false-positive conclusion should not be based only on inconvenience or lack of time. Review the evidence, affected path, and intended behavior. When uncertainty remains, classify the record cautiously and use an approved security-review process outside Sentinel for further analysis.

A reviewer can explain why a candidate is not applicable without claiming durable suppression.

Classification describes review interpretation and should not be collapsed into status; confirm the data-source label before treating a finding as a customer scan result. False-positive handling can be described as review classification, but persistent suppression is not verified; evaluate severity and confidence independently.