Knowledge · Application Security

SAST PoC Plan

A practical SAST PoC plan with roles, representative repositories, test scenarios, evidence capture, acceptance gates, schedule, and decision record.

Primary question: How can a team turn SAST evaluation requirements into an executable proof-of-concept plan with measurable acceptance criteria?

Definitions

SAST PoC plan

An executable evaluation document that assigns scope, environments, roles, test scenarios, evidence, schedule, scoring rules, and exit criteria for a candidate SAST product.

PoC acceptance gate

A pre-agreed condition that determines whether a candidate passes, fails, or requires an explicitly approved exception.

Test scenario

A repeatable action and expected evidence used to evaluate one or more requirements, such as scanning a representative repository or enforcing a pull-request policy.

The engineering problem

A vendor demonstration can show a successful path without testing representative scale, difficult frameworks, existing pipeline constraints, or routine analyst work.

Changing scanner configuration, code revisions, or scoring rules during the PoC makes candidate results difficult to compare.

Security controls

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

PoC charter

Evaluation boundary
Artifact
A one-page charter identifying the decision, candidates, in-scope requirements, repositories, environments, timeline, owners, exclusions, and permitted vendor assistance.
Risk
Allowing the evaluation scope to expand or change differently for each candidate.
Output
Approved and versioned PoC boundary.

Evidence:

Representative repository set

Evaluation corpus
Artifact
Version-pinned repositories covering important languages, frameworks, architectures, sizes, build patterns, and known operational difficulties, with handling rules for proprietary source.
Risk
Producing results that do not represent the organization's application portfolio.
Output
A documented repository set and source revision for every test.

Evidence: OWASP SAMM Security Testing

Scenario and evidence matrix

PoC test matrix
Artifact
A table with scenario ID, requirement, setup, action, expected evidence, actual evidence, owner, score, exception, and retest status.
Risk
Scoring impressions instead of repeatable observations.
Output
Comparable scenario records for each candidate.

Evidence: NIST Secure Software Development Framework

Acceptance and exit criteria

PoC decision gates
Artifact
Mandatory pass conditions, weighted score thresholds, permitted exceptions, stop conditions, unresolved-risk treatment, and final approvers.
Risk
Moving the decision threshold after results are known.
Output
A reviewable pass, conditional pass, or fail decision.

Evidence:

Verification workflow

  1. Approve the PoC charter and assign security, development, DevOps, infrastructure, procurement, and decision owners.
  2. Freeze candidate versions, configurations, repository commits, and infrastructure assumptions.
  3. Prepare test scenarios for installation, access control, representative scans, findings, CI/CD, exports, triage, suppression, rescans, upgrades, and recovery.
  4. Record expected evidence and acceptance rules before running each scenario.
  5. Execute the same scenario set for every candidate and log deviations.
  6. Validate known findings where ground truth exists and separately record newly discovered candidates for review.
  7. Measure scan operation and finding-review effort without presenting short PoC observations as long-term production cost.
  8. Review mandatory failures, weighted scores, exceptions, and unresolved risks.
  9. Archive the evidence package and signed decision record.

Limits of verification

  • A short PoC cannot establish long-term maintenance effort, support quality, rule evolution, or production-scale reliability.
  • Ground-truth quality limits the conclusions that can be drawn about detection accuracy.
  • Results are specific to the pinned repositories, versions, configuration, infrastructure, and test period.
  • This executable plan complements the broader SAST Proof of Concept methodology; it does not replace the organization's procurement process.

Canonical terms used: SAST PoC plan; SAST proof of concept plan; SAST PoC acceptance criteria; static analysis evaluation plan; SAST PoC test cases.

Evidence and references

  1. NIST Secure Software Development FrameworkThe SSDF describes code analysis, issue triage, remediation, evidence retention, and secure software practices suitable for evaluation scenarios.nist-ssdf
  2. OWASP SAMM Security TestingOWASP SAMM describes security testing maturity from baseline automated testing through integration into development and deployment.owasp-samm-security-testing
  3. DerScanner documentationDerScanner publishes documentation for static analysis, supported technologies, deployment, and integrations.derscanner-docs

Make the PoC reproducible

Test DerScanner against versioned repositories, explicit scenarios, and pre-agreed acceptance gates.

Share your shortlisted requirements and representative technology stack. The DerScanner team will help identify the documented setup inputs for a controlled evaluation.

Make the PoC reproducible

Plan your SAST PoC

Describe your repository set, evaluation timeline, and mandatory acceptance criteria.

Engineering knowledge for building and operating trustworthy systems.

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