| name | sprint-security-review |
| description | Prepares sprint review and retrospective materials that demonstrate security alongside features: green build reports aggregating SAST/DAST/dependency scan results, completed security story summaries, and security metrics trends. Triggers on: "prepare sprint review", "green build report", "security metrics for this sprint", "demo our security work", "sprint security summary", "retro on our pipeline".
|
| license | MIT |
| metadata | {"author":"Community","version":"1.0.0","category":"secure-sdlc"} |
Sprint Security Review
Make security work visible in the sprint review instead of invisible plumbing. Produce a report that lets the team demo security outcomes to stakeholders in 5 minutes, plus metrics that show trend, not just snapshot.
What to Gather
Ask for (or extract from CI/scan outputs the user provides):
- Pipeline results for the sprint's final build: SAST, DAST, dependency/container scans, test results and coverage.
- Security stories completed this sprint (IDs and one-line outcomes).
- Open security debt: counts by severity, and anything that aged past SLA.
- Two or three sprint-over-sprint metrics — pick from: mean time to remediate by severity, new findings vs. resolved, false-positive rate, security debt trend, coverage trend.
If the user can't supply real numbers, generate the template with placeholders and mark them clearly — never invent metrics.
Green Build Report Template
# Sprint [N] — Green Build Report
## Pipeline Status
| Stage | Status | Details |
|-------|--------|---------|
| SAST | ✅/❌ | [new High/Critical count; accepted Medium count with link to acceptance] |
| DAST | ✅/❌ | [findings against staging] |
| Dependency scan | ✅/❌ | [Critical CVEs; notable upgrades] |
| Container/image scan | ✅/❌ | [base image currency] |
| Unit tests | ✅/❌ | [pass count, coverage %] |
| Integration tests | ✅/❌ | [pass count] |
## Security Stories Completed
- [ID] [Title] — [one-line demonstrable outcome, e.g. "transfer API now rejects malformed amounts; demo: curl with attack payload returns 422"]
## Security Debt Position
- Open: [n Critical / n High / n Medium / n Low] ([↑/↓ vs last sprint])
- Past SLA: [items, owner, plan]
## Metrics
- [Metric]: [value] ([trend vs previous sprint])
## Risks & Asks
- [Anything needing stakeholder decision: risk acceptance, capacity, tooling]
Demo Guidance
For each completed security story, propose a 30-second demonstration that shows the control working — the blocked attack, the alert firing, the audit log entry — rather than describing code. Stakeholders remember "we watched the brute-force attempt get locked out", not "we improved auth".
Retrospective Prompts (security angle)
Offer these when the team runs the retro:
- Which security findings could have been caught earlier in the pipeline, and what gate would have caught them?
- Did security stories get squeezed out mid-sprint? If so, was the capacity reserve real?
- Any false-positive pain worth tuning rules for?
- Did anything ship with accepted risk — and is that acceptance documented?
Guidelines
- A red pipeline stage is not shameful in the report — hiding it is. Show the failure, the cause, and the plan; that builds more stakeholder trust than a suspiciously green wall.
- Keep the whole report to one page; link out to scan dashboards for detail.
- Trends beat snapshots: always compare against at least the previous sprint where data exists.
