Security Work in Sprints | Vulnerability Tracking
Security work competes with features for sprint capacity. GitScrum integrates security tasks with 15-25% allocation, vulnerability labels, and risk-based prioritization.
6 min read
Security work often competes with feature delivery for sprint capacity, creating tension between protection and progress. GitScrum helps teams integrate security tasks into regular sprints, track vulnerability remediation, and maintain visibility into security posture without derailing feature development.
Security Work Categories
| Category | Priority | Sprint Treatment |
|---|---|---|
| Critical vulnerability | P0 - Immediate | Drop everything |
| High-risk issue | P1 - This sprint | Reserved capacity |
| Proactive improvement | P2 - Planned | Normal prioritization |
| Security tech debt | P3 - Backlog | When capacity allows |
| Compliance requirement | Deadline-driven | Planned milestone |
Security in Sprint Planning
SPRINT CAPACITY ALLOCATION
┌─────────────────────────────────────────────────┐
│ TYPICAL SPRINT BREAKDOWN │
│ │
│ Feature Development: 60-70% │
│ ├── New features │
│ └── Feature improvements │
│ │
│ Security Work: 15-25% │
│ ├── Vulnerability fixes │
│ ├── Security improvements │
│ ├── Dependency updates │
│ └── Security testing │
│ │
│ Other: 10-15% │
│ ├── Bug fixes │
│ ├── Technical debt │
│ └── Process improvements │
└─────────────────────────────────────────────────┘
SECURITY SPRINT BUFFER:
┌─────────────────────────────────────────────────┐
│ Reserve 20% of security capacity for: │
│ • Critical vulnerabilities discovered mid-sprint│
│ • Urgent dependency updates │
│ • Security incidents │
│ │
│ If unused: pull from security backlog │
└─────────────────────────────────────────────────┘
Security Backlog Structure
SECURITY BACKLOG ORGANIZATION
Labels:
├── [security-critical] - Exploitable, immediate fix
├── [security-high] - Significant risk
├── [security-medium] - Moderate risk
├── [security-low] - Minor issues
├── [security-proactive] - Improvements
└── [security-compliance] - Regulatory
Task Categories:
┌─────────────────────────────────────────────────┐
│ 1. VULNERABILITY REMEDIATION │
│ Tasks from security scans, pen tests │
│ Clear severity and remediation deadline │
│ │
│ 2. SECURITY FEATURES │
│ New security capabilities │
│ MFA, encryption, audit logs │
│ │
│ 3. HARDENING │
│ Proactive security improvements │
│ Header configuration, CSP, etc. │
│ │
│ 4. DEPENDENCY UPDATES │
│ Security patches in dependencies │
│ Regular update cycle │
│ │
│ 5. COMPLIANCE │
│ Regulatory requirements │
│ Deadline-driven work │
└─────────────────────────────────────────────────┘
Vulnerability Task Template
SECURITY VULNERABILITY TASK
┌─────────────────────────────────────────────────┐
│ Title: [CVE-2024-XXXX] SQL Injection in Search │
│ Labels: [security-critical] [backend] [api] │
│ │
│ SEVERITY: Critical (CVSS 9.8) │
│ SOURCE: Penetration test finding │
│ DEADLINE: 48 hours from discovery │
│ │
│ VULNERABILITY DETAILS: │
│ Location: /api/search endpoint │
│ Type: SQL Injection │
│ Impact: Data exfiltration, privilege escalation│
│ Exploitability: Low complexity, no auth needed │
│ │
│ REMEDIATION: │
│ 1. Parameterize query in search.service.ts │
│ 2. Add input validation │
│ 3. Implement WAF rule (temporary) │
│ │
│ VERIFICATION: │
│ ☐ Fix implemented and reviewed │
│ ☐ Pen test re-validated │
│ ☐ Security team approved │
│ ☐ Deployed to production │
│ ☐ Monitoring in place │
│ │
│ DISCLOSURE: │
│ Internal only / Customer notification required │
└─────────────────────────────────────────────────┘
Security in Definition of Done
SECURITY ACCEPTANCE CRITERIA
FOR ALL FEATURES:
┌─────────────────────────────────────────────────┐
│ ☐ No new security vulnerabilities introduced │
│ ☐ Security tests passing │
│ ☐ Dependency scan clean │
│ ☐ Sensitive data handling reviewed │
└─────────────────────────────────────────────────┘
FOR AUTHENTICATION/AUTHORIZATION FEATURES:
┌─────────────────────────────────────────────────┐
│ ☐ Security review completed │
│ ☐ Threat model updated │
│ ☐ Audit logging implemented │
│ ☐ Rate limiting in place │
│ ☐ Session management verified │
└─────────────────────────────────────────────────┘
FOR DATA HANDLING FEATURES:
┌─────────────────────────────────────────────────┐
│ ☐ Data classification confirmed │
│ ☐ Encryption requirements met │
│ ☐ Access controls implemented │
│ ☐ Data retention policy applied │
│ ☐ Privacy requirements satisfied │
└─────────────────────────────────────────────────┘
Security Metrics Dashboard
SECURITY HEALTH METRICS
VULNERABILITY MANAGEMENT:
┌─────────────────────────────────────────────────┐
│ Open Vulnerabilities: │
│ Critical: 0 (target: 0, SLA: 24h) ✓ │
│ High: 3 (target: <5, SLA: 7 days) ✓ │
│ Medium: 12 (target: <20, SLA: 30 days)✓ │
│ Low: 45 (target: <100, SLA: 90 days) ✓ │
└─────────────────────────────────────────────────┘
REMEDIATION VELOCITY:
┌─────────────────────────────────────────────────┐
│ Mean time to remediate (by severity): │
│ Critical: 18 hours (SLA: 24h) ✓ │
│ High: 4 days (SLA: 7 days) ✓ │
│ Medium: 21 days (SLA: 30 days) ✓ │
│ Low: 65 days (SLA: 90 days) ✓ │
└─────────────────────────────────────────────────┘
SECURITY DEBT:
┌─────────────────────────────────────────────────┐
│ Total security debt items: 28 │
│ Addressed this quarter: 15 │
│ New this quarter: 8 │
│ Trend: Decreasing ↓ │
└─────────────────────────────────────────────────┘
Best Practices
Anti-Patterns
✗ Security work only when breached
✗ "We'll fix it later" for vulnerabilities
✗ No dedicated security capacity
✗ Security as blocker vs collaborator
✗ Ignoring dependency updates
✗ Security requirements added post-development