GitScrum
Try free
6 min read • Guide 371 of 877

Security Development Practices

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

PhaseSecurity Activity
DesignThreat modeling
CodeSecure coding, review
BuildSAST, dependency scan
TestDAST, pen testing
DeployContainer scan, secrets
RunMonitoring, 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

  1. Shift left — Security in design
  2. Automate scanning — CI/CD integration
  3. Treat like bugs — Track and fix
  4. Train developers — Security awareness
  5. Defense in depth — Multiple layers

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
Back to How To Guides