Security Best Practices | DevSecOps for Dev Teams
Integrate security into your SDLC with SAST, DAST, and secrets management. GitScrum tracks vulnerability remediation and security review workflows.
9 min read
Security isn't a feature you add at the end—it's a mindset that permeates every stage of development. GitScrum helps teams track security tasks, manage vulnerability remediation, and ensure security reviews happen before code reaches production. The key is making security part of the definition of done, not a separate audit that happens after launch.
Security Integration Points
| Phase | Security Activity | Automation |
|---|---|---|
| Design | Threat modeling | Partial |
| Code | Secure coding, review | Manual |
| Build | SAST, dependency scan | Full |
| Test | DAST, penetration testing | Partial |
| Deploy | Config validation | Full |
| Runtime | Monitoring, WAF | Full |
Secure Development Lifecycle
SECURITY IN SDLC
PHASE 1: DESIGN
┌─────────────────────────────────────────────────┐
│ Threat Modeling: │
│ ├── Identify assets (data, functions) │
│ ├── Identify threats (STRIDE framework) │
│ ├── Identify mitigations │
│ └── Document security requirements │
│ │
│ Security Requirements: │
│ ├── Authentication needs │
│ ├── Authorization model │
│ ├── Data protection requirements │
│ └── Compliance requirements │
│ │
│ Architecture Review: │
│ ├── Security architecture patterns │
│ ├── Trust boundaries │
│ └── Defense in depth │
└─────────────────────────────────────────────────┘
PHASE 2: DEVELOPMENT
┌─────────────────────────────────────────────────┐
│ Secure Coding: │
│ ├── Follow secure coding guidelines │
│ ├── Input validation │
│ ├── Output encoding │
│ ├── Parameterized queries │
│ └── Proper error handling │
│ │
│ Code Review: │
│ ├── Security-focused review checklist │
│ ├── Authentication/authorization checks │
│ ├── Data handling review │
│ └── No hardcoded secrets │
│ │
│ IDE Security Plugins: │
│ └── Real-time security feedback │
└─────────────────────────────────────────────────┘
PHASE 3: TESTING
┌─────────────────────────────────────────────────┐
│ Automated Testing: │
│ ├── SAST (Static Analysis) │
│ ├── DAST (Dynamic Analysis) │
│ ├── Dependency scanning │
│ └── Container scanning │
│ │
│ Manual Testing: │
│ ├── Penetration testing │
│ ├── Security review │
│ └── Abuse case testing │
│ │
│ Security Test Cases: │
│ ├── Authentication bypass attempts │
│ ├── Authorization boundary tests │
│ ├── Input validation testing │
│ └── Session management testing │
└─────────────────────────────────────────────────┘
Common Vulnerabilities
OWASP TOP 10 PREVENTION
INJECTION:
┌─────────────────────────────────────────────────┐
│ Risk: SQL, NoSQL, OS, LDAP injection │
│ │
│ Prevention: │
│ ├── Use parameterized queries (prepared stmt) │
│ ├── Use ORM frameworks │
│ ├── Validate and sanitize input │
│ └── Escape special characters │
│ │
│ ✗ Bad: │
│ query = "SELECT * FROM users WHERE id=" + id │
│ │
│ ✓ Good: │
│ query = "SELECT * FROM users WHERE id = ?" │
│ stmt.setInt(1, id) │
└─────────────────────────────────────────────────┘
BROKEN AUTHENTICATION:
┌─────────────────────────────────────────────────┐
│ Risk: Session hijacking, credential stuffing │
│ │
│ Prevention: │
│ ├── Multi-factor authentication │
│ ├── Strong password policies │
│ ├── Account lockout after failed attempts │
│ ├── Secure session management │
│ ├── Rotate session IDs after login │
│ └── Use secure, httpOnly cookies │
└─────────────────────────────────────────────────┘
SENSITIVE DATA EXPOSURE:
┌─────────────────────────────────────────────────┐
│ Risk: Data breach, PII exposure │
│ │
│ Prevention: │
│ ├── Encrypt data at rest and in transit │
│ ├── Use TLS 1.2+ for all connections │
│ ├── Hash passwords with bcrypt/argon2 │
│ ├── Minimize data collection │
│ ├── Mask sensitive data in logs │
│ └── Secure key management │
└─────────────────────────────────────────────────┘
CROSS-SITE SCRIPTING (XSS):
┌─────────────────────────────────────────────────┐
│ Risk: Session theft, defacement, malware │
│ │
│ Prevention: │
│ ├── Encode output based on context │
│ ├── Use Content Security Policy (CSP) │
│ ├── Validate and sanitize input │
│ ├── Use modern frameworks (auto-escaping) │
│ └── HTTPOnly cookies for sessions │
│ │
│ ✗ Bad: │
│ <div>{{ user.name }}</div> (no escaping) │
│ │
│ ✓ Good: │
│ <div>{{ user.name | escape }}</div> │
└─────────────────────────────────────────────────┘
BROKEN ACCESS CONTROL:
┌─────────────────────────────────────────────────┐
│ Risk: Unauthorized access to data/functions │
│ │
│ Prevention: │
│ ├── Deny by default │
│ ├── Implement access control centrally │
│ ├── Enforce ownership checks │
│ ├── Disable directory listing │
│ ├── Log access control failures │
│ └── Rate limit API access │
│ │
│ ✓ Always verify: │
│ Can THIS user access THIS resource? │
└─────────────────────────────────────────────────┘
Security in CI/CD
CI/CD SECURITY PIPELINE
PIPELINE STAGES:
┌─────────────────────────────────────────────────┐
│ Stage 1: Pre-Commit │
│ ├── Secrets scanning (git-secrets, trufflehog) │
│ ├── Linting for security patterns │
│ └── Local SAST quick scan │
│ │
│ Stage 2: Build │
│ ├── SAST (full scan) │
│ ├── Dependency vulnerability scan │
│ ├── License compliance check │
│ └── Container image scan │
│ │
│ Stage 3: Test │
│ ├── Security unit tests │
│ ├── DAST scan (against test env) │
│ └── API security testing │
│ │
│ Stage 4: Deploy │
│ ├── Infrastructure as Code scanning │
│ ├── Configuration validation │
│ └── Secret rotation verification │
│ │
│ Stage 5: Runtime │
│ ├── WAF/security monitoring │
│ ├── Anomaly detection │
│ └── Security logging and alerting │
└─────────────────────────────────────────────────┘
QUALITY GATES:
┌─────────────────────────────────────────────────┐
│ Block deployment if: │
│ ├── Critical vulnerabilities found │
│ ├── High severity issues not acknowledged │
│ ├── Secrets detected in code │
│ ├── Dependency with critical CVE │
│ └── Compliance check fails │
│ │
│ Warn but allow if: │
│ ├── Medium vulnerabilities found │
│ ├── Outdated dependencies │
│ └── Minor compliance deviations │
└─────────────────────────────────────────────────┘
Secrets Management
SECRETS HANDLING
SECRETS TO PROTECT:
┌─────────────────────────────────────────────────┐
│ ├── API keys and tokens │
│ ├── Database credentials │
│ ├── Encryption keys │
│ ├── Service account credentials │
│ ├── SSL/TLS certificates │
│ └── Third-party integration secrets │
└─────────────────────────────────────────────────┘
NEVER DO:
┌─────────────────────────────────────────────────┐
│ ✗ Hardcode secrets in source code │
│ ✗ Commit secrets to version control │
│ ✗ Store secrets in environment files in repo │
│ ✗ Log secrets in application logs │
│ ✗ Share secrets via email or chat │
│ ✗ Use same secrets across environments │
└─────────────────────────────────────────────────┘
SECRETS MANAGEMENT APPROACH:
┌─────────────────────────────────────────────────┐
│ Storage: │
│ ├── Use secrets manager (Vault, AWS Secrets) │
│ ├── Environment variables (injected at deploy) │
│ └── Never in code or config files │
│ │
│ Access: │
│ ├── Principle of least privilege │
│ ├── Audit access to secrets │
│ └── Rotate secrets regularly │
│ │
│ Rotation: │
│ ├── Automated rotation where possible │
│ ├── Rotation schedule documented │
│ └── Procedure for emergency rotation │
└─────────────────────────────────────────────────┘
Security Code Review
SECURITY REVIEW CHECKLIST
AUTHENTICATION:
┌─────────────────────────────────────────────────┐
│ ☐ Strong password requirements enforced │
│ ☐ Account lockout after failed attempts │
│ ☐ Session management secure │
│ ☐ Logout invalidates session │
│ ☐ Password reset flow secure │
│ ☐ MFA implemented where appropriate │
└─────────────────────────────────────────────────┘
AUTHORIZATION:
┌─────────────────────────────────────────────────┐
│ ☐ Access control on every endpoint │
│ ☐ Ownership verified for resources │
│ ☐ Role-based access properly implemented │
│ ☐ No horizontal privilege escalation │
│ ☐ No vertical privilege escalation │
│ ☐ Default deny policy │
└─────────────────────────────────────────────────┘
DATA HANDLING:
┌─────────────────────────────────────────────────┐
│ ☐ Input validated and sanitized │
│ ☐ Output encoded appropriately │
│ ☐ Sensitive data encrypted │
│ ☐ PII handled according to policy │
│ ☐ No sensitive data in logs │
│ ☐ Secure data transmission │
└─────────────────────────────────────────────────┘
ERROR HANDLING:
┌─────────────────────────────────────────────────┐
│ ☐ Generic error messages to users │
│ ☐ Detailed errors only in logs │
│ ☐ No stack traces exposed │
│ ☐ Errors don't reveal system info │
└─────────────────────────────────────────────────┘
Incident Response
SECURITY INCIDENT PROCESS
SEVERITY LEVELS:
┌─────────────────────────────────────────────────┐
│ Critical: Active breach, data exfiltration │
│ Response: Immediate, all hands │
│ │
│ High: Vulnerability being exploited │
│ Response: Within hours │
│ │
│ Medium: Significant vulnerability found │
│ Response: Within days │
│ │
│ Low: Minor security issue │
│ Response: Within sprint │
└─────────────────────────────────────────────────┘
INCIDENT RESPONSE STEPS:
┌─────────────────────────────────────────────────┐
│ 1. Identify and Confirm │
│ ├── Validate the incident is real │
│ ├── Assess severity │
│ └── Notify security team │
│ │
│ 2. Contain │
│ ├── Isolate affected systems │
│ ├── Revoke compromised credentials │
│ └── Block attack vectors │
│ │
│ 3. Eradicate │
│ ├── Remove malicious code/access │
│ ├── Patch vulnerabilities │
│ └── Reset credentials │
│ │
│ 4. Recover │
│ ├── Restore from clean backups │
│ ├── Verify system integrity │
│ └── Resume normal operations │
│ │
│ 5. Learn │
│ ├── Post-incident review │
│ ├── Document lessons learned │
│ └── Implement preventive measures │
└─────────────────────────────────────────────────┘
Best Practices
Anti-Patterns
✗ Security as afterthought or final gate
✗ Hardcoded credentials in source code
✗ No automated security scanning
✗ Ignoring dependency vulnerabilities
✗ No security training for developers
✗ Generic error handling exposing internals