# Sprint Security Review

> 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".

- Skill: `timwukp/sprint-security-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add timwukp/sprint-security-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timwukp/sprint-security-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: MIT
- Author: timwukp (https://skillmd.com/u/timwukp)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/timwukp/sprint-security-review

---


# 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):

1. **Pipeline results** for the sprint's final build: SAST, DAST, dependency/container scans, test results and coverage.
2. **Security stories completed** this sprint (IDs and one-line outcomes).
3. **Open security debt**: counts by severity, and anything that aged past SLA.
4. **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

```markdown
# 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.