SecOps Overview

SecOps (Security Operations) integrates security practices into the entire software development lifecycle, enabling teams to deliver secure software at velocity without sacrificing agility for protection.

DevSecOps Principles

DevSecOps represents the cultural and technical evolution of embedding security into every phase of the software development lifecycle. The shift-left security philosophy moves security checks earlier in the pipeline, where vulnerabilities are exponentially cheaper to fix.

Shift-Left Security

Traditional security models perform assessments late in the lifecycle — often just before production. Shift-left security inverts this model:

Core Principles

1. Security as Code — Security policies expressed as version-controlled code (Open Policy Agent, Sentinel)
2. Automated Security Gates — Pipeline-enforced quality gates that block on critical findings
3. Continuous Monitoring — Real-time visibility into security posture across all environments
4. Shared Responsibility — Security is everyone's responsibility, not a siloed team
5. Rapid Feedback — Developers receive security feedback within minutes, not weeks

Security in CI/CD Pipeline Stages

A secure CI/CD pipeline implements multiple verification layers. Each stage must fail the pipeline when critical security issues are detected:

# Example: Secure CI/CD Pipeline Structure
# .github/workflows/secure-pipeline.yml

stages:
  - precommit    # Git hooks, linting
  - build        # SAST, SCA, secrets scan
  - test         # Unit tests, DAST
  - container    # Image scanning, SBOM generation
  - deploy       # IaC scanning, compliance checks
  - monitor      # Runtime security, anomaly detection

security-gates:
  sast-critical:     block-on > 0 critical findings
  secrets-scan:      block-on any leaked secret
  dependency-cvss:   block-on CVSS >= 7.0
  container-cve:     block-on CVE severity = CRITICAL
  compliance-drift:  block-on policy violation

Pipeline Security Controls

Defense in Depth Strategy

Defense in depth is a layered security architecture where multiple independent controls protect assets. If one layer fails, subsequent layers provide continued protection:

┌─────────────────────────────────────────┐
│  Layer 7: Data Encryption (at rest/transit) │
│  Layer 6: Application Security (WAF, RASP)  │
│  Layer 5: Endpoint Protection (EDR, FIM)    │
│  Layer 4: Network Security (SG, NACL, IDS)  │
│  Layer 3: Compute Security (Hardened AMIs)   │
│  Layer 2: Access Control (IAM, RBAC, MFA)    │
│  Layer 1: Perimeter (CDN, DDoS protection)   │
│  Layer 0: Physical/Cloud Provider Security   │
└─────────────────────────────────────────┘

Layer Implementation

Security Frameworks

NIST Cybersecurity Framework

The NIST CSF organizes cybersecurity activities into five core functions:

1. Identify — Asset management, risk assessment, governance
2. Protect — Access control, awareness training, data security
3. Detect — Anomaly detection, continuous monitoring
4. Respond — Response planning, communications, analysis
5. Recover — Recovery planning, improvements, communications

CIS Controls

The CIS Controls (v8) provide 18 prioritized safeguards:

OWASP Top 10 (2021)

Threat Modeling Basics

STRIDE Methodology

STRIDE is a threat classification framework developed by Microsoft. Each letter represents a category of threat:

Threat Modeling Process

1. Define Scope — Identify the application, data flows, and trust boundaries
2. Decompose Application — Create Data Flow Diagrams (DFDs) showing processes, data stores, external entities
3. Identify Threats — Apply STRIDE to each element in the DFD
4. Assess Risks — Rate likelihood and impact for each identified threat
5. Plan Mitigations — Design and implement controls for high-risk threats
6. Validate — Re-assess after mitigations are implemented

# threat_model_risk_calculator.py
# Risk scoring for identified threats

def calculate_risk(likelihood: int, impact: int) -> str:
    """
    Calculate risk level based on 1-5 likelihood and impact scores.
    
    Returns: CRITICAL, HIGH, MEDIUM, LOW
    """
    score = likelihood * impact
    
    if score >= 15:
        return "CRITICAL"
    elif score >= 10:
        return "HIGH"
    elif score >= 5:
        return "MEDIUM"
    else:
        return "LOW"

# Example: SQL injection in authentication endpoint
likelihood = 4   # Easily exploitable with known tools
impact = 5       # Full database compromise
risk = calculate_risk(likelihood, impact)
print(f"SQL Injection Risk Level: {risk}")  # CRITICAL

# Example: Information disclosure via verbose error messages
likelihood = 3   # Requires some reconnaissance
impact = 2       # Limited information leakage
risk = calculate_risk(likelihood, impact)
print(f"Info Disclosure Risk Level: {risk}")  # MEDIUM

Security Tools Landscape

Vulnerability Management Lifecycle

Vulnerability management is a continuous cyclical process:

1. Discover — Asset inventory, network scanning, agent-based detection
2. Assess — Vulnerability scanning with authenticated and unauthenticated tests
3. Prioritize — Risk-based scoring using CVSS, threat intelligence, asset criticality
4. Remediate — Patching, configuration hardening, compensating controls
5. Verify — Rescanning to confirm remediation, regression testing
6. Report — Executive dashboards, compliance evidence, trend analysis

# vulnerability-management-sla.yaml
# SLA targets by severity

severities:
  critical:
    cvss_range: "9.0 - 10.0"
    remediation_sla: "24 hours"
    approval_required: false  # Emergency patching
    auto_create_ticket: true
    
  high:
    cvss_range: "7.0 - 8.9"
    remediation_sla: "7 days"
    approval_required: true
    auto_create_ticket: true
    
  medium:
    cvss_range: "4.0 - 6.9"
    remediation_sla: "30 days"
    approval_required: true
    auto_create_ticket: true
    
  low:
    cvss_range: "0.1 - 3.9"
    remediation_sla: "90 days"
    approval_required: false
    auto_create_ticket: false

exemptions:
  process: "CISO approval required for >30 day extensions"
  max_extension: "90 days"
  review_frequency: "Monthly"

Security Metrics and KPIs

Effective SecOps programs measure leading indicators (process metrics) and lagging indicators (outcome metrics):

Security Champion Program

A Security Champion program embeds security expertise within development teams without requiring dedicated security headcount per team.

Program Structure

Security Champion Program
│
├── Executive Sponsor (CISO / VP Engineering)
│
├── Security Champion Lead (Security Team)
│   ├── Onboarding curriculum
│   ├── Monthly training sessions
│   └── Office hours support
│
├── Champions (1 per dev team ~10:1 ratio)
│   ├── Attend monthly meetings
│   ├── Review security requirements
│   ├── Escalate issues to security team
│   └── Advocate for secure practices
│
└── Incentives
    ├── Conference attendance budget
    ├── Certification reimbursement (OSCP, CISSP)
    ├── Recognition in performance reviews
    └── Dedicated learning time (10% allocation)

Champion Responsibilities

• Participate in threat modeling sessions for their team's features
• Review security-related pull requests
• Ensure team compliance with security policies
• Report security metrics to the security team monthly
• Drive adoption of security tools and practices within their team

Compliance Mapping

Organizations often need to satisfy multiple compliance frameworks simultaneously. Cross-mapping controls reduces audit burden:

Evidence Collection Automation

Automate evidence collection for compliance audits using infrastructure-as-code and continuous monitoring:

# terraform/compliance-evidence-collection.tf
# Automated evidence collection for SOC 2

# AWS Config Rule: Check for encrypted volumes
resource "aws_config_config_rule" "ec2_encrypted_volumes" {
  name = "ec2-volumes-must-be-encrypted"
  
  source {
    owner             = "AWS"
    source_identifier = "EC2_VOLUME_INUSE_CHECK"
  }
  
  input_parameters = jsonencode({
    volumeIds = ""
  })
  
  depends_on = [aws_config_configuration_recorder.compliance_recorder]
}

# AWS Config Rule: MFA enabled for root
resource "aws_config_config_rule" "root_account_mfa_enabled" {
  name = "root-account-mfa-enabled"
  
  source {
    owner             = "AWS"
    source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
  }
  
  depends_on = [aws_config_configuration_recorder.compliance_recorder]
}

# CloudWatch Log Group for audit trail
resource "aws_cloudwatch_log_group" "audit_logs" {
  name              = "/compliance/audit-trail"
  retention_in_days = 2555  # 7 years for SOX/PCI-DSS
  
  kms_key_id = aws_kms_key.audit_encryption.arn
}