SnowOps — DevSecOps Readiness Plan¶

Status: Backlog — build on demand or when bandwidth allows. Decision: D72 (2026-06-16) Purpose: Inventory of DevSecOps-specific assets to create so SnowOps can deliver a DevSecOps engagement when a client asks. No asset in this document is scheduled for immediate development — they are queued for when demand arrives or bandwidth opens up.

What Already Covers DevSecOps¶

The compliance infrastructure overlaps heavily with DevSecOps. These existing assets are reusable in a DevSecOps offering with minimal rework:

Domain	Existing Assets	DevSecOps Value
Shift-left scanning	D1 (pre-commit), D2 (PR quality gate), I1 (image scan), I2 (dependency scan), I3 (CodeQL SAST)	Core of any DevSecOps pipeline — already production-grade
Policy-as-Code	D3/X3 (OPA/Conftest), D4/X4 (Kyverno), D5 (waiver engine)	Terraform + K8s policy enforcement with exception management
Container security	C2 (build/sign/SBOM), I1 (image scan), D4 (admission control)	Build-time + deploy-time container hardening
DAST	I4 (OWASP ZAP)	Dynamic application security testing
SIEM / SOAR	J3 (Sentinel), K3 (SOAR playbooks), J4 (alert rules)	Detection + automated response
Incident response	K1 (IR runbooks), K2 (on-call), K4 (PIR), K5 (tabletop exercises)	Full IR lifecycle
Drift / remediation	S1 (drift detector), S3 (auto-remediation playbooks)	Continuous posture enforcement
Identity	H1–H7 (Entra baseline, PIM, CA, access reviews, SPN rotation)	Zero-trust identity plane
Evidence	E0–E6 (snapshots, Vanta/Drata, evidence sync, access reviews)	Audit-ready evidence chain
Secrets management	F5 (Key Vault), gitleaks (D1/D2)	Secrets at rest + secrets in code
Network hardening	N1–N7 (landing zone, firewall, WAF, DDoS, zero-trust ref)	Defense-in-depth network
Data protection	M1–M7 (encryption, TLS, CMK, Purview, DLP, data residency)	Data-layer security
Vulnerability mgmt	I5 (Defender ticketer), I6 (patch compliance), I7 (CVE triage + SLA)	Full vuln lifecycle
Change management	R1–R4 (PR templates, changelog, emergency change, CAB)	Controlled change processes
Compliance reporting	S2 (dashboard), S4 (scorecard), V4 (compliance manual), V5 (posture report)	Client-facing evidence

Bottom line: ~70% of a DevSecOps engagement is already built. What's missing is the DevSecOps-specific packaging, a few technical differentiators, and the tool-agnostic adapter layer for client flexibility.

DevSecOps Backlog — Items to Create¶

Tier 1 — GTM-ready (create before first DevSecOps sale)¶

These items are enough to have a sales conversation and deliver a scoped engagement.

DS1 — DevSecOps Service Package Definition¶

Where: docs/gtm/ (Y-series extension) Effort: ~1 day (documentation only) Depends on: Nothing

Define the DevSecOps offering as a service package: - Scope document: what's included at each tier (Quick-Win / Baseline / Advanced) - Deliverables matrix mapping existing A–Z assets to DevSecOps outcomes - Client responsibilities and prerequisites - Pricing structure (follows §3.8 fixed-price model) - Differentiation from the compliance packages (buyer = CISO/Head of Engineering, not GRC; outcome = secure SDLC, not audit certificate)

Why first: Without this, there's nothing to sell. This drives which technical assets to prioritize.

DS2 — DevSecOps Maturity Assessment Tool¶

Where: apps/devsecops-assessment/ (new app, E0/B6 mold) Effort: ~2–3 days Depends on: Nothing (standalone evaluator)

OWASP SAMM or DSOMM-based questionnaire tool: - Pure evaluator behind a collector seam (B6 pattern: FixtureCollector + optional live) - Scored report per domain: Governance, Design, Implementation, Verification, Operations - Current state vs target state gap analysis - Outputs: markdown + HTML + optional PDF (reuse the S4/G3 Pandoc-spawn pattern) - Drives scoping conversations and upsells (the DevSecOps counterpart of the G-series Discovery Audit for compliance)

Why: The G-series Discovery Audit is the compliance wedge. DS2 is the DevSecOps wedge — run it during a prospect call, hand them a maturity score, show what moves the needle.

DS3 — Threat Modeling Templates + Runbook¶

Where: docs/runbooks/threat-modeling/ + templates/threat-models/ Effort: ~1 day (documentation + d2lang templates) Depends on: Nothing

STRIDE-based threat modeling artifacts: - Data flow diagram templates using d2lang (already in the stack via V2) - Facilitation runbook: how to run a threat modeling session, outputs, cadence - Threat model review checklist for PRs (a checklist, not a gate — threat models are human exercises, not automatable scans) - Template for recording findings + mitigations + residual risks

Why: Every DevSecOps engagement starts with "what are we protecting?" Threat modeling is the answer. Templates make it repeatable.

Tier 2 — Technical differentiators (build when first engagement is signed)¶

These close real technical gaps and differentiate from competitors.

DS4 — SLSA Build Provenance (Level 2/3)¶

Where: Enhancement to C2 (container-build-sign.yml) Effort: ~1 day Depends on: C2 (already shipped)

Add slsa-github-generator to the container-build-sign pipeline: - Produces verifiable SLSA provenance attestation attached to OCI image - Complements existing Notation v2 signing (C2) and Syft SBOM (C2) - Enterprise clients increasingly require SLSA Level 2+ for supply chain security - Pure CI addition — no new module or app

DS5 — Runtime Security (Falco) for AKS¶

Where: gitops/apps/falco.yaml + modules/azure/falco-rules/ or policy/falco/ Effort: ~2 days Depends on: F3 (AKS), F8 (ArgoCD), J3 (Sentinel)

Deploy Falco via the existing ArgoCD app-of-apps (F8): - Runtime threat detection for anomalous container behavior, privilege escalation, network exfil - Custom rule pack mirroring Kyverno's D4 posture (defense-in-depth: D4 blocks at admission, Falco detects at runtime) - Alert routing to Sentinel (J3) via Log Analytics (J1) — wire Falco syslog → J1 → J3 - Kyverno covers admission; Falco covers runtime — enterprise clients expect both

DS6 — API Security Scanning¶

Where: Enhancement to D2 (quality-gates.yml) + policy/api-security/ Effort: ~1 day Depends on: D2 (already shipped)

Add API spec linting to the PR quality gate: - Spectral for OpenAPI spec validation (naming, auth requirements, data exposure) - New job in quality-gates.yml (D2) — only fires when .openapi.yaml / .swagger.json files change - SARIF output → GitHub Code Scanning (same pattern as tfsec/gitleaks) - Many DevSecOps clients have API-first architectures — common ask

DS7 — Dependency-Track Integration¶

Where: apps/dependency-track/ or documentation for self-hosted instance Effort: ~2 days Depends on: C2 (SBOM generation already done)

OWASP Dependency-Track as a persistent SCA platform: - Consume SBOM artifacts from C2 (Syft already generates SPDX + CycloneDX) - Policy-based alerts when new Critical/High CVEs hit existing dependencies - Dashboard for dependency risk posture over time - Closes the loop: C2 generates SBOMs → DS7 continuously monitors them - Can be self-hosted on AKS or SaaS — document both paths

DS8 — Security Metrics Dashboard¶

Where: Extension to J5 (grafana-dashboards/dashboards/snowops-devsecops-metrics.json) Effort: ~1 day Depends on: J5 (already shipped), E0, I7

Developer/engineering-leadership-facing metrics: - Mean Time to Remediate (MTTR) from I7 CVE triage SLA data - Open finding counts by severity (from Defender/E0 posture data) - Policy violation rate and trend (from D3/D4 enforcement data) - Vulnerability aging distribution - Passes the existing J5 offline dashboard gate (no new infrastructure)

Tier 3 — Advanced / client-specific (build for mature clients)¶

DS9 — Pen Test Scope + Scheduling Templates¶

Where: docs/runbooks/pentest/ + templates/pentest/ Effort: ~1 day (documentation only) Depends on: Nothing

Templates for coordinated penetration testing: - Scoping questionnaire, rules of engagement, report template - Links to I7 (CVE triage) for findings intake, K1 (IR) for critical findings - Scheduling automation via E7 (TicketPlatform) for recurring pen tests

DS10 — Security Chaos Engineering Runbooks¶

Where: docs/runbooks/security-chaos/ Effort: ~1 day (documentation + fixture scenarios) Depends on: X1 (sandbox), D4, D3, F5

Fault injection experiments that validate security controls fire correctly: - Deploy a privileged pod → should be blocked by Kyverno (D4) - Deploy an unsigned image → should be rejected (D4 image verification) - Access Key Vault without managed identity → should be denied - Apply Terraform plan violating an OPA rule → should fail (D3) - Submit a PR with a hardcoded secret → should be caught (D1/D2) - Reuse the existing sandbox (X1) and Terratest harness (X2) for execution - Strong differentiator — few vendors offer this

Tool-Agnostic Scanning Architecture (D72)¶

The Problem¶

SnowOps currently hardcodes specific security tools (Trivy, CodeQL, gitleaks, Kyverno, etc.). Clients may have organizational mandates or existing contracts with alternative vendors doing the same job. Examples: - "We use Prisma Cloud, not Trivy" - "We use SonarQube, not CodeQL" - "We use OPA/Gatekeeper, not Kyverno" - "We use Splunk, not Sentinel"

Existing Patterns to Extend¶

The repo already solves this for three domains: 1. Cloud providers — modules/_contracts/ (F0): typed interfaces; Azure implements today, AWS/GCP implement the same contracts later 2. Compliance platforms — EvidencePlatform interface (E1): Vanta (E2) and Drata (E3) are swappable adapters behind the same contract 3. Ticketing platforms — TicketPlatform interface (E7): GitHub Issues, Jira, Linear, ADO Boards are swappable adapters behind the same contract

The Pattern: Scanner Contracts¶

Apply the same contract/adapter pattern to security tooling. Each tool category gets a Scanner Contract — a standardized output format the pipeline consumes. The tool invocation is pluggable; the downstream consumption is fixed.

Key insight: most CI security tools already converge on standard output formats:

Category	Output Standard	Current Tool	Common Alternatives
Container/Image Scanning	SARIF	Trivy (I1)	Prisma Cloud, Snyk Container, Aqua, Qualys
SAST	SARIF	CodeQL (I3)	SonarQube, Semgrep, Checkmarx, Veracode
DAST	SARIF	OWASP ZAP (I4)	Burp Suite Enterprise, Qualys WAS, HCL AppScan
IaC Scanning	SARIF	tfsec + Checkov (D1/D2)	Prisma Cloud/Bridgecrew, Snyk IaC, KICS
SCA / Dependencies	SARIF	Dependabot + Trivy (I2)	Snyk, Mend/WhiteSource, Black Duck
Secret Scanning	SARIF	gitleaks (D1/D2)	TruffleHog, GitGuardian, Talisman
SBOM Generation	SPDX / CycloneDX	Syft (C2)	Trivy SBOM, CycloneDX tools
K8s Admission Policy	Native (cluster-level)	Kyverno (D4)	OPA/Gatekeeper, Prisma Cloud
SIEM	Native (platform-level)	Sentinel (J3)	Splunk, Elastic SIEM, Datadog Security

Implementation Approach¶

For CI/CD tools (SARIF-based — I-series, D-series, C2):

The pipeline workflows already consume SARIF and upload to GitHub Code Scanning. Making them tool-agnostic requires:

Reusable scanner wrapper action — a composite GitHub Action (or shell script) per category that:
Accepts a scanner input (e.g., trivy, snyk, prisma)
Installs/invokes the selected tool with the right flags
Normalizes output to SARIF at a known path
The calling workflow consumes that SARIF uniformly
Per-client configuration — a scanner-config.yaml (or repo variable) that declares which tool the client uses per category. Defaults to the SnowOps-preferred tool.
Adapter implementation — one adapter per supported tool per category. Start with the current tool as the only adapter; add alternatives when a client needs one.

For infrastructure-level tools (K8s policy, SIEM):

These are deeper substitutions — different modules, not just different CLI tools. The F0 contracts pattern applies directly:

Kyverno → OPA/Gatekeeper: The D4 policy intent (no privileged containers, require resource limits, etc.) is tool-agnostic; the implementation is Kyverno YAML vs Rego. Ship a policy/opa-gatekeeper/ alternative that enforces the same rules. Document which to choose in the engagement scoping (DS1).
Sentinel → Splunk/Elastic: The J3/J4 detection rules (KQL queries) are Azure-native. For Splunk/Elastic clients, the detection intent (same threat domains: identity/privilege/network/data-exfil) would need SPL/KQL translations. This is M5-class work — defer until demand proves it.

Priority: What to Build When¶

Priority	Item	Trigger
1	Document the pattern (this section)	Done (D72)
2	SARIF-normalized scanner wrapper for I1 (image scan)	First client requesting non-Trivy
3	SARIF-normalized scanner wrapper for I3 (SAST)	First client requesting non-CodeQL
4	SARIF-normalized scanner wrapper for D1/D2 (IaC + secrets)	First client requesting non-tfsec/gitleaks
5	OPA/Gatekeeper alternative policy bundle	First client on Gatekeeper
6	Non-Sentinel SIEM integration	First multi-cloud / non-Azure-native client

Build rule: Don't pre-build adapters. Build each adapter when a signed client needs it. The architecture makes adding one a ~half-day task per tool.

Recommended Build Sequence¶

Phase 1 — GTM-ready (before first DevSecOps outreach):
  DS1 (service package definition) → DS3 (threat modeling templates)

Phase 2 — Pre-sales tooling (before first signed engagement):
  DS2 (maturity assessment tool)

Phase 3 — Technical delivery (when first engagement is signed):
  DS4 (SLSA provenance) → DS6 (API scanning) → DS8 (security metrics)

Phase 4 — Differentiation (for mature clients):
  DS5 (Falco runtime) → DS7 (Dependency-Track)

Phase 5 — Advanced (on demand):
  DS9 (pen test templates) → DS10 (security chaos)

Tool-agnostic adapters: build each one when a client needs it (never pre-build).

Phase 1 alone takes ~2 days and is enough to have a sales conversation. Phase 2 adds the DevSecOps counterpart to the G-series Discovery Audit. Phases 3–5 are delivery-time or on-demand.

Relationship to Existing Packages¶

Existing Package	DevSecOps Overlay
Quick-Win `[QW]`	Add: DS3 threat modeling checklist as a bonus deliverable
Baseline `[B]`	Already includes shift-left scanning (D1/D2/I1–I3), policy gates (D3/D4), container security (C2). DevSecOps framing = same assets, different narrative
Advanced `[A]`	Already includes SIEM (J3), SOAR (K3), full vuln mgmt (I4–I7), evidence chain (E0–E6). Add: DS4 (SLSA), DS5 (Falco), DS8 (metrics)
DevSecOps-specific	DS1 package + DS2 assessment + DS3 threat modeling + tool-agnostic adapters as needed

The key insight: most DevSecOps delivery repackages existing assets under a different narrative. The genuinely new technical work is small (DS4–DS8); the packaging and assessment tooling (DS1–DS3) is the real differentiator.