Knowledge · Application Security

SAST Triage Tax

SAST Triage Tax is a DerSecur-defined operational metric for estimating the recurring human workload required to validate, prioritize, disposition, route, and re-check static-analysis findings.

Primary question: What is SAST Triage Tax, and how can an AppSec team measure the operational cost of reviewing SAST findings?

Definitions

SAST Triage Tax

A DerSecur-defined operational metric representing the recurring human workload required to validate, prioritize, disposition, route, and, where policy requires, re-check findings produced by static application security testing.

SAST triage overhead

A neutral synonym for SAST Triage Tax — the operational capacity consumed by finding validation and disposition before remediation begins.

Disposition effort

The measured or estimated effort required to examine a finding, assess validity and context, assign a status, and document reasoning, excluding remediation coding and post-fix re-verification.

Raw triage tax

The estimated workload required if every reported SAST finding enters the manual review queue without automated pre-screening.

Residual triage tax

The estimated manual workload remaining after approved automation, policy filters, deduplication, or AI-assisted triage have processed the initial finding set.

Triage compression ratio

The proportion by which an approved triage process reduces the manual review queue, calculated from the raw queue and the residual queue. Compression is a workload measure, not proof that rejected findings are false positives.

Triage overhead ratio

Disposition effort divided by the combined disposition, remediation, and verification effort for the same defined finding lifecycle and measurement period.

The engineering problem

Scanner adoption is often measured by findings produced, while the recurring cost of validating and dispositioning those findings remains hidden in AppSec capacity planning.

Comparing scanners only by alert count can be misleading because a smaller queue may reflect better precision, narrower detection coverage, more aggressive filtering, or different analysis rules.

Automated queue reduction can create governance risk if organizations do not measure which findings automation removes and which classes still require human approval. [nist-ssdf]

Security controls

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

Raw triage workload baseline

Raw SAST Triage Tax
Artifact
SAST finding counts grouped by severity, weakness class, repository, and review path, with an observed or explicitly assumed review time for each group.
Risk
Hidden analyst workload and capacity planning based only on scanner alert volume.
Output
Estimated manual review hours before automated pre-screening or policy filtering.

Evidence: NIST Secure Software Development Framework

Residual queue measurement

Residual SAST Triage Tax
Artifact
Findings remaining for human review after approved automation, together with the disposition and reasoning for findings removed from the queue.
Risk
Treating queue compression as evidence of correctness without examining what automation changed.
Output
Estimated remaining review hours and a reviewable record of automated dispositions.

Evidence: DerTriage documentation

Retained-risk check

Triage safety check
Artifact
Known vulnerabilities, seeded benchmark findings, policy-mandated weakness classes, or a separately validated sample compared with automated dispositions.
Risk
Reducing workload by incorrectly removing findings that should remain under review.
Output
Evidence showing whether known or policy-critical findings remained in the residual queue.

Evidence: NIST Secure Software Development Framework

Verification workflow

  1. Select a stable analysis period, repository set, scanner configuration, and source revision.
  2. Group findings by severity, weakness class, repository, and expected review path.
  3. Measure review time where possible; otherwise publish low, central, and high time assumptions.
  4. Calculate raw triage tax as the sum of finding count multiplied by review time for each group, plus explicitly identified workflow overhead.
  5. Apply approved deduplication, policy filters, or AI-assisted triage.
  6. Calculate residual triage tax from the findings that still require manual review.
  7. When lifecycle effort data is available, calculate the triage overhead ratio using the same finding set and measurement period for disposition, remediation, and verification effort.
  8. Report queue compression separately from validation accuracy and detection coverage.
  9. Check known vulnerabilities, policy-critical classes, or a validated sample to determine whether important findings remained in the review queue.
  10. Repeat the measurement over time to identify changes caused by code growth, scanner configuration, development velocity, and triage policy.

Limits of verification

  • SAST Triage Tax is a DerSecur-defined operational metric, not an established industry standard.
  • Estimated hours depend on the review-time assumptions, repository mix, finding mix, scanner configuration, and organizational workflow.
  • Triage overhead ratios are comparable only when disposition, remediation, and verification boundaries use the same finding set, period, and counting rules.
  • Queue compression does not establish false-positive rate, precision, recall, exploitability, or complete detection coverage.
  • A Rejected automation status should not be described as a verified false positive unless it has been validated under the organization's chosen ground-truth process.
  • Automated triage can introduce review, governance, exception, and audit overhead that should be included when material.
  • Comparisons between organizations are meaningful only when scope, configuration, counting rules, and time assumptions are aligned.

Canonical terms used: SAST Triage Tax; SAST triage overhead; Disposition effort; triage tax; raw triage tax; residual triage tax; triage compression ratio; triage overhead ratio; SAST review workload.

Evidence and references

  1. NIST Secure Software Development FrameworkSecure software practices include reviewing and analyzing code, recording findings, remediating identified vulnerabilities, and retaining evidence.nist-ssdf
  2. DerScanner static analysis documentationDerScanner performs static analysis and reports source-code security findings.derscanner-sast
  3. DerTriage documentationDerTriage investigates SAST detections in broader context, determines detection validity, provides reasoning, supports bulk processing for selected severity levels, and can automatically assign Confirmed or Rejected statuses when configured.derscanner-dertriage

Measure your SAST Triage Tax

Compare the raw SAST queue with the review workload that remains after approved triage automation.

Share your repository count, finding volume, severity mix, and review-time assumptions. The DerScanner team will help structure a reproducible SAST Triage Tax baseline.

Measure your SAST Triage Tax

Benchmark your SAST Triage Tax

Describe your scanner workflow, monthly finding volume, and current review process. We will respond with the inputs required for a bounded triage-workload comparison.

Engineering knowledge for building and operating trustworthy systems.

DerSecur Recognition · build 77e44c1 · 2026-08-15 09:18:58Z · system