Evidence

Evidence connects a Sentinel finding to a traceable repository location, scanner result, rule, summary, or timestamp. It is the basis for review, not a substitute for reviewer judgment. Scanner evidence references and source metadata are available. A universal confidence model, fixed retention period, immutable archive, and unrestricted export contract are not defined.

Evidence model

A useful evidence record tells the reviewer what produced the observation and where to inspect it. Depending on the current data source, evidence may reference a file path, rule identifier, scanner, summary, timestamp, or related finding field.

Evidence remains tied to the repository snapshot and scope used for the scan. If the code changes, a previously accurate reference can become stale. The product should not be described as proving that evidence still matches the latest branch unless the current record establishes that relationship.

Data provenance is part of the model. Store, demo, fixture, empty, and unsupported states are different. Demo and fixture evidence is product material, not customer scan evidence.

Sentinel evidence records the source context that supports a candidate finding. Evidence records can reference file paths, scanner or rule identifiers, summaries, and timestamps. Traceability lets a reviewer move from the finding to the supporting source or scanner result. Confidence reflects strength or reliability of support and must remain separate from severity.

Evidence records can reference file paths, scanner or rule identifiers, summaries, and timestamps; open the evidence reference from the finding and verify that it resolves to the expected authorized repository. Source snippets may contain sensitive repository content and should be exposed only to authorized reviewers; record uncertainty when the evidence is incomplete or the source has changed. Evidence supports a decision; it does not prove exploitability, business impact, or a universal remediation.

Export behavior is not established, and a visible evidence record should not be described as immutable; compare the cited file and rule context with the finding summary. Traceability lets a reviewer move from the finding to the supporting source or scanner result; restrict copied snippets to the minimum needed for review. Use evidence to support a decision, not to claim exploitability, business impact, or a universal remediation.

Source references

A source reference is most useful when it lets a reviewer return to the exact repository context that supports the finding. File path, rule or scanner identifier, safe code context, summary, and timestamp can provide that traceability when the record contains them. Preserve the relationship between the evidence and its finding rather than copying an isolated snippet into a separate note.

Repository evidence can expose secrets, personal data, or proprietary implementation details. Share only the minimum context needed for review and follow the approved repository-access boundary. No universal redaction, export, or retention mechanism is documented; external sharing therefore requires separate privacy and security review.

Open source references only within the authorized repository boundary. Confirm the path, relevant lines or context, scanner or rule, and timestamp when those details are available. A reference that points outside the approved repository or scope should trigger an intake review.

Source snippets can contain secrets, proprietary code, or personal information. Copy only what is necessary for authorized review and do not place sensitive content into public tickets or generic support logs.

References should resolve to authorized files, scanners, rules, summaries, or timestamps. Source snippets may contain sensitive repository content and should be exposed only to authorized reviewers. No fixed evidence-retention period is verified in the supplied sources. Export behavior is not established, and a visible evidence record should not be described as immutable.

Confidence reflects strength or reliability of support and must remain separate from severity; compare the cited file and rule context with the finding summary. Export behavior is not established, and a visible evidence record should not be described as immutable; restrict copied snippets to the minimum needed for review. Retention, deletion, export, and access-control guarantees require privacy and policy review beyond the supplied implementation.

Confidence

Confidence expresses how strongly the available references support the candidate finding. It should not be substituted for severity: a high-confidence low-impact issue and a low-confidence high-impact claim require different review decisions. No public confidence-scoring scale is documented. Use the recorded value as context and explain the underlying references instead of inventing thresholds.

Confidence describes the strength or reliability of support for the finding. It is not the same as severity, business impact, or exploitability. The evidence model does not establish a complete numeric scale or public confidence rubric.

Review confidence through the available evidence: how directly the source supports the claim, whether multiple references agree, whether the code context is complete, and whether the repository snapshot is current. Avoid converting those considerations into invented score thresholds.

Low confidence does not automatically make a finding harmless. High confidence does not automatically make it severe. Preserve the two dimensions so reviewers can reason about urgency and certainty independently.

Confidence describes evidentiary strength rather than issue severity. Data provenance can be store, demo, fixture, empty, or unsupported depending on the loader path. Record uncertainty when the evidence is incomplete or the source has changed. Restrict copied snippets to the minimum needed for review.

No fixed evidence-retention period is verified in the supplied sources; record uncertainty when the evidence is incomplete or the source has changed. Evidence records can reference file paths, scanner or rule identifiers, summaries, and timestamps; treat demo and fixture references as product examples rather than production security evidence.

Traceability

Traceability lets a reviewer move from the finding to the evidence and back to the authorized repository. Keep finding identifiers, source references, scanner or rule details, and safe timestamps connected when the product exposes them.

A traceable record should also reveal its provenance. Store-backed evidence can support an operational review, while demo or fixture evidence should be clearly labeled as example content. An empty state means no record is available; unsupported means the path cannot provide one.

Do not claim immutable lineage or complete auditability. The current implementation exposes references and loader behavior rather than a locked, immutable evidence ledger for audit purposes.

Traceability lets a reviewer move from a finding back to the relevant repository context. Treat demo and fixture references as product examples rather than production security evidence. Open the evidence reference from the finding and verify that it resolves to the expected authorized repository.

Data provenance can be store, demo, fixture, empty, or unsupported depending on the loader path; restrict copied snippets to the minimum needed for review. Confidence reflects strength or reliability of support and must remain separate from severity; open the evidence reference from the finding and verify that it resolves to the expected authorized repository.

Retention

No fixed retention or deletion period is verified for Sentinel evidence. Do not promise indefinite history, automatic expiry, legal hold, guaranteed deletion, or provider-side removal. Retention language must remain under privacy and policy review.

Repository evidence can be sensitive. Minimize copied snippets, limit access to authorized reviewers, and use organizational systems approved for security records when long-term preservation is required. The Sentinel page itself should not be described as the only durable record.

If evidence disappears, check data-source state and history before assuming tampering. The loader may be using an empty, demo, fixture, unsupported, or different store path.

No fixed retention or deletion period is verified for evidence records. Compare the cited file and rule context with the finding summary.

Traceability lets a reviewer move from the finding to the supporting source or scanner result; treat demo and fixture references as product examples rather than production security evidence. No fixed evidence-retention period is verified in the supplied sources; compare the cited file and rule context with the finding summary.

Review

Reviewers should be able to state what the reference proves and what remains inferred. If the cited file, rule, or code context is unavailable, mark the gap instead of upgrading confidence from the finding summary alone. Demo and fixture evidence must remain labeled throughout review.

Review evidence against the finding summary and affected files. Confirm that the rule or scanner observation is relevant, that the cited code is within scope, and that the conclusion does not rely on missing context.

When evidence is insufficient, record uncertainty rather than expanding into offensive validation. Sentinel does not authorize live-target testing, credential attempts, exploit automation, or destructive tests.

A final review should keep the finding, evidence, severity, confidence, classification, and status distinct. Those fields support a decision together; none of them alone proves a vulnerability or a completed remediation.

Evidence should be examined critically before a finding is accepted or rejected.

Source snippets may contain sensitive repository content and should be exposed only to authorized reviewers; open the evidence reference from the finding and verify that it resolves to the expected authorized repository. Data provenance can be store, demo, fixture, empty, or unsupported depending on the loader path; record uncertainty when the evidence is incomplete or the source has changed.