Threat-Informed Security-Testing Strategy

Wrote docs/architecture/tasks/banking-sec-test-001/security-testing-strategy/security-testing-strategy.md. Complete threat-informed security testing strategy establishing multi-stage CI/CD security pipeline gates, OWASP ASVS Level 3 verification, test data anonymization, and red team validation.

---

skill: security-testing-strategy

Security-Testing Strategy: Core Banking Transaction Gateway [SECTEST-BANK-001]

Summary

This specification establishes the threat-informed security testing strategy, automated CI/CD verification pipeline, test environment architecture, and adversarial validation program for banking-transaction-gateway v3.0 under run ID banking-sec-test-001. It governs 80 backend microservices processing high-value cardholder transactions. It decisively eliminates the testing blind spots demonstrated in incident SEC-4935 (where reliance on annual penetration tests allowed an exploitable business logic flaw to persist in production for 22 days). The strategy enforces OWASP ASVS Level 3 controls, a multi-tier automated CI/CD gate structure (Secret Scanning, SAST, SCA, dynamic DAST), production-like isolated staging test environments with synthetic PII data masking, and scheduled biannual red-team adversary emulation.

Detailed Description

Relying on annual point-in-time penetration testing creates an indefensible 364-day vulnerability window between audits. Fast-moving development teams ship hundreds of code commits weekly, making automated shift-left security verification essential. A threat-informed testing strategy aligns automated CI test suites directly with known adversary techniques (MITRE ATT&CK) and enforces blocking gates before code merges to main branches.

Developer Pull Request (80 Microservices / 45 Daily Merges)
                            │
                            ▼
[ Stage 1: Commit & Pre-Merge CI Gates (GitHub Actions) ]
  ├── Secret Detection: Gitleaks (Hard Block on any exposed key)
  ├── Static Analysis (SAST): Semgrep (Blocking on High/Critical ASVS rules)
  └── Software Composition (SCA): Snyk (Blocking on Reachable CVEs >= 8.0)
                            │
                            ▼ (Ephemeral Staging Environment)
[ Stage 2: Dynamic & Integration Verification ]
  ├── Dynamic API Testing (DAST): OWASP ZAP (Fuzzing REST/gRPC contracts)
  ├── Identity & AuthZ Probes: Automated BOLA / Broken Object Level Auth Tests
  └── Test Data Masking: 100% Synthetic PII (Zero Production Card Data)
                            │
                            ▼
[ Stage 3: Periodic Adversarial Emulation ]
  └── Biannual Red Team Operations: MITRE ATT&CK Financial Threat Scenarios

Criteria and weights

Comparison

Result

Option C is selected. Multi-tier automated CI gates prevent regressions; synthetic test environments ensure compliance; red teaming tests holistic defense.

---

Required Mechanisms

1. Multi-Stage Testing Pipeline Taxonomy [MC-PT-01]

• Stage 1 (Pre-Commit / Pre-Merge):
  • Secret Detection: gitleaks detect --source=. --verbose (Execution time: < 10 seconds).
  • Static Application Security Testing (SAST): semgrep scan --config=p/owasp-top-ten (Execution time: < 90 seconds).
  • Software Composition Analysis (SCA): snyk test --severity-threshold=high (Execution time: < 60 seconds).
• Stage 2 (Staging Dynamic Testing):
  • Dynamic Application Security Testing (DAST): OWASP ZAP automated API vulnerability scans against staging endpoints.
  • Fuzz Testing: REST and gRPC schema fuzzing for unexpected buffer sizes and illegal Unicode sequences.

2. Threat-to-Test Mapping (MITRE ATT&CK / OWASP ASVS) [MC-TM-01]

3. Environment Fidelity & Test Data Anonymization [MC-ED-01]

Staging Environment Architecture: Identical topology to production (Kubernetes EKS, network security policies, and IAM roles).

• Synthetic Data Contract:
  • Direct copying of production customer databases to test environments is strictly prohibited.
  • All test records are synthesized using automated data generators (Faker / custom seed scripts).
  • Payment card numbers use official test ranges (e.g. Visa 4000-0000-0000-0002) that fail live financial authorization networks.

4. CI/CD Gate Thresholds & Waiver Governance [MC-GW-01]

• Blocking Thresholds:
  • Pull requests fail build if:
    1. Secret scanner finds any API key or token.
    2. SAST finds any CRITICAL or HIGH severity CWE.
    3. SCA finds any unpatched CRITICAL CVE with an available fix.
• Waiver Protocol:
  • Temporary risk acceptance requires cryptographic sign-off from David O'Reilly.
  • Maximum waiver validity: 14 calendar days.
  • All active waivers expire automatically, restoring the blocking CI gate.

---

Invariants and Contracts

Mandatory Pre-Merge Blocking Quality Gate [INV-SECTEST-01]
  Pull requests containing detected secrets or unpatched critical vulnerabilities must fail CI.
  Bypassing security checks via CI skip directives or administrator override is prohibited.

Zero Production PII in Test Environments [INV-SECTEST-02]
  Test, staging, and development databases must not ingest unmasked production customer records.
  All test datasets must be generated synthetically or scrubbed via certified tokenization.

Fourteen-Day Maximum Waiver Expiration [INV-SECTEST-03]
  Security scan waivers must not exceed 14 calendar days.
  Expired waivers automatically revert to blocking status in build pipelines.

Explicit Unknowns

• DAST scan execution duration overhead when testing 450 dynamic OpenAPI routes during nightly integration builds (G-1).
• Mock service latency variance during high-throughput fuzz testing against external payment processor emulators (G-2).

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against security testing standards:

• Shift-Left Automation: PASS. Multi-stage CI gates detect secrets, SAST, and SCA flaws pre-merge.
• Data Privacy: PASS. 100% synthetic test data eliminates production PII leakage.
• Threat Alignment: PASS. Test suites mapped directly to MITRE ATT&CK and OWASP ASVS Level 3.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-SECTEST-01: David O'Reilly to determine whether automated Interactive Application Security Testing (IAST) agents should be embedded into staging runtime pods (Owner: David O'Reilly).

Next steps

1. Marcus Vance provisions reusable GitHub Actions workflows containing Gitleaks, Semgrep, and Snyk scanners.
2. Quality Engineering deploys synthetic test data generation pipelines for staging database seeding.
3. Conduct staging dry run verifying pull request blocking on simulated vulnerable test repositories.