Application security / DevSecOps
SecurePay / DevSecOps Pipeline
A synthetic payments API with tested security gates that distinguish scanner findings from failed or missing evidence.
Inspect the system
Inspect the policy, fixture replay, and retained scanner reports. The real scanner outcome is WARN/REVIEW; PASS belongs to the remediated demonstration fixture.
- Stack
- Python, Flask, Docker, and GitHub Actions.
- Workflow
- Raw evidence → validation → policy → remediation and review.
- Evidence scope
- Fixture replay and separately retained real scanner runs.
Overview
I built SecurePay to test the security gate itself: whether it detects a regression, recognizes remediation, and blocks when a required scanner fails. A small synthetic Flask payments API gives the delivery workflow a concrete application boundary.
Problem
A scanner returning no findings is useful only when its execution and coverage are valid. Missing artifacts, stale reports, and malformed output need explicit failure handling before a pipeline can make a review decision.
From change to review
- Application change
- Tests and scanners
- Raw evidence
- Validation and normalization
- Policy decision
- Remediation
- Human review
The offline CLI replays three committed states: a regression fixture returns BLOCK, its remediated fixture returns PASS, and missing scanner evidence returns BLOCK. It verifies these transitions without running scanners or installing vulnerable dependencies.
Architecture
Independent test, SAST, dependency, secrets, and configuration jobs run in parallel. The application image then supplies vulnerability, CycloneDX inventory, and local passive ZAP evidence. A Python policy layer checks reports and execution manifests before producing JSON, Markdown, and SARIF decisions. Missing, malformed, tampered, or failed required evidence blocks the gate.
Engineering decisions
- Separate scanner execution status from finding severity; an unavailable scanner cannot reuse a stale clean report.
- Keep scoped, justified, expiring exceptions visible for review. WARN/REVIEW remains an advisory successful check, with human approval and repository merge rules outside the evaluator.
Validation
September 7, 2026 CI at f6864cf passed 141 tests in each of three Ubuntu/Windows jobs. All eight security workflow jobs succeeded with a WARN/REVIEW decision. These are dated executions, not continuously renewed security results.
Separately retained scanner evidence at b8ccf34 records real image remediation that removed two blocking HIGH findings: BLOCK became WARN/REVIEW. The retained reports and SBOM keep remaining vulnerabilities and observed inventory inspectable.
Lessons / constraints
The API has no real payment processing, database, or authenticated identity. Passive ZAP covers local health-endpoint responses, not authenticated business flows. An SBOM describes observed inventory without proving completeness or exploitability. The completed lab demonstrates reproducible gate behavior; it does not establish production release approval, compliance, or absence of vulnerabilities.