1779 Use Cases Db0fbeb5

Use Cases - Security Pro Pack

Real-world security scenarios solved with Security Pro Pack

Use Case 1: Pre-Production Security Gate

Scenario: Your team is about to deploy a new payment processing feature to production. You need to ensure it meets security standards before launch.

Challenge:

• New feature handles sensitive payment data (PCI DSS compliance required)
• Multiple developers contributed code (varying security awareness)
• Tight deadline (2 days until launch)
• Need comprehensive security validation without hiring external auditor

Solution with Security Pro Pack:

Day 1: Automated Security Scanning (2 hours)

# Step 1: Quick vulnerability scan
cd src/features/payment-processing
/ss --output payment-security-scan.md

# Findings:
# -  Critical: Hardcoded Stripe API key
# -  High: Missing input validation on payment amount
# -  High: No rate limiting on payment endpoint
# -  Medium: Verbose error messages expose internal logic

Day 1: Compliance Check (1 hour)

Ask Compliance Checker agent:

"Please review the payment processing code for PCI DSS compliance requirements"

Findings:
-  Encryption in transit (TLS 1.3)
-  Missing: Card data not immediately deleted after processing
-  Missing: No audit logging of payment attempts
-  Tokenization implemented correctly

Day 1: Cryptography Review (30 minutes)

# Review crypto implementation
/ca src/features/payment-processing/crypto.js

# Findings:
# -  AES-256-GCM used correctly
# -  Hardcoded encryption key (PCI DSS violation)
# -  Proper IV generation

Day 2: Fix All Issues (4 hours)

// Fixed: Hardcoded secrets → Environment variables
const STRIPE_KEY = process.env.STRIPE_SECRET_KEY

// Fixed: Input validation
function validatePaymentAmount(amount) {
  if (!amount || amount <= 0 || amount > 10000) {
    throw new Error('Invalid payment amount')
  }
}

// Fixed: Rate limiting
const paymentLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5 // 5 payment attempts per 15 minutes
})

Day 2: Re-validate (1 hour)

# Re-scan to verify fixes
/ss src/features/payment-processing/

# Result:  Zero critical issues, all high-severity issues resolved

Outcome:

• Prevented: PCI DSS compliance violation (potential $5,000-$100,000/month fines)
• Saved: $3,000-$5,000 (cost of external security audit)
• Time: 8.5 hours total (vs. 2-3 weeks for traditional audit)
• Deployed: On schedule with confidence in security posture

Use Case 2: Security Incident Response

Scenario: Your production API experienced unauthorized data access. You need to quickly identify the vulnerability and assess the scope.

Challenge:

• Users reported seeing other users' data
• Incident occurred 2 hours ago
• Need to identify vulnerability immediately
• Must assess scope of data breach
• Regulator requires incident report within 72 hours

Solution with Security Pro Pack:

Hour 1: Rapid Vulnerability Assessment

Ask Security Auditor Expert:

"Perform emergency security audit of user profile API. Focus on broken object level authorization (BOLA/IDOR)."

Agent Response:
Critical Vulnerability Identified:

GET /api/users/:id/profile
 Missing authorization check
 Any authenticated user can access any profile by changing :id parameter

Evidence:
- User A (ID: 123) accessed User B's profile (ID: 456)
- No server-side validation of ownership

Hour 2: Scope Assessment

# Audit all API endpoints for similar issues
/asa https://api.example.com --focus authorization

# Findings:
# - 12 endpoints vulnerable to IDOR
# - Estimated affected users: 15,000 (accessed logs confirm)
# - Data exposed: email, phone, address (no payment data)

Hour 3: Immediate Mitigation

// Emergency fix deployed to production
app.get('/api/users/:id/profile', authenticate, (req, res) => {
  const requestedId = req.params.id

  // Authorization check added
  if (requestedId !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: 'Forbidden' })
  }

  // Continue with authorized request
})

Hour 4-6: Comprehensive Security Audit

# Full security scan
/ss --verbose --output incident-security-audit.md

# Threat model to identify similar vulnerabilities

Ask Threat Modeler:

"Perform STRIDE threat modeling on our API architecture to identify similar authorization issues"

Day 2-3: Incident Report Generation

# Generate compliance documentation for breach notification
/cdg --framework gdpr

# Customize with incident-specific details

Outcome:

• Response Time: Vulnerability identified and patched within 3 hours
• Scope: Accurately assessed data exposure for GDPR breach notification
• Prevented: Further unauthorized access (15,000 users protected)
• Compliance: Met 72-hour GDPR reporting requirement
• Cost Avoided: Potential €20 million GDPR fine (4% of global revenue)

Use Case 3: Container Security for Kubernetes Deployment

Scenario: Your team is migrating to Kubernetes. You need to ensure all container images meet security standards before production deployment.

Challenge:

• 25 microservices (25 Docker images)
• Varying base images (Ubuntu, Alpine, Node, Python)
• Some images built by different teams
• Security baseline undefined
• No existing container security scanning

Solution with Security Pro Pack:

Week 1: Baseline Container Security Audit

# Scan all images
for image in $(docker images --format "{{.Repository}}:{{.Tag}}"); do
  /dss $image --output reports/dss-$image.md
done

# Aggregate findings
# - Total: 247 vulnerabilities across 25 images
# -  Critical: 18 CVEs
# -  Critical: 12 images running as root
# -  Critical: 8 images with hardcoded secrets

Week 1-2: Systematic Remediation

Priority 1: Root User Issues (2 days)

# Before (Vulnerable)
FROM node:16
COPY . /app
CMD ["node", "server.js"]  # Runs as root!

# After (Secure)
FROM node:16-alpine
COPY . /app
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
CMD ["node", "server.js"]

Priority 2: Update Base Images (3 days)

# Before
FROM ubuntu:18.04  # 4 years old, 47 CVEs

# After
FROM ubuntu:22.04  # Latest LTS, 0 CVEs
RUN apt-get update && apt-get upgrade -y

Priority 3: Remove Hardcoded Secrets (2 days)

# Before (Secrets in environment variables)
docker run -e DB_PASSWORD="hardcoded" myapp

# After (Kubernetes secrets)
kubectl create secret generic db-secret \
  --from-literal=password=$DB_PASSWORD

# Reference in deployment:
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

Week 3: Validation & CI/CD Integration

# Re-scan all images
for image in $(docker images --format "{{.Repository}}:{{.Tag}}"); do
  /dss $image
done

# Result:  Zero critical issues across all 25 images

CI/CD Integration (GitHub Actions):

name: Container Security Scan

on: [push]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - name: Build image
        run: docker build -t ${{ github.repository }}:${{ github.sha }} .

      - name: Security scan
        run: /dss ${{ github.repository }}:${{ github.sha }}

      - name: Block on critical issues
        run: |
          if grep -q " Critical" scan-report.md; then
            exit 1
          fi

Outcome:

• Vulnerabilities Fixed: 247 → 0 critical issues
• Compliance: Met Kubernetes security best practices
• Automation: Security scanning integrated into CI/CD (prevents future issues)
• Cost Avoided: Prevented potential container escape and data breach
• Time: 3 weeks (vs. 3-6 months for manual security review)

Use Case 4: HIPAA Audit Preparation

Scenario: Your healthcare startup is preparing for first HIPAA audit. Auditors arrive in 4 weeks.

Challenge:

• No existing HIPAA documentation
• Small team (5 developers) with limited compliance knowledge
• Electronic Protected Health Information (ePHI) stored in application
• Auditor requires 12 policies and 8 procedures
• Risk analysis required
• Need business associate agreements

Solution with Security Pro Pack:

Week 1: Documentation Generation (8 hours)

# Generate all HIPAA documentation
/cdg --framework hipaa --org "HealthTech Startup Inc"

# Generated (23 documents):
# - 12 policies (Security Management, Workforce Security, etc.)
# - 8 procedures (Risk Assessment, Incident Response, etc.)
# - 3 diagrams (Data Flow, Network Architecture, Incident Response)

Week 1: Compliance Gap Analysis (4 hours)

Ask Compliance Checker agent:

"Review our application architecture for HIPAA compliance. Focus on Administrative, Physical, and Technical Safeguards."

Findings:
Administrative Safeguards:
 Security Management Process documented
 Workforce security policies in place
 Missing: Security training records
 Missing: Sanction policy documentation

Physical Safeguards:
 Facility access controls (cloud provider)
 Workstation security policy
 Missing: Device encryption enforcement

Technical Safeguards:
 Access controls (RBAC implemented)
 Audit logging enabled
 Missing: Automatic logoff after inactivity
 Missing: Encryption of ePHI at rest

Week 2: Technical Remediation (40 hours)

// Fix: Automatic logoff
const sessionTimeout = 15 * 60 * 1000 // 15 minutes (HIPAA requirement)
app.use(session({
  cookie: { maxAge: sessionTimeout },
  rolling: true
}))

// Fix: Encryption at rest
const encryptedFields = ['ssn', 'medical_record_number', 'diagnosis']
// Use AES-256-GCM for ePHI fields

# Verify cryptography implementation
/ca src/models/patient.js

# Result:  AES-256-GCM implemented correctly

Week 3: Security Audit & Risk Analysis (20 hours)

# Comprehensive security scan
/ss --verbose

# Threat modeling

Ask Threat Modeler:

"Perform STRIDE threat modeling on our patient data management system. Include data flow diagram."

# Risk Analysis Template (from compliance docs)
# Filled out based on threat model findings

Identified Risks:
1. Risk ID: R-001
   Threat: Unauthorized ePHI access via IDOR
   Likelihood: High
   Impact: High
   Risk Level: Critical
   Mitigation: Add authorization checks (implemented)

Week 4: Final Audit Preparation (10 hours)

• Review all 23 generated documents
• Customize with organization-specific details
• Prepare evidence (logs, encryption certificates, training records)
• Practice audit interview questions

Audit Result:

• Passed HIPAA audit on first attempt
• Minor Findings: 3 (documentation formatting issues only)
• Major Findings: 0
• Critical Findings: 0

Outcome:

• Time Saved: 6-8 weeks (manual documentation would take 200+ hours)
• Cost Saved: $15,000-$25,000 (HIPAA consultant fees)
• Risk Avoided: Potential $50,000 per violation fines
• Business Impact: Can now sign contracts with healthcare providers requiring HIPAA compliance

Use Case 5: API Security Before Public Launch

Scenario: Your startup is launching a public REST API for third-party developers. You need to ensure it's secure before making it public.

Challenge:

• First public API (no prior experience)
• Will be used by thousands of developers
• Needs to handle high traffic
• Reputation risk if vulnerabilities discovered
• No budget for external penetration test

Solution with Security Pro Pack:

Week 1: Comprehensive API Security Audit

# Audit API endpoints
/asa https://staging-api.example.com --output api-audit-report.md

# Findings (OWASP API Security Top 10):
# API1 - Broken Object Level Authorization: 3 endpoints vulnerable
# API2 - Broken Authentication: No rate limiting on /auth endpoints
# API3 - Mass Assignment: User can modify admin field
# API4 - Unrestricted Resource Consumption: No pagination limits
# API8 - Security Misconfiguration: Debug mode enabled

Week 2: Systematic Remediation

Fix 1: Broken Object Level Authorization

// Before (Vulnerable)
app.get('/api/projects/:id', authenticate, (req, res) => {
  const project = await Project.findById(req.params.id)
  res.json(project)  // Any user can access any project!
})

// After (Secure)
app.get('/api/projects/:id', authenticate, async (req, res) => {
  const project = await Project.findById(req.params.id)

  if (!project) {
    return res.status(404).json({ error: 'Not found' })
  }

  // Verify ownership or team membership
  if (!project.hasAccess(req.user.id)) {
    return res.status(403).json({ error: 'Forbidden' })
  }

  res.json(project)
})

Fix 2: Rate Limiting

// Authentication rate limiting
const authLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 5,
  message: 'Too many login attempts'
})

app.post('/auth/login', authLimiter, loginHandler)
app.post('/auth/register', authLimiter, registerHandler)

// General API rate limiting (per API key)
const apiLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 100, // 100 requests per minute
  keyGenerator: (req) => req.headers['x-api-key']
})

app.use('/api/', apiLimiter)

Fix 3: Mass Assignment Protection

// Allowlist approach
const allowedUserFields = ['name', 'email', 'avatar']

app.patch('/api/users/:id', authenticate, (req, res) => {
  const updates = {}

  allowedUserFields.forEach(field => {
    if (req.body[field] !== undefined) {
      updates[field] = req.body[field]
    }
  })

  // Admin field cannot be modified by user
  await User.update(req.params.id, updates)
})

Week 3: Threat Modeling

Ask Threat Modeler:

"Perform STRIDE threat modeling on our public API architecture. Include authentication flow, data access patterns, and rate limiting."

Identified Threats:
1. Spoofing: API key theft
   Mitigation: API key rotation, IP allowlisting for production keys

2. Tampering: Request replay attacks
   Mitigation: Add timestamp validation, HMAC signatures

3. Denial of Service: API abuse
   Mitigation: Tiered rate limits (free: 100/min, paid: 1000/min)

Week 4: Documentation & Launch Prep

# Generate OpenAPI documentation
# Include security requirements in docs

# Final security scan
/asa https://api.example.com --comprehensive

# Result:  All OWASP API Top 10 vulnerabilities addressed

Public Launch:

• Security Score: A+ (0 critical, 0 high vulnerabilities)
• Performance: Handles 10,000 req/min with auto-scaling
• Uptime: 99.99% first month
• Security Incidents: 0 in first 6 months

Outcome:

• Prevented: API abuse and data breaches
• Developer Trust: Developers feel confident using secure API
• Business Impact: 1,000+ developers integrated in first month
• Cost Avoided: $10,000-$20,000 (external penetration test)

Use Case 6: Cryptography Implementation Review

Scenario: Your team implemented custom encryption for user data. You need to verify it's implemented correctly before production.

Challenge:

• Team unfamiliar with cryptography best practices
• Storing sensitive PII (personally identifiable information)
• GDPR compliance required (data protection by design)
• Custom crypto implementation (high risk)

Solution with Security Pro Pack:

Day 1: Crypto Audit (2 hours)

# Review all cryptographic code
/ca src/crypto/ --output crypto-audit-report.md

# Critical Findings:
#  Using MD5 for password hashing (completely broken)
#  Hardcoded AES encryption key
#  Fixed IV reuse (same IV for all encryptions)
#  AES-CBC without HMAC (unauthenticated encryption)
#  No key rotation mechanism

Day 1-2: Expert Consultation (3 hours)

Ask Crypto Expert agent:

"Review our user data encryption implementation. We're using AES-256-CBC for PII encryption and MD5 for password hashing. What are the vulnerabilities and how do we fix them?"

Agent Response:

Critical Issues:

1. MD5 Password Hashing:
    MD5 is completely broken (rainbow tables exist)
    Fix: Use Argon2id

   Before:
   const hash = crypto.createHash('md5').update(password).digest('hex')

   After:
   const argon2 = require('argon2')
   const hash = await argon2.hash(password, {
     type: argon2.argon2id,
     memoryCost: 65536,
     timeCost: 3
   })

2. Hardcoded Encryption Key:
    If source code leaks, all data compromised
    Fix: Use environment variables + key management service

3. Fixed IV Reuse:
    Reveals patterns in encrypted data
    Fix: Generate random IV for each encryption

4. Unauthenticated Encryption:
    Attacker can modify ciphertext without detection
    Fix: Use AES-256-GCM (authenticated encryption)

Day 3-5: Implementation Fixes (24 hours)

//  SECURE: Argon2id password hashing
const argon2 = require('argon2')

async function hashPassword(password) {
  return await argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 65536,  // 64 MB
    timeCost: 3,
    parallelism: 4
  })
}

//  SECURE: AES-256-GCM with random IV
const crypto = require('crypto')

function encryptPII(plaintext) {
  const key = Buffer.from(process.env.ENCRYPTION_KEY, 'hex')  // From env
  const iv = crypto.randomBytes(12)  // Random IV for each encryption
  const cipher = crypto.createCipheriv('aes-256-gcm', key, iv)

  let encrypted = cipher.update(plaintext, 'utf8', 'hex')
  encrypted += cipher.final('hex')

  const authTag = cipher.getAuthTag()  // Authentication tag

  return {
    iv: iv.toString('hex'),
    encrypted,
    authTag: authTag.toString('hex')
  }
}

Day 6: Re-audit & Validation (2 hours)

# Re-audit crypto implementation
/ca src/crypto/

# Result:  All critical issues resolved
# Remaining: 2 medium-severity best practice recommendations

Outcome:

• Prevented: Catastrophic data breach (weak MD5 passwords, compromised encryption)
• GDPR Compliance: Achieved "data protection by design" requirement
• Reputation: Avoided security researcher disclosure of broken crypto
• Financial: Prevented potential €20 million GDPR fine

Use Case 7: Security Training for Development Team

Scenario: Your startup hired 3 junior developers. They need security training but you have no dedicated security team.

Challenge:

• Junior developers with limited security knowledge
• No budget for external security training ($2,000+ per person)
• Need practical, hands-on learning
• Want to integrate security into development workflow

Solution with Security Pro Pack:

Week 1: Hands-On Security Learning

Exercise 1: Identify Vulnerabilities

# Give each developer a sample vulnerable app
git clone https://github.com/example/vulnerable-app

# Task: Run security scan and identify all vulnerabilities
/ss vulnerable-app/

# Expected findings:
# - SQL injection
# - XSS vulnerabilities
# - Hardcoded secrets
# - Missing authentication

Exercise 2: Learn from Experts

Assign each developer to work with an expert agent:

• Developer 1: Ask Security Auditor Expert to explain OWASP Top 10
• Developer 2: Ask Penetration Tester to demonstrate SQL injection attack
• Developer 3: Ask Crypto Expert to explain proper password hashing

Exercise 3: Fix Vulnerabilities

# After fixing, re-scan to validate
/ss vulnerable-app/

# Goal: Reduce critical issues from 15 → 0

Week 2: Real-World Application

Task: Secure team's actual project

# Each developer scans a different module
Developer 1: /ss src/auth/
Developer 2: /ss src/api/
Developer 3: /ss src/database/

# Fix all critical and high-severity issues
# Pair program with expert agents for guidance

Week 3: Advanced Topics

Day 1-2: Compliance

Ask Compliance Checker:

"Explain PCI DSS requirements for our payment processing module"

Day 3-4: Threat Modeling

Ask Threat Modeler:

"Teach me how to perform STRIDE threat modeling on a user authentication system"

Day 5: Container Security

# Scan Docker containers
/dss postgres:latest
/dss redis:latest
/dss myapp:latest

# Learn: Why running as root is dangerous
# Learn: How to create minimal, secure containers

Ongoing: Security Champions

• Each developer becomes "security champion" for their module
• Weekly security scans in team meeting
• Share findings and fixes with team

Outcome:

• Knowledge: Developers gained practical security skills
• Cost Saved: $6,000 (3 developers × $2,000 training cost)
• Culture: Security-first mindset embedded in team
• Metrics:
  • Week 1: 45 critical vulnerabilities
  • Week 4: 0 critical vulnerabilities
  • Month 3: 95% of code passes security scan on first try

Summary: Value Across Use Cases

Total Value: $49,000-$80,000 in direct cost savings + millions in risk avoidance

Ready to apply these workflows to your projects? Install Security Pro Pack today!