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.
1---2name: sprint-security-review3description: 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".4license: MIT5---67# Sprint Security Review89Make 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.1011## What to Gather1213Ask for (or extract from CI/scan outputs the user provides):14151. **Pipeline results** for the sprint's final build: SAST, DAST, dependency/container scans, test results and coverage.162. **Security stories completed** this sprint (IDs and one-line outcomes).173. **Open security debt**: counts by severity, and anything that aged past SLA.184. **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.1920If the user can't supply real numbers, generate the template with placeholders and mark them clearly — never invent metrics.2122## Green Build Report Template2324```markdown25# Sprint [N] — Green Build Report2627## Pipeline Status28| Stage | Status | Details |29|-------|--------|---------|30| SAST | ✅/❌ | [new High/Critical count; accepted Medium count with link to acceptance] |31| DAST | ✅/❌ | [findings against staging] |32| Dependency scan | ✅/❌ | [Critical CVEs; notable upgrades] |33| Container/image scan | ✅/❌ | [base image currency] |34| Unit tests | ✅/❌ | [pass count, coverage %] |35| Integration tests | ✅/❌ | [pass count] |3637## Security Stories Completed38- [ID] [Title] — [one-line demonstrable outcome, e.g. "transfer API now rejects malformed amounts; demo: curl with attack payload returns 422"]3940## Security Debt Position41- Open: [n Critical / n High / n Medium / n Low] ([↑/↓ vs last sprint])42- Past SLA: [items, owner, plan]4344## Metrics45- [Metric]: [value] ([trend vs previous sprint])4647## Risks & Asks48- [Anything needing stakeholder decision: risk acceptance, capacity, tooling]49```5051## Demo Guidance5253For 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".5455## Retrospective Prompts (security angle)5657Offer these when the team runs the retro:5859- Which security findings could have been caught earlier in the pipeline, and what gate would have caught them?60- Did security stories get squeezed out mid-sprint? If so, was the capacity reserve real?61- Any false-positive pain worth tuning rules for?62- Did anything ship with accepted risk — and is that acceptance documented?6364## Guidelines6566- 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.67- Keep the whole report to one page; link out to scan dashboards for detail.68- Trends beat snapshots: always compare against at least the previous sprint where data exists.
timwukp