Severity Guide
Severity tells teams how quickly and with which controls they should respond to a Sentinel finding.
This page is not just a one-word priority label; it clarifies whether a finding blocks release, who owns it, and what counts as closure evidence.
CRITICAL — Critical
Remote code execution, model backdoor, credential exfiltration, or a finding that can become direct production compromise.
Recommended action: Quarantine the artifact, block promotion, rotate exposed credentials, and require owner sign-off before release.
Typical owner: Security lead, service owner, platform owner
HIGH — High
Dangerous deserialization, known exploitable CVE, structural tampering, or unsafe dynamic behavior.
Recommended action: Stop release until patched or isolated. Add a compensating control only when the owner accepts the residual risk.
Typical owner: AppSec, platform, affected engineering team
MEDIUM — Medium
Suspicious pattern, weak validation, unsafe default, or missing integrity control that needs engineering review.
Recommended action: Create a tracked remediation item, add validation or allowlists, and retest in the next scan.
Typical owner: Service owner or model release owner
LOW — Low
Minor misconfiguration, hygiene issue, or pattern that improves maintainability and review quality.
Recommended action: Fix opportunistically or fold into hardening work. Keep the signal visible in recurring reports.
Typical owner: Repository owner
INFO — Info
Metadata, inventory, size-limit notice, or best-practice reminder that does not imply a vulnerability by itself.
Recommended action: Use as context for triage, inventory, and policy tuning.
Typical owner: Security operations or platform team
Lowering severity requires more than explanation. A control must change: format migration, sandboxing, hash verification, egress restriction, secret rotation, or narrower tool permissions.