Knowledge · Application Security

SAST Triage Playbook

A practical SAST triage playbook with queue gates, disposition criteria, escalation rules, evidence fields, and operating metrics.

Primary question: How should an AppSec team review, disposition, route, and audit SAST findings?

Definitions

SAST triage

The process of validating a static-analysis finding, adding application context, assigning a disposition and priority, and routing the resulting work.

Disposition

A recorded decision such as confirmed, rejected with rationale, accepted risk, duplicate, mitigated by context, or needs investigation.

Triage record

The evidence, reasoning, ownership, timestamps, and status history retained for a finding decision.

The engineering problem

Unstructured triage creates inconsistent decisions across analysts and repositories, making backlog and risk reports difficult to interpret.

Closing findings without retained reasoning prevents later review when code, threat context, policy, or scanner rules change. [nist-ssdf]

Security controls

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

Intake quality gate

Triage intake checklist
Artifact
A required-field checklist covering repository, revision, rule, weakness class, source location, trace, scanner severity, scan configuration, and finding identity.
Risk
Analysts spend time reconstructing missing scan context or disposition the wrong source revision.
Output
A review-ready finding or a documented request for missing evidence.

Evidence: OWASP SAMM Security Testing

Disposition decision table

SAST disposition matrix
Artifact
A table with rows for confirmed, rejected, accepted risk, duplicate, contextual mitigation, and needs investigation; columns define required evidence, approver, expiry, and next action.
Risk
Equivalent findings receive different outcomes without a defensible reason.
Output
A consistent status with rationale and ownership.

Evidence: NIST Secure Software Development Framework

Escalation and sampling rule

Triage assurance rule
Artifact
Criteria for escalating critical impact, uncertain data flows, disputed decisions, expired exceptions, and a periodic sample of closed findings.
Risk
Incorrect closures remain undetected and repeated process defects accumulate.
Output
Second-review decisions and sampled quality results.

Evidence: OWASP DevSecOps Guideline

Queue operations board

Triage queue dashboard
Artifact
Weekly counts for new, reviewed, escalated, reopened, aged, and routed findings, segmented by repository and severity.
Risk
Queue growth and stalled ownership remain hidden behind aggregate scan totals.
Output
Capacity and aging signals for the AppSec operating review.

Evidence:

Verification workflow

  1. Confirm the finding belongs to the intended repository, revision, branch, and scan policy.
  2. Review the rule, weakness class, source and sink, trace, code context, and configuration evidence.
  3. Determine technical validity without using business priority as a substitute for validity.
  4. Assess impact, exposure, reachability, existing controls, asset criticality, and policy obligations.
  5. Assign a disposition using the decision table and retain evidence and reasoning.
  6. Derive remediation priority from impact and application context; preserve the original scanner severity.
  7. Route confirmed work to an accountable engineering owner with the applicable SLA.
  8. Escalate uncertain, high-impact, disputed, or policy-exception cases to the named reviewer.
  9. Recheck remediated findings against the relevant source revision and record the result.
  10. Sample closed findings and review queue aging on a fixed cadence.

Limits of verification

  • This playbook does not determine whether a finding is exploitable and does not replace application-specific threat analysis.
  • Scanner severity is an input, not a complete business-risk assessment.
  • Review sampling can detect some process errors but cannot establish that all closed findings are correct.
  • Disposition labels must be mapped to the actual scanner, ticketing system, exception policy, and regulatory obligations.
  • Automated triage requires separate validation, approval boundaries, audit records, and fallback procedures.

Canonical terms used: SAST triage playbook; SAST finding disposition; SAST triage workflow; SAST finding review; SAST triage checklist.

Evidence and references

  1. NIST Secure Software Development FrameworkThe SSDF addresses identifying, recording, tracking, and remediating software vulnerabilities and retaining information about discovered issues.nist-ssdf
  2. OWASP SAMM Security TestingOWASP SAMM describes repeatable security testing, integrated results, and risk-based testing practices.owasp-samm-security-testing
  3. OWASP DevSecOps GuidelineThe guideline describes integrating security testing and feedback into delivery workflows.owasp-devsecops
  4. DerScanner documentationDerScanner publishes documentation for its capabilities and workflows.derscanner-docs

Establish a reviewable triage process

Define the evidence, decisions, ownership, and escalation required for each SAST finding.

Use representative findings to validate the playbook before applying it across the application portfolio.

Establish a reviewable triage process

Review your SAST triage model

Describe your finding volume, review roles, disposition policy, and ticketing workflow.

Engineering knowledge for building and operating trustworthy systems.

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