Duration: 2 hours
Level: Basic
Prerequisites: Basic understanding of software development lifecycle
By the end of this module, you will:
- Understand the concept and importance of shift-left security
- Learn the cost implications of finding bugs at different stages
- Identify key security practices for each development phase
- Understand the DevSecOps culture and shared responsibility model
- Set up your initial development environment
Security has traditionally been a gate at the end of the development process. This module explores why that approach is no longer sufficient and how shift-left security transforms the way we build secure applications.
graph LR
A[Development] --> B[Testing]
B --> C[Security Review]
C --> D[Production]
C -->|Issues Found| A
style C fill:#f96,stroke:#333,stroke-width:2px
Problems with this approach:
- Security issues found late are expensive to fix
- Delays in release cycles
- Security team becomes a bottleneck
- Developers lack security context
graph LR
A[Secure Design] --> B[Secure Development]
B --> C[Secure Testing]
C --> D[Secure Deployment]
D --> E[Secure Operations]
subgraph "Continuous Security"
A -.-> F[Security Scanning]
B -.-> F
C -.-> F
D -.-> F
E -.-> F
end
style F fill:#6f9,stroke:#333,stroke-width:2px
Research shows that fixing security issues becomes exponentially more expensive as they progress through the SDLC:
graph TB
subgraph "Cost to Fix Security Issues"
A[Design: $80] --> B[Development: $240]
B --> C[Testing: $960]
C --> D[QA: $7,600]
D --> E[Production: $4.45M]
end
style E fill:#f66,stroke:#333,stroke-width:4px
-
Prevention over Detection
- Secure coding practices
- Security requirements in design
- Threat modeling early
-
Automation First
- Automated security scanning
- Policy as code
- Continuous compliance
-
Developer Empowerment
- Security training
- Developer-friendly tools
- Fast feedback loops
-
Shared Responsibility
- Everyone owns security
- Security champions in teams
- Collaborative culture
DevSecOps extends DevOps by embedding security practices throughout the entire software development lifecycle.
graph TB
subgraph "DevSecOps Infinity Loop"
A[Plan] --> B[Code]
B --> C[Build]
C --> D[Test]
D --> E[Release]
E --> F[Deploy]
F --> G[Operate]
G --> H[Monitor]
H --> A
I[Security] -.-> A
I -.-> B
I -.-> C
I -.-> D
I -.-> E
I -.-> F
I -.-> G
I -.-> H
end
style I fill:#bbf,stroke:#333,stroke-width:2px
Moving from traditional security to DevSecOps requires:
-
Breaking Down Silos
- Security teams collaborate with developers
- Shared goals and metrics
- Cross-functional teams
-
Continuous Learning
- Security training for developers
- Development understanding for security
- Regular knowledge sharing
-
Fail Fast, Fix Fast
- Embrace security findings
- Quick remediation cycles
- Learning from incidents
Creating a security-first culture requires:
- Leadership Buy-In: Security starts at the top
- Developer Empowerment: Give teams the tools and training
- Continuous Learning: Security landscape constantly evolves
- Shared Responsibility: Everyone owns security
- Celebration of Success: Recognize security achievements
Objective: Calculate the potential cost savings of shift-left security
-
Consider a typical security vulnerability (e.g., SQL injection)
-
Research the average time to fix at each stage:
- During coding: 30 minutes
- During testing: 3 hours
- In production: 10 hours + incident response
-
Calculate the cost difference using these hourly rates:
- Developer: $100/hour
- QA Engineer: $80/hour
- Security Team: $150/hour
- Incident Response: $500/hour
-
Document your findings in
exercises/01-cost-analysis.md
Expected Output: A cost comparison showing ROI of shift-left practices
Objective: Map security practices to your development lifecycle
-
Create a diagram of your current (or ideal) SDLC phases
-
For each phase, identify:
- Current security practices (if any)
- Potential security improvements
- Tools that could help
-
Use this template:
# SDLC Security Mapping
## Planning Phase
- **Current Practices**: [List current practices]
- **Improvements**: [List potential improvements]
- **Tools**: [List applicable tools]
## Development Phase
- **Current Practices**: [List current practices]
- **Improvements**: [List potential improvements]
- **Tools**: [List applicable tools]
[Continue for all phases...]- Save as
exercises/02-sdlc-mapping.md
Objective: Configure basic Git security settings
- Configure Git with security in mind:
# Set up Git identity
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
# Enable commit signing (optional but recommended)
git config --global commit.gpgsign true
# Set up credential helper
git config --global credential.helper cache- Create a
.gitignorefile for security:
# Security-sensitive files
.env
.env.*
*.key
*.pem
*.p12
*.pfx
secrets/
credentials/
# IDE and system files
.vscode/
.idea/
.DS_Store
Thumbs.db- Create pre-commit hooks for security:
Create .git/hooks/pre-commit:
#!/bin/bash
# Check for common security issues
# Check for AWS keys
if git diff --cached --name-only | xargs grep -E "AKIA[0-9A-Z]{16}" 2>/dev/null; then
echo "ERROR: AWS Access Key detected in commit"
exit 1
fi
# Check for private keys
if git diff --cached --name-only | xargs grep -E "BEGIN (RSA |DSA |EC |OPENSSH )?PRIVATE KEY" 2>/dev/null; then
echo "ERROR: Private key detected in commit"
exit 1
fi
echo "Security checks passed"
exit 0- Make the hook executable:
chmod +x .git/hooks/pre-commitObjective: Build a practical security checklist for development
-
Create a security checklist for your team covering:
- Code review security items
- Pre-commit checks
- Dependencies management
- Secrets handling
-
Use this template in
exercises/04-security-checklist.md:
# Development Security Checklist
## Code Review
- [ ] No hardcoded secrets or credentials
- [ ] Input validation implemented
- [ ] SQL queries use parameterization
- [ ] Error messages don't expose sensitive info
- [ ] [Add more items...]
## Before Committing
- [ ] Run security linter
- [ ] Check for exposed secrets
- [ ] Update dependencies
- [ ] [Add more items...]
## Dependencies
- [ ] All dependencies from trusted sources
- [ ] No known vulnerabilities
- [ ] Licenses reviewed
- [ ] [Add more items...]Objective: Design metrics for measuring security improvement
-
Identify key security metrics:
- Mean Time to Detect (MTTD)
- Mean Time to Remediate (MTTR)
- Number of vulnerabilities by severity
- Security training completion rate
-
Create a simple dashboard mockup showing these metrics
-
Document how you would collect each metric
Save your design in exercises/05-metrics-dashboard.md
- Shift-left security moves security practices earlier in the development lifecycle
- Cost savings are dramatic when issues are caught early
- DevSecOps requires cultural change, not just tools
- Automation is key to scalable security
- Shared responsibility means everyone owns security
- ✅ Understanding of shift-left principles
- ✅ Basic Git security configuration
- ✅ Security checklist creation
- ✅ Cost-benefit analysis of security practices
- ✅ SDLC security mapping
Before moving to the next module, ensure you have:
- Completed all 5 exercises
- Created your security checklist
- Configured Git security settings
- Understood the cost implications of shift-left
- Mapped security to SDLC phases
Ready to dive deeper? Continue to Module 02: GitHub Advanced Security Fundamentals where we'll explore powerful security tools built into GitHub.
Questions or Issues? Check our FAQ or open an issue.
| Previous | Up | Next |
|---|---|---|
| 🚀 Quick Start Guide | 📚 All Modules | Module 02: GitHub Advanced Security → |
Quick Links: 🏠 Home • 📖 Workshop Overview • 🛡️ Security FAQ