DevSecOps & Secure Development Lifecycle

Executive Summary

Building Security Into Every Release

DevSecOps integrates security into every phase of the software development lifecycle rather than treating it as an afterthought. For ReGenesis, this means that every code change is automatically scanned for vulnerabilities, every dependency is monitored for known security issues, and every deployment goes through security checks before reaching production. The goal is to catch and fix security issues before they reach customers.

The approach is especially important for an AI coaching platform because the platform faces both traditional web application security risks (OWASP Top 10) and emerging AI-specific risks (OWASP LLM Top 10, including prompt injection and data leakage through AI responses). The secure SDLC incorporates threat modeling for major features, mandatory code review with security focus, static analysis, dependency scanning, secrets detection, and SBOM (Software Bill of Materials) generation for supply chain transparency.

Enterprise clients expect documented secure development practices as part of the procurement process. SOC 2 CC8.1 (change management) and ISO 27001 A.8.25-A.8.31 (secure development) require evidence that security is embedded in the development process, not bolted on afterward.

Working Knowledge

The Secure Development Lifecycle

Overview

Threat Modeling

Before building any major feature, the team conducts a threat model to identify potential security risks. This is especially important for features that involve:

• New data flows (coaching session recording, AI processing)
• Authentication/authorization changes
• Third-party integrations (Anthropic API, SSO providers)
• Mobile functionality (offline mode, local storage)

Methodology: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)

Threat Category	Example for ReGenesis	Mitigation
Spoofing	Attacker impersonates a coach to access coachee data	SSO + MFA, session validation, role verification
Tampering	Modifying coaching session transcripts	Integrity hashes, audit trails, field-level encryption
Repudiation	Denying an administrative action occurred	Tamper-evident audit logs, digital signatures
Information Disclosure	AI leaking one coachee's data into another's session	Tenant isolation, context window scoping, output filtering
Denial of Service	Overwhelming the platform to prevent coaching sessions	WAF, rate limiting, auto-scaling, DDoS protection
Elevation of Privilege	Coachee gaining coach or admin permissions	RBAC enforcement at API level, authorization middleware

Code Review Process

Every code change goes through peer review before merging:

Requirement	Details
Minimum reviewers	1 reviewer for standard changes, 2 for security-sensitive changes
Security-sensitive changes	Auth, encryption, data access, AI prompts, infrastructure
Review checklist	Input validation, authorization checks, logging, error handling, secret management
Branch protection	main branch requires PR approval, passing CI, no force pushes
Security label	PRs touching security-sensitive areas automatically tagged for security review

OWASP Top 10 (Web Application)

The classic web application security risks that the platform defends against:

#	Risk	Platform Defense
A01	Broken Access Control	RBAC middleware, tenant isolation, row-level security
A02	Cryptographic Failures	TLS 1.2+, AES-256, KMS key management, no weak algorithms
A03	Injection	Parameterized queries (Prisma ORM), input validation (Zod), WAF rules
A04	Insecure Design	Threat modeling, security requirements, secure defaults
A05	Security Misconfiguration	IaC (Terraform), automated config scanning, no default credentials
A06	Vulnerable Components	Dependabot, npm audit, automated dependency updates
A07	Authentication Failures	SSO, MFA, rate limiting, account lockout, secure session management
A08	Software/Data Integrity	CI/CD pipeline security, signed images, SBOM, dependency pinning
A09	Logging/Monitoring Failures	Comprehensive audit logging, SIEM, real-time alerting
A10	Server-Side Request Forgery	Outbound request allowlisting, URL validation, private subnet isolation

OWASP LLM Top 10 (AI-Specific)

Risks specific to the platform's use of Large Language Models (Claude API via Sasha):

#	Risk	Description	Platform Defense
LLM01	Prompt Injection	User manipulates AI through crafted prompts	System prompt hardening, input sanitization, output filtering
LLM02	Insecure Output Handling	AI output used unsafely in the application	Output validation, content policy checks, HTML escaping
LLM03	Training Data Poisoning	N/A (ReGenesis uses API, not custom training)	Anthropic's responsibility; ReGenesis validates outputs
LLM04	Model Denial of Service	Excessive token usage or long-running requests	Token limits, request timeouts, cost monitoring
LLM05	Supply Chain Vulnerabilities	Compromised model provider	Anthropic vendor assessment, API key rotation, fallback provider
LLM06	Sensitive Information Disclosure	AI reveals data from other sessions	Per-session context scoping, no cross-tenant data in prompts
LLM07	Insecure Plugin Design	N/A for current architecture	Not applicable (no plugins)
LLM08	Excessive Agency	AI performing actions beyond intended scope	Sasha has no write access, all actions require human confirmation
LLM09	Overreliance	Users trusting AI output without verification	Disclaimers, human coach oversight, confidence indicators
LLM10	Model Theft	N/A (ReGenesis does not host models)	Not applicable

AI-Specific Threat: Cross-Session Data Leakage

The highest AI-specific risk for ReGenesis is data leaking from one coaching session or one coachee into another's context. Defenses:

1. Each Sasha session starts with a clean context window
2. Historical context is loaded per-coachee, never cross-coachee
3. System prompts enforce data boundary rules
4. Output filtering checks for PII from other users
5. Prompt injection detection monitors for manipulation attempts

CI/CD Pipeline Security

Dependency Management

Tool	Purpose	Configuration
Dependabot	Automated dependency updates	Weekly PRs for minor/patch, immediate for security
npm audit	Known vulnerability check	Runs in CI, blocks on critical/high
Socket.dev	Supply chain attack detection	Monitors for malicious packages
Renovate (alternative)	Dependency update automation	If Dependabot insufficient
package-lock.json	Dependency pinning	Always committed, ensures reproducible builds

Secrets Scanning

Layer	Tool	Behavior
Pre-commit	gitleaks / TruffleHog	Blocks commit if secrets detected
CI	GitHub secret scanning	Scans all pushes, alerts on findings
Repository	GitHub push protection	Blocks pushes containing known secret patterns
Monitoring	GitHub Advanced Security	Continuous scanning of repository history

Never Commit Secrets

API keys, database passwords, encryption keys, and tokens must NEVER appear in source code. All secrets must be stored in AWS Secrets Manager and injected at runtime. The CI pipeline will fail if any secret patterns are detected in code.

SAST & DAST Tool Selection

Tool Selection Status

SAST tool selection is partially resolved -- CodeQL is confirmed as the primary scanner with SonarQube as a secondary code quality gate. DAST tool selection needs finalization before the Pilot phase, including scope definition for authenticated scanning and API fuzzing targets.

SAST (Static Application Security Testing)

Tool	Role	Phase	Cost	Notes
GitHub CodeQL	Primary security scanner	MVP onward	Free for GitHub repos	Runs on every PR; covers OWASP Top 10 patterns, custom queries for tenant isolation and prompt injection
SonarQube	Secondary code quality + security	Pilot onward	Community (free) or Developer tier	Quality gate enforcement: coverage, duplication, security hotspots, code smells

Decision: CodeQL serves as the primary security scanner integrated into every pull request via GitHub Actions. SonarQube is added at the Pilot phase to provide deeper code quality metrics, technical debt tracking, and security hotspot review that complement CodeQL's vulnerability-focused analysis.

DAST (Dynamic Application Security Testing)

Tool	Role	Phase	Cost	Notes
OWASP ZAP	Automated DAST in CI/CD	Pilot onward	Free / open-source	Baseline and full scans against staging after each deploy
Burp Suite Professional	Manual penetration testing	GA onward	~$449/user/year	Used by security team for deep manual testing, logic flaw discovery
Nuclei	Targeted vulnerability scanning	GA onward (optional)	Free / open-source	Template-based scanning for known CVEs, misconfigurations, and exposed endpoints

DAST CI/CD Integration

# .github/workflows/dast-zap.yml
name: DAST - OWASP ZAP Scan

on:
  workflow_run:
    workflows: ["Deploy to Staging"]
    types: [completed]

permissions:
  contents: read
  issues: write

jobs:
  zap-scan:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - uses: actions/checkout@v4

      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.12.0
        with:
          target: "https://staging.regenesis.ai"
          rules_file_name: ".zap/rules.tsv"
          cmd_options: "-a"

      - name: OWASP ZAP Full Scan (Weekly)
        if: github.event.schedule == 'cron(0 2 * * 0)'
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: "https://staging.regenesis.ai"
          rules_file_name: ".zap/rules.tsv"

      - name: Upload ZAP Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report_html.html

DAST Scanning Scope

• Authenticated scanning -- ZAP configured with session tokens to test behind-login surfaces (coach dashboard, coachee portal, admin console)
• API fuzzing -- REST API endpoints tested for injection, parameter tampering, and broken access control
• Session management -- Token expiry, session fixation, cookie flags, and concurrent session handling
• Input validation -- Form fields, query parameters, and request bodies tested for XSS, SQLi, and command injection
• CORS and header security -- Verify strict CORS policies, security headers (CSP, HSTS, X-Frame-Options), and cookie attributes
• AI/LLM endpoints excluded -- Sasha API endpoints are excluded from automated DAST scanning; these undergo separate red-team testing with prompt injection and data leakage scenarios (see AI Red Team Testing)

Change Management

Aspect	Policy
Standard changes	Automated deployment after CI passes + 1 reviewer approval
Security changes	Requires 2 reviewer approval including security lead
Infrastructure changes	Requires Terraform plan review + approval
Emergency changes	Expedited approval (Security Officer), must be retroactively reviewed within 24h
Rollback	One-click rollback in deployment pipeline, maximum 5-minute rollback time
Change log	All deployments logged with commit SHA, deployer, timestamp, change description

SBOM Generation

A Software Bill of Materials lists every component in the software supply chain. Enterprise clients increasingly require SBOMs for supply chain risk assessment.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:...",
  "version": 1,
  "metadata": {
    "timestamp": "2026-06-15T00:00:00Z",
    "tools": [{ "name": "cyclonedx-node-npm", "version": "1.0.0" }],
    "component": {
      "type": "application",
      "name": "regenesis-portal",
      "version": "1.0.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "react",
      "version": "18.3.0",
      "purl": "pkg:npm/react@18.3.0",
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Developer Security Training

Topic	Frequency	Audience	Format
Secure coding fundamentals	Onboarding + annual	All developers	Online course
OWASP Top 10	Annual	All developers	Workshop
OWASP LLM Top 10	Annual	AI/ML engineers	Workshop
Incident response for developers	Annual	All developers	Tabletop exercise
Threat modeling	Per-feature	Feature team	Facilitated session
Security champion training	Quarterly	Security champions	Advanced workshop

Technical Spec