Knowledge · Application Security

SAST Severity and SLA Matrix

A configurable SAST severity and SLA matrix that separates scanner severity from business priority and defines deadlines, escalation, verification, and exception handling.

Primary question: How should an organization map SAST findings to remediation SLAs, escalation rules, and exceptions?

Definitions

Scanner severity

The tool-assigned estimate of technical seriousness for a finding under the scanner's rule model.

Remediation priority

The organization-assigned order for addressing a finding after considering technical impact, exposure, asset criticality, reachability, and policy.

Remediation SLA

The approved time boundary for reaching a defined finding state, measured from a documented start event and subject to explicit pause and exception rules.

The engineering problem

A severity-only deadline can over-prioritize unreachable findings while delaying lower-severity weaknesses in exposed or critical applications.

An SLA percentage is not reproducible when teams use different start dates, pause rules, closure states, or reopened-finding treatment.

Security controls

Each control inspects a different artifact and produces evidence for an engineering decision.

Context adjustment rubric

SAST priority rubric
Artifact
A scored or rule-based worksheet covering exposure, data sensitivity, application criticality, reachability, exploit prerequisites, compensating controls, and policy obligations.
Risk
Priority changes depend on undocumented analyst judgment.
Output
A contextual priority with the factors and approver recorded.

Evidence: NIST Secure Software Development Framework

Configurable SLA matrix

SAST remediation SLA table
Artifact
A table with priority bands as rows and columns for example target window, start event, target state, escalation cadence, verification, and executive exception authority.
Risk
Deadline reporting appears precise while teams apply incompatible definitions.
Output
One approved policy table implemented consistently in workflow systems.

Evidence: OWASP DevSecOps Guideline

Starter policy artifact

Illustrative SLA matrix
Artifact
Critical: organization-defined shortest window and immediate ownership; High: next-shortest window and weekly review; Medium: planned release window; Low: backlog or risk-based window. Replace all windows with approved calendar or business-day values.
Risk
Copying arbitrary industry deadlines without considering organizational risk tolerance or remediation capacity.
Output
A workshop-ready matrix whose timing fields are intentionally marked for local approval.

Evidence:

Exception and breach register

SLA governance register
Artifact
A record of extensions, accepted risks, blocked fixes, compensating controls, expiry dates, breach reasons, owners, and approvals.
Risk
Exceptions become permanent or SLA performance improves by administratively closing unresolved risk.
Output
Reviewable exceptions and attributable breach causes.

Evidence: NIST Secure Software Development Framework

Verification workflow

  1. Define the finding event that starts the clock, such as triage confirmation or initial report.
  2. Define target states separately for remediation complete, fix verified, risk accepted, and false-positive rejection.
  3. Select calendar days or business days and document timezone, pause, reopening, and inherited-finding rules.
  4. Preserve the scanner severity and rule metadata.
  5. Apply the approved context rubric to derive remediation priority.
  6. Assign an engineering owner and escalation owner when the SLA starts.
  7. Track elapsed and paused time from immutable workflow timestamps.
  8. Require verification evidence before counting a remediated finding as complete.
  9. Route extensions through the exception register with an expiry and named approver.
  10. Review breaches by cause and adjust capacity, workflow, or policy without rewriting historical results.

Limits of verification

  • No universal remediation deadline fits every organization, application, weakness, or regulatory environment.
  • Scanner severity and generic weakness ratings do not by themselves establish exploitability or business impact.
  • A fast closure metric can conceal accepted risk, duplicate closures, or inadequate verification unless states are reported separately.
  • Context rubrics can create false precision; retain analyst reasoning and permit controlled escalation.
  • This matrix is engineering governance guidance, not legal or regulatory advice.

Canonical terms used: SAST severity matrix; SAST remediation SLA; vulnerability remediation deadline; SAST priority rubric; finding SLA policy.

Evidence and references

  1. NIST Secure Software Development FrameworkThe SSDF describes identifying, recording, tracking, prioritizing, and remediating vulnerabilities using risk-based processes.nist-ssdf
  2. OWASP DevSecOps GuidelineThe guideline addresses security activities, testing, and feedback within software delivery processes.owasp-devsecops
  3. OWASP SAMM Security TestingOWASP SAMM frames security testing as a repeatable practice that can be scaled and integrated with development.owasp-samm-security-testing
  4. DerScanner documentationDerScanner publishes product documentation for evaluators and implementers.derscanner-docs

Define measurable remediation policy

Establish priority factors, timing boundaries, escalation, verification, and exception evidence.

Test the matrix against historical findings before using it for compliance or performance reporting.

Define measurable remediation policy

Review your severity and SLA model

Describe your applications, current severity policy, workflow states, and remediation reporting needs.

Engineering knowledge for building and operating trustworthy systems.

DerSecur Recognition · build ff420a3 · 2026-08-17 14:15:22Z · system