Security Development Practices | Shift-Left DevSecOps
Integrate security into SDLC with SAST, dependency scanning, and threat modeling. GitScrum tracks vulnerabilities by severity with 24h to 90d SLAs.
6 min read
Security is everyone's responsibility, not just the security team's. Good security practices are built into development workflows, not bolted on at the end. This guide covers practical security practices for development teams.
Security in SDLC
| Phase | Security Activity |
|---|---|
| Design | Threat modeling |
| Code | Secure coding, review |
| Build | SAST, dependency scan |
| Test | DAST, pen testing |
| Deploy | Container scan, secrets |
| Run | Monitoring, patching |
Secure Coding
Development Practices
SECURE CODING
═════════════
INPUT VALIDATION:
─────────────────────────────────────
Always validate:
├── User input
├── API parameters
├── File uploads
├── Headers
├── Never trust input
└── Whitelist over blacklist
Example:
// Bad
const userId = req.params.id;
db.query(`SELECT * FROM users WHERE id = ${userId}`);
// Good
const userId = parseInt(req.params.id, 10);
if (isNaN(userId)) throw new Error('Invalid ID');
db.query('SELECT * FROM users WHERE id = ?', [userId]);
OUTPUT ENCODING:
─────────────────────────────────────
├── HTML encode for HTML context
├── URL encode for URLs
├── SQL parameterize for queries
├── Context-aware encoding
└── Prevent injection
AUTHENTICATION:
─────────────────────────────────────
├── Use proven libraries
├── Strong password requirements
├── Rate limiting on login
├── Secure session management
├── MFA where appropriate
└── Don't roll your own
AUTHORIZATION:
─────────────────────────────────────
├── Check on every request
├── Server-side enforcement
├── Principle of least privilege
├── Don't rely on client
└── Explicit access control
SECRETS MANAGEMENT:
─────────────────────────────────────
├── Never in code
├── Environment variables
├── Secret managers (Vault, AWS Secrets)
├── Rotate regularly
├── Different per environment
└── Protected secrets
Code Review
Security Focus
SECURITY CODE REVIEW
════════════════════
REVIEW CHECKLIST:
─────────────────────────────────────
For every PR:
├── ☐ Input validation present
├── ☐ No hardcoded secrets
├── ☐ SQL parameterized
├── ☐ Auth checks in place
├── ☐ Sensitive data protected
├── ☐ Error handling secure
├── ☐ Logging sanitized
└── Security-conscious review
RED FLAGS:
─────────────────────────────────────
Watch for:
├── String concatenation in queries
├── eval() or similar
├── Hardcoded passwords/keys
├── Missing auth checks
├── Disabled security controls
├── Overly permissive CORS
├── Sensitive data in logs
└── Known bad patterns
AUTOMATED CHECKS:
─────────────────────────────────────
CI/CD gates:
├── SAST scan
├── Dependency check
├── Secret detection
├── Block on critical findings
├── Automated first line
└── Human review second
CI/CD Security
Pipeline Security
CI/CD SECURITY
══════════════
SECURITY PIPELINE:
─────────────────────────────────────
Push
│
▼
┌─────────────────┐
│ Secret Detection│ GitGuardian, TruffleHog
└────────┬────────┘
│
▼
┌─────────────────┐
│ SAST Analysis │ SonarQube, Snyk
└────────┬────────┘
│
▼
┌─────────────────┐
│ Dependency Scan │ npm audit, Snyk
└────────┬────────┘
│
▼
┌─────────────────┐
│ Container Scan │ Trivy, Clair
└────────┬────────┘
│
▼
┌─────────────────┐
│ Build & Deploy │
└─────────────────┘
SAST (STATIC ANALYSIS):
─────────────────────────────────────
Scan code for vulnerabilities:
├── SQL injection patterns
├── XSS vulnerabilities
├── Insecure crypto
├── Hardcoded secrets
├── Early detection
└── Every PR
DEPENDENCY SCANNING:
─────────────────────────────────────
Check for known vulnerabilities:
├── npm audit
├── Snyk
├── Dependabot
├── Block on critical CVEs
├── Auto-update patches
└── Supply chain security
SECRET DETECTION:
─────────────────────────────────────
Find leaked secrets:
├── Pre-commit hooks
├── CI/CD scanning
├── Git history scanning
├── Alert on detection
├── Block commits
└── Prevent leaks
POLICY GATES:
─────────────────────────────────────
Block deploys when:
├── Critical vulnerabilities
├── Secrets detected
├── High-severity findings
├── No exceptions
└── Enforce standards
Vulnerability Management
Handling Findings
VULNERABILITY MANAGEMENT
════════════════════════
TRIAGE:
─────────────────────────────────────
For each finding:
├── Is it real? (not false positive)
├── Is it exploitable?
├── What's the impact?
├── Assign severity
└── Prioritize response
SEVERITY LEVELS:
─────────────────────────────────────
Critical:
├── Actively exploited
├── Remote code execution
├── Data breach risk
├── SLA: 24 hours
└── Drop everything
High:
├── Significant risk
├── Authentication bypass
├── Privilege escalation
├── SLA: 7 days
└── High priority
Medium:
├── Moderate risk
├── Limited impact
├── Requires user action
├── SLA: 30 days
└── Normal priority
Low:
├── Minor risk
├── Defense in depth
├── Best practice
├── SLA: 90 days
└── Backlog
TRACKING:
─────────────────────────────────────
Track like bugs:
├── Create task in GitScrum
├── Label: security
├── Severity field
├── SLA deadline
├── Assigned owner
└── Visible accountability
Threat Modeling
Design Security
THREAT MODELING
═══════════════
WHEN TO MODEL:
─────────────────────────────────────
├── New features
├── Architecture changes
├── Third-party integrations
├── Sensitive data handling
├── During design phase
└── Before coding
STRIDE MODEL:
─────────────────────────────────────
Spoofing: Can someone pretend to be someone else?
Tampering: Can data be modified maliciously?
Repudiation: Can actions be denied?
Information Disclosure: Can data leak?
Denial of Service: Can service be disrupted?
Elevation of Privilege: Can access be escalated?
SIMPLE APPROACH:
─────────────────────────────────────
For each feature ask:
├── What can go wrong?
├── Who are the attackers?
├── What are the assets?
├── What are the controls?
├── Document threats
└── Mitigate in design
DOCUMENT FINDINGS:
─────────────────────────────────────
Feature: User profile API
Threat: Unauthorized access to profiles
Control: Authentication required
Threat: IDOR (access other profiles)
Control: Authorization check on profile ID
GitScrum Integration
Security Tracking
GITSCRUM FOR SECURITY
═════════════════════
SECURITY LABELS:
─────────────────────────────────────
├── security
├── vulnerability
├── severity:critical
├── severity:high
├── severity:medium
├── severity:low
└── Clear categorization
SECURITY TASKS:
─────────────────────────────────────
Task: "Fix SQL injection in search API"
├── Severity: Critical
├── SLA: 24 hours
├── CVE reference (if any)
├── Affected versions
├── Fix approach
└── Complete information
TRACKING METRICS:
─────────────────────────────────────
├── Open vulnerabilities by severity
├── SLA compliance
├── Time to remediation
├── Findings over time
├── Trend visibility
└── Improvement tracking
DOCUMENTATION:
─────────────────────────────────────
NoteVault:
├── Security standards
├── Secure coding guidelines
├── Incident response plan
├── Threat models
└── Security knowledge base
Best Practices
For Security Development
Anti-Patterns
SECURITY MISTAKES:
✗ Security as afterthought
✗ Ignoring scan results
✗ No vulnerability SLAs
✗ Secrets in code
✗ Missing input validation
✗ Rolling own crypto
✗ Assuming trust
✗ Security by obscurity