Security-Focused Agile Development | Vulnerability SLAs
Build security into agile sprints with shift-left practices. GitScrum tracks vulnerabilities by CVSS severity with automated workflow management.
9 min read
Security can't be an afterthought. GitScrum helps teams integrate security into agile workflows with security task tracking, vulnerability management, and process integration.
Security in Agile
Shift-Left Security
SECURITY THROUGHOUT DEVELOPMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRADITIONAL (Shift-Right): │
│ │
│ Design → Develop → Test → Security Review → Deploy │
│ ↑ │
│ "We found 47 vulnerabilities" │
│ "Release delayed 3 weeks" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SHIFT-LEFT (Integrated): │
│ │
│ Security Security Security Security │
│ ↓ ↓ ↓ ↓ │
│ Design → Develop → Test → Deploy │
│ │
│ AT EACH PHASE: │
│ │
│ Design: │
│ • Threat modeling │
│ • Security requirements │
│ • Architecture review │
│ │
│ Develop: │
│ • Secure coding practices │
│ • Static analysis (SAST) │
│ • Dependency scanning │
│ • Code review includes security │
│ │
│ Test: │
│ • Dynamic analysis (DAST) │
│ • Security test cases │
│ • Penetration testing │
│ │
│ Deploy: │
│ • Configuration scanning │
│ • Runtime protection │
│ • Monitoring and alerting │
└─────────────────────────────────────────────────────────────┘
Sprint Integration
SECURITY IN SPRINT RHYTHM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SPRINT ALLOCATION: │
│ │
│ [████████████████████████████░░░░░░░░░░] │
│ │ Features 60% │ Bugs 15% │ Security 15% │ Tech Debt 10%│
│ │
│ SECURITY WORK TYPES: │
│ │
│ PROACTIVE: │
│ • Security features (2FA, encryption) │
│ • Security improvements │
│ • Hardening tasks │
│ • Training/learning │
│ │
│ REACTIVE: │
│ • Vulnerability remediation │
│ • Incident response │
│ • Audit findings │
│ • Dependency updates │
│ │
│ IN SPRINT CEREMONIES: │
│ │
│ Backlog Refinement: │
│ • Security review of upcoming features │
│ • "What could go wrong?" │
│ │
│ Sprint Planning: │
│ • Include security tasks │
│ • Security acceptance criteria │
│ │
│ Daily Standup: │
│ • Security blockers surfaced │
│ │
│ Retrospective: │
│ • Security incidents reviewed │
│ • Process improvements │
└─────────────────────────────────────────────────────────────┘
Secure Development
Secure Coding Practices
DEVELOPER SECURITY CHECKLIST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INPUT VALIDATION: │
│ ☐ All user input validated │
│ ☐ Allowlist validation (not blocklist) │
│ ☐ Parameterized queries (no SQL injection) │
│ ☐ Output encoding (no XSS) │
│ │
│ AUTHENTICATION: │
│ ☐ Strong password requirements │
│ ☐ Rate limiting on auth endpoints │
│ ☐ Secure session management │
│ ☐ Multi-factor authentication option │
│ │
│ AUTHORIZATION: │
│ ☐ Access control on every endpoint │
│ ☐ Principle of least privilege │
│ ☐ Server-side enforcement │
│ ☐ Tested for privilege escalation │
│ │
│ DATA PROTECTION: │
│ ☐ Sensitive data encrypted at rest │
│ ☐ TLS for data in transit │
│ ☐ No secrets in code │
│ ☐ PII handling compliant │
│ │
│ ERROR HANDLING: │
│ ☐ Generic error messages to users │
│ ☐ Detailed errors to logs only │
│ ☐ No stack traces exposed │
│ │
│ LOGGING: │
│ ☐ Security events logged │
│ ☐ No sensitive data in logs │
│ ☐ Tamper-evident logging │
└─────────────────────────────────────────────────────────────┘
Security Code Review
SECURITY REVIEW PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EVERY CODE REVIEW SHOULD CHECK: │
│ │
│ INJECTION RISKS: │
│ • User input used in queries? │
│ • Dynamic code execution? │
│ • Command execution with user input? │
│ │
│ ACCESS CONTROL: │
│ • Authorization checked? │
│ • Can users access others' data? │
│ • Admin functions protected? │
│ │
│ SECRETS: │
│ • Hardcoded credentials? │
│ • API keys in code? │
│ • Environment-specific secrets? │
│ │
│ DATA HANDLING: │
│ • Sensitive data exposed? │
│ • Proper encryption used? │
│ • Data retained too long? │
│ │
│ SECURITY-SENSITIVE CHANGES (Extra Review): │
│ • Authentication/authorization changes │
│ • Cryptography changes │
│ • Payment processing │
│ • User data handling │
│ • New external integrations │
│ │
│ → Tag as "security-review" in GitScrum │
│ → Require security-trained reviewer │
└─────────────────────────────────────────────────────────────┘
Vulnerability Management
Vulnerability Workflow
VULNERABILITY HANDLING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DISCOVERY: │
│ Sources: SAST, DAST, dependency scan, pen test, bug bounty│
│ │
│ TRIAGE: │
│ Assess severity and create GitScrum task │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 VULNERABILITY: SQL Injection in /api/search ││
│ │ ││
│ │ Severity: Critical ││
│ │ CVSS: 9.8 ││
│ │ Source: Penetration test ││
│ │ Affected: All users ││
│ │ Discovered: 2024-01-15 ││
│ │ ││
│ │ SLA: 24 hours ││
│ │ Assignee: @alex ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SEVERITY SLAs: │
│ Critical (9.0-10.0): 24 hours │
│ High (7.0-8.9): 7 days │
│ Medium (4.0-6.9): 30 days │
│ Low (0.1-3.9): 90 days │
│ │
│ WORKFLOW: │
│ New → Triaged → In Progress → Fixed → Verified → Closed │
│ │
│ VERIFICATION: │
│ • Retest after fix │
│ • Confirm vulnerability resolved │
│ • Check for regression │
└─────────────────────────────────────────────────────────────┘
Dependency Security
DEPENDENCY VULNERABILITY MANAGEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATED SCANNING: │
│ • Dependabot / Snyk / OWASP Dependency Check │
│ • Run in CI on every build │
│ • Block builds on critical/high severity │
│ │
│ SCAN RESULTS EXAMPLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Dependency Vulnerabilities ││
│ │ ││
│ │ 🔴 Critical: lodash@4.17.20 (CVE-2021-23337) ││
│ │ Fix: Upgrade to 4.17.21 ││
│ │ ││
│ │ 🟠 High: axios@0.21.0 (CVE-2021-3749) ││
│ │ Fix: Upgrade to 0.21.2 ││
│ │ ││
│ │ 🟡 Medium: 3 vulnerabilities ││
│ │ ⚪ Low: 7 vulnerabilities ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROCESS: │
│ │
│ Daily: Review new critical/high │
│ Weekly: Update dependencies with fixes │
│ Monthly: Full dependency audit │
│ Quarterly: Remove unused dependencies │
│ │
│ GITSCRUM INTEGRATION: │
│ • Auto-create tasks for critical vulnerabilities │
│ • Track remediation progress │
│ • Report on vulnerability trends │
└─────────────────────────────────────────────────────────────┘
Threat Modeling
Threat Model Process
THREAT MODELING IN DESIGN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WHEN TO THREAT MODEL: │
│ • New feature with security implications │
│ • Changes to authentication/authorization │
│ • New data flows │
│ • New external integrations │
│ • Major architecture changes │
│ │
│ STRIDE FRAMEWORK: │
│ │
│ For each component/flow, ask: │
│ │
│ Spoofing: │
│ "Can someone pretend to be something they're not?" │
│ │
│ Tampering: │
│ "Can someone modify data they shouldn't?" │
│ │
│ Repudiation: │
│ "Can someone deny they did something?" │
│ │
│ Information Disclosure: │
│ "Can sensitive data be exposed?" │
│ │
│ Denial of Service: │
│ "Can someone make this unavailable?" │
│ │
│ Elevation of Privilege: │
│ "Can someone gain unauthorized access?" │
│ │
│ OUTPUT: │
│ • Identified threats │
│ • Risk rating for each │
│ • Mitigations (→ security stories in backlog) │
│ • Acceptance criteria with security checks │
└─────────────────────────────────────────────────────────────┘
Security Stories
WRITING SECURITY-FOCUSED STORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SECURITY FEATURE STORY: │
│ │
│ Title: Implement rate limiting on login endpoint │
│ │
│ As a: Security team │
│ I want: Rate limiting on login attempts │
│ So that: Brute force attacks are prevented │
│ │
│ Acceptance Criteria: │
│ ☐ 5 failed attempts locks account for 15 minutes │
│ ☐ Lockout logged with IP and timestamp │
│ ☐ User notified of lockout │
│ ☐ Admin can unlock accounts │
│ ☐ Rate limit cannot be bypassed via API │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SECURITY ACCEPTANCE CRITERIA (Any Story): │
│ │
│ Title: User profile editing │
│ │
│ Functional Criteria: │
│ ☐ User can edit name, email, avatar │
│ ☐ Changes save successfully │
│ │
│ Security Criteria: │
│ ☐ User can only edit their own profile │
│ ☐ Input validated (length, format) │
│ ☐ Email change requires verification │
│ ☐ Profile changes logged for audit │
│ ☐ Rate limited to prevent abuse │
└─────────────────────────────────────────────────────────────┘
Security Culture
Team Security Awareness
BUILDING SECURITY CULTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TRAINING: │
│ • Onboarding security training for all devs │
│ • Annual security refresher │
│ • Training after incidents │
│ • OWASP Top 10 awareness │
│ │
│ KNOWLEDGE SHARING: │
│ • Security champions in each team │
│ • Monthly security topics in team meetings │
│ • Share learnings from incidents │
│ • Security office hours │
│ │
│ INCENTIVES: │
│ • Recognize security improvements │
│ • Bug bounty for internal findings │
│ • Include security in perf reviews │
│ │
│ MAKE IT EASY: │
│ • Automated security tools │
│ • Clear security guidelines │
│ • Secure defaults in templates │
│ • Security review checklists │
│ │
│ BLAMELESS CULTURE: │
│ • Security issues are learning opportunities │
│ • Focus on process improvement │
│ • No punishment for reporting issues │
│ • Celebrate finding bugs before production │
└─────────────────────────────────────────────────────────────┘