This page is part of the ForgeSDLC knowledge base — an AI-assisted, human-directed methodology for taking product work from concept to production. For the core operating model and vocabulary, see Forge SDLC overview and What is ForgeSDLC?.

Security testing — strategy and implementation

Purpose: A project-agnostic blueprint for layering automated and manual security testing so vulnerabilities are found before attackers exploit them.

Audience: Engineers, DevSecOps, and security teams designing CI/CD gates, toolchains, and remediation workflows.

Overview

Security testing is not a single scan at the end of a release. It is a layered program: fast, broad checks run continuously; deeper, manual work targets high-risk areas. The goal is signal over noise — tuned rules, triage discipline, and tracked fixes — so teams trust the process enough to act on findings.

Security test pyramid

Interpretation: SAST and SCA scale across every commit; DAST (and IAST, see below) validates running behavior; pen tests and red team exercises stress real-world creativity and detection/response.

SAST (static application security testing)

How it works: Analyzes source or bytecode without execution, matching code patterns and data flows to rules for issues like injection, unsafe crypto, and hard-coded secrets.

Rule sets: Language-specific; often OWASP/CWE-oriented; customizable for frameworks.

Integration: IDE (fast feedback), PR checks (shift-left), full-repo CI (coverage).

False positives: Tune rules, suppress with justification, prioritize reachable paths, and feed back to rule owners.

SCA (software composition analysis)

How it works: Inspects manifests and lockfiles (and sometimes binaries) to map dependencies to known vulnerabilities and licenses.

Outputs: Vulnerability reports, license compliance flags, SBOM (CycloneDX, SPDX) for audits and incident response.

Databases: NVD, OSV, GitHub Security Advisories, vendor feeds.

DAST (dynamic application security testing)

How it works: Sends requests to a running application to find issues like XSS, injection, and misconfigurations visible at the HTTP layer.

Authentication: Use test accounts, token injection, or scripted login; avoid production credentials.

CI: Run against ephemeral staging with seeded data; gate on severity thresholds after baseline tuning.

IAST (interactive application security testing)

How it works: Instruments the running app (agent) to observe real execution paths, taint propagation, and sink hits — bridging static and dynamic views.

Advantages vs SAST + DAST alone: Fewer false positives on reachable issues; insight into runtime context (frameworks, serializers).

Limitations: Agent overhead; language/runtime support; needs meaningful test traffic (quality of tests drives coverage).

Security testing in CI/CD

Gates should use severity + exploitability + context (not raw counts alone) after a baseline period.

Penetration testing

Comparison matrix: techniques

Container and infrastructure scanning

Vulnerability management lifecycle

1. Discover — scanners, pen tests, bug bounty, threat intel
2. Triage — valid vs false positive, affected assets
3. Prioritize — CVSS + exploitability + business context
4. Remediate — patch, config, compensating control
5. Verify — retest, regression tests
6. Close — record rationale and residual risk

Vulnerability triage decision tree

Metrics

Anti-patterns

External references

• OWASP Web Security Testing Guide
• OWASP SAMM (security assurance maturity)
• NIST SP 800-115 (technical security testing)
• Semgrep documentation
• Snyk Learn

Keep project-specific security documentation in docs/security/, threat models in docs/security/threat-models/, and security decisions in docs/adr/, not in this file.