# DevSecOps — Part 6: Compliance Frameworks & Master Cheat Sheet > **Series:** DevSecOps (6 of 6) > **Part 1:** `01-fundamentals-and-shift-left.md` — Fundamentals & Shift-Left Security > **Part 2:** `02-sast-dast-sca.md` — SAST, DAST, SCA & Dependency Scanning > **Part 3:** `03-container-and-kubernetes-security.md` — Container & Kubernetes Security > **Part 4:** `04-secrets-management-and-iam.md` — Secrets Management & IAM > **Part 5:** `05-cicd-pipeline-security-and-supply-chain.md` — CI/CD & Supply Chain Security > **Part 6:** This file — Compliance Frameworks & Master Cheat Sheet > **Questions:** `questions.md` ## Table of Contents 1. [Why SREs Need to Understand Compliance](#why-sres-need-to-understand-compliance) 2. [Compliance vs Security — Not the Same Thing](#compliance-vs-security--not-the-same-thing) 3. [SOC 2](#soc-2) 4. [ISO 27001](#iso-27001) 5. [PCI-DSS](#pci-dss) 6. [GDPR and HIPAA — A Quick Contrast](#gdpr-and-hipaa--a-quick-contrast) 7. [How DevSecOps Tooling Maps to Compliance Controls](#how-devsecops-tooling-maps-to-compliance-controls) 8. [Audit Evidence — What Auditors Actually Want](#audit-evidence--what-auditors-actually-want) 9. [A Real-World Use Case: PCI-DSS for an E-Commerce Checkout](#a-real-world-use-case-pci-dss-for-an-e-commerce-checkout) 10. [A Real-World Use Case: SOC 2 for a SaaS Startup](#a-real-world-use-case-soc-2-for-a-saas-startup) 11. [Master Cheat Sheet: Every Tool in This Series](#master-cheat-sheet-every-tool-in-this-series) 12. [Master Cheat Sheet: One-Line Commands](#master-cheat-sheet-one-line-commands) 13. [Master Cheat Sheet: STRIDE, OWASP Top 10, CAP/SLSA Quick Recall](#master-cheat-sheet-stride-owasp-top-10-capslsa-quick-recall) 14. [Common Mistakes](#common-mistakes) 15. [Worked Practice Problems](#worked-practice-problems) 16. [Series Summary — The Complete DevSecOps Picture](#series-summary--the-complete-devsecops-picture) --- ## Why SREs Need to Understand Compliance You don't need to be a compliance expert to work in SRE/DevSecOps — but you'll constantly work *alongside* compliance requirements, and interviewers regularly probe whether you understand how technical controls actually map to the compliance frameworks a business is legally or contractually obligated to meet. ```mermaid graph LR Business["Business needs:
'We MUST be SOC 2
compliant to sell to
enterprise customers'"] --> Eng["Engineering translates this
into CONCRETE technical
controls: access logging,
encryption, RBAC, incident
response process..."] Eng --> Tools["...which is LITERALLY
everything covered in
Parts 1-5 of this series"] ``` **The simplest possible framing:** compliance frameworks are essentially checklists that say "prove you're doing good security practices" — and everything covered in this DevSecOps series (scanning, least privilege, secrets management, supply chain integrity) is exactly the substance that satisfies those checklists. Compliance isn't a separate discipline bolted on top of DevSecOps — it's largely **DevSecOps practices, formalized and audited.** --- ## Compliance vs Security — Not the Same Thing A genuinely important distinction, and a favorite "gotcha" framing in interviews. ```mermaid graph TD A["Compliance:
'Can we PROVE, to an
external auditor, that we
follow a defined set of
controls?'"] --> ANote["A checkbox exercise —
passing an audit does NOT
automatically mean you're
actually secure"] B["Security:
'Are we ACTUALLY resistant
to real attacks and failures?'"] --> BNote["The real, substantive goal —
you can be genuinely secure
WITHOUT being certified
against any specific
framework at all"] ``` **A strong, senior-level interview line:** "Compliance and security overlap heavily but aren't identical — you can pass a compliance audit with checkbox-driven controls that don't meaningfully reduce real risk, and conversely you can be genuinely secure without ever pursuing a specific certification. I treat compliance requirements as a useful *forcing function* and a shared vocabulary with auditors/customers, but I design for actual security first, and compliance evidence falls out of doing that well — not the other way around." --- ## SOC 2 **SOC 2 (System and Organization Controls 2)** is the most commonly referenced compliance framework for B2B SaaS companies, especially in the US — an independent auditor's report confirming a company follows defined controls across some or all of five **Trust Service Criteria**. ```mermaid graph TD SOC2["SOC 2 Trust Service
Criteria"] --> S1["Security
(mandatory —
every SOC 2 report
includes this)"] SOC2 --> S2["Availability"] SOC2 --> S3["Processing Integrity"] SOC2 --> S4["Confidentiality"] SOC2 --> S5["Privacy"] ``` | Criterion | Plain-English Meaning | DevSecOps Tie-In | |---|---|---| | **Security** | Protected against unauthorized access | Everything from Parts 1-5: RBAC, scanning, secrets management | | **Availability** | The system is actually up and usable when needed | Directly the SRE Fundamentals series — SLOs, redundancy, incident response | | **Processing Integrity** | The system processes data completely, accurately, and on time | Testing, monitoring, data validation | | **Confidentiality** | Data designated as confidential is protected | Encryption, access controls (Part 4) | | **Privacy** | Personal information is collected/used/disposed of properly | Data handling policies, often overlapping with GDPR | ### Type I vs Type II — A Commonly Tested Distinction ```mermaid graph LR T1["SOC 2 Type I:
'Are these controls
DESIGNED correctly,
at a single point in time?'"] --> T1Note["A snapshot — weaker
assurance, faster/cheaper
to obtain"] T2["SOC 2 Type II:
'Have these controls
ACTUALLY OPERATED
effectively over a period
of time (typically 6-12
months)?'"] --> T2Note["Ongoing evidence — much
stronger assurance, and
what most enterprise
customers actually require"] ``` **Interview-ready line:** "Type I answers 'do the controls exist, on paper, right now?' Type II answers 'did they actually work, continuously, over the past 6-12 months?' — which is why most serious enterprise customers specifically require Type II, not Type I. This distinction matters practically because it changes what evidence engineering needs to continuously produce (ongoing logs and records, not a one-time snapshot)." --- ## ISO 27001 **ISO 27001** is the dominant *international* information security management standard (much more globally recognized outside the US than SOC 2, which is more US-centric). ```mermaid graph TD ISO["ISO 27001"] --> ISMS["Centered on an ISMS:
Information Security
Management SYSTEM —
not just a list of controls,
but an ongoing PROCESS
of risk assessment,
treatment, and improvement"] ISMS --> Annex["Annex A: a catalog of
~93 specific security
controls (as of the
2022 revision) organizations
select from based on their
own risk assessment"] ``` **The key conceptual difference from SOC 2 worth naming:** SOC 2 is fundamentally "prove you follow a fixed set of trust criteria." ISO 27001 is fundamentally "prove you have an ongoing *system* for identifying and managing risk, and select/implement the specific controls that risk assessment says you need" — it's more process-and-risk-management-centric, rather than a fixed checklist. --- ## PCI-DSS **PCI-DSS (Payment Card Industry Data Security Standard)** applies specifically to any organization that stores, processes, or transmits **credit card data** — this is the single compliance framework most directly and concretely tied to hands-on engineering practices, making it a favorite interview topic. ```mermaid graph TD PCI["PCI-DSS: 12 Core
Requirements (grouped
into 6 goals)"] --> G1["Build & maintain a
secure network"] PCI --> G2["Protect cardholder data"] PCI --> G3["Maintain a vulnerability
management program"] PCI --> G4["Implement strong access
control measures"] PCI --> G5["Regularly monitor and
test networks"] PCI --> G6["Maintain an information
security policy"] ``` | PCI-DSS Concept | Direct DevSecOps Tie-In From This Series | |---|---| | Encrypt cardholder data in transit and at rest | Envelope encryption, TLS (Part 4) | | Restrict access on a need-to-know basis | RBAC, IAM least privilege (Parts 3 & 4) | | Regularly test security systems | SAST/DAST/SCA scanning, penetration testing (Part 2) | | Track and monitor all access to cardholder data and network resources | Audit logging, the Observability series | | Maintain a vulnerability management program | SCA, image scanning, patch management (Parts 2 & 3) | **A genuinely important, commonly-tested concept: network segmentation as a scope-reduction strategy.** PCI-DSS compliance requirements apply to your entire "cardholder data environment" (CDE) — but a well-architected system can dramatically shrink *how much* of the infrastructure falls "in scope" by properly isolating (via network policies, from Part 3) the specific components that actually touch card data from everything else. ```mermaid graph TD Bad["Flat network: EVERY service
can reach the payment
processing component"] --> BadScope["❌ ENTIRE infrastructure
is in PCI scope — every
service must meet the
full standard"] Good["Segmented network:
ONLY the payment service
can reach the card-data
component, via a tightly
controlled NetworkPolicy"] --> GoodScope["✅ Only the SEGMENTED
portion is in PCI scope —
dramatically less of the
infrastructure needs full
PCI-level controls"] ``` **A strong interview answer:** "The single highest-leverage architectural decision for PCI-DSS compliance is network segmentation — isolating the components that actually touch cardholder data so that most of your infrastructure falls outside the compliance boundary entirely. This directly reuses the Kubernetes NetworkPolicy and least-privilege concepts from Part 3, applied specifically to reduce audit scope, not just to reduce security risk." --- ## GDPR and HIPAA — A Quick Contrast Two more frameworks worth being able to distinguish at a glance, since they're commonly confused or conflated. | | GDPR | HIPAA | |---|---|---| | **Scope** | Personal data of EU residents (regardless of where the company is based) | Protected health information (PHI) in the US healthcare context | | **Type** | Privacy regulation (a law) | Privacy/security regulation (a law) | | **Key DevSecOps-relevant concept** | "Right to be forgotten" (must be able to actually delete a specific user's data on request — a real engineering challenge across distributed systems, backups, logs) | Strict access controls and audit logging for anyone who touches PHI | | **Notable engineering implication** | Data deletion/export capability must be a genuinely supported operation, not an afterthought | Every access to sensitive health data must be individually auditable | **A great, concrete interview example for GDPR's "right to be forgotten":** "If a user requests deletion under GDPR, that's not just a database row delete — it has to actually propagate to backups, logs, caches, analytics pipelines, and any downstream system that received a copy of that data. Designing for genuine, complete data deletion across a distributed system is a real, non-trivial engineering problem, not just a legal checkbox." --- ## How DevSecOps Tooling Maps to Compliance Controls A single, consolidated table tying the entire five-part series back to compliance — genuinely useful to have memorized as a synthesis answer. | DevSecOps Practice (This Series) | Compliance Control It Satisfies | |---|---| | SAST/DAST/SCA scanning (Part 2) | "Vulnerability management program" (PCI-DSS), "Security" criterion (SOC 2) | | Container/K8s security, RBAC (Part 3) | "Access control" (PCI-DSS, ISO 27001 Annex A) | | Secrets management, encryption (Part 4) | "Protect cardholder/sensitive data" (PCI-DSS), "Confidentiality" (SOC 2) | | Audit logging (touches Observability series) | "Track and monitor access" (PCI-DSS), evidence for SOC 2 Type II | | CI/CD hardening, supply chain security (Part 5) | "Secure development lifecycle" (ISO 27001 Annex A), general "Security" criterion | | Incident response process (Incident Management tutorial) | "Security" criterion (SOC 2), Requirement 12 (PCI-DSS) | | Blameless postmortems (SRE Fundamentals series) | Continuous improvement expectation (ISO 27001's ISMS) | --- ## Audit Evidence — What Auditors Actually Want A genuinely practical, often-overlooked point: passing an audit isn't about *doing* the right things — it's about being able to **prove**, with evidence, that you did them, continuously, over time. ```mermaid graph TD Control["Control: 'Access to
production is restricted
and reviewed'"] --> Evidence1["Evidence auditors want:
a SCREENSHOT/export of
the actual RBAC config"] Control --> Evidence2["Evidence: quarterly access
REVIEW records — who
reviewed, when, what
changed as a result"] Control --> Evidence3["Evidence: audit logs
SHOWING the control was
actually enforced (e.g. a
denied unauthorized access
attempt)"] ``` **A concrete, practical interview line:** "A common gap teams hit isn't that the control doesn't exist — it's that nobody kept evidence it was actually followed. If your access review process isn't documented (who reviewed, when, what they found), an auditor has no way to confirm it happened even if it genuinely did. This is exactly why mature teams treat compliance evidence generation as an automated *byproduct* of good tooling — e.g., every RBAC change is already in version-controlled git history with an audit trail, rather than a manual, easy-to-forget process." --- ## A Real-World Use Case: PCI-DSS for an E-Commerce Checkout A full, worked scenario tying everything together. ```mermaid flowchart TD Req["Requirement: PCI-DSS
compliant checkout flow"] --> Arch["Architecture Decision:
NEVER store raw card
numbers ourselves —
use a PCI-compliant
third-party processor
(e.g. Stripe) via tokenization"] Arch --> Token["Card data goes DIRECTLY
from the customer's browser
to Stripe — our own
servers only ever see a
non-sensitive TOKEN"] Token --> Scope["Result: our own PCI
compliance SCOPE shrinks
dramatically (SAQ A instead
of the full standard) —
we never touch raw card
data at all"] ``` **The single strongest, most practical engineering lesson from this scenario:** the *cheapest* way to comply with PCI-DSS is often architectural — **avoid ever touching raw cardholder data in the first place** (using tokenization via a PCI-compliant processor) — rather than trying to build and audit a fully PCI-compliant system yourself. This is a genuinely strong, senior-level answer to "how would you architect a compliant checkout flow." --- ## A Real-World Use Case: SOC 2 for a SaaS Startup ```mermaid flowchart TD Start["Startup needs SOC 2
Type II to close enterprise
deals"] --> Gap["Gap analysis: what controls
exist today vs. what's
required?"] Gap --> Findings["Findings: no formal access
review process, no
documented incident
response plan, secrets
hardcoded in some services"] Findings --> Remediate["Remediation, directly
reusing THIS series:
- Least-privilege IAM (Part 4)
- Vault for secrets (Part 4)
- Documented incident
response (Incident Mgmt tutorial)
- Automated CI security
scanning (Parts 2-3)"] Remediate --> Evidence["Collect evidence
continuously for 6-12 months
(the Type II observation
period)"] Evidence --> Audit["External auditor reviews
evidence, issues SOC 2
Type II report"] ``` **Why this scenario is worth having ready:** it demonstrates that pursuing a compliance certification is, in practice, largely a project of *actually implementing* the DevSecOps practices from Parts 1-5 of this series, then formalizing evidence collection around them — reinforcing the "compliance is largely DevSecOps, formalized" framing from the start of this tutorial. --- ## Master Cheat Sheet: Every Tool in This Series A single consolidated reference table — genuinely useful both for interview prep and as a real, practical bookmark. | Category | Tool | What It Does | |---|---|---| | SAST | Semgrep | Pattern/data-flow-based source code scanning | | SAST | SonarQube | Code quality + security scanning, Quality Gates | | DAST | OWASP ZAP | Attacks a running app like a real attacker | | SCA | Snyk | Dependency vulnerability scanning + monitoring | | SCA | Dependabot | Automated PRs to bump vulnerable dependencies | | SCA | pip-audit / npm audit | Built-in, quick dependency vulnerability checks | | Container scanning | Trivy | Image, filesystem, IaC, and SBOM scanning (very broad) | | Container scanning | Grype | Focused container/filesystem vulnerability scanning | | Secret scanning | Gitleaks | Git history + working tree secret detection | | Secret scanning | TruffleHog | Secret detection WITH live verification | | Secrets management | HashiCorp Vault | Dynamic secrets, centralized secret storage, PKI | | Secrets management | AWS Secrets Manager | Managed, AWS-native secret storage + rotation | | IaC scanning | tfsec | Terraform-specific misconfiguration scanning | | IaC scanning | Checkov | Broad IaC scanning (Terraform, CFN, K8s, Docker) | | K8s policy | OPA / Gatekeeper | Policy-as-code admission control | | K8s runtime security | Falco | Behavior-based runtime threat detection | | SBOM generation | Syft | Generates SBOMs from source or images | | Artifact signing | cosign (Sigstore) | Signs and verifies container images/artifacts | | Supply chain maturity | SLSA framework | Tiered supply chain integrity maturity model | --- ## Master Cheat Sheet: One-Line Commands ```bash # --- SAST --- semgrep --config=p/security-audit --error . # --- SCA --- npm audit --audit-level=high pip-audit snyk test # --- Container image scanning --- trivy image --exit-code 1 --severity CRITICAL,HIGH myapp:latest # --- Secret scanning --- gitleaks detect --source . --verbose trufflehog git file://. --only-verified # --- IaC scanning --- tfsec . checkov -d . # --- SBOM generation --- syft myapp:latest -o cyclonedx-json > sbom.json # --- Artifact signing / verification --- cosign sign myregistry.io/myapp:latest cosign verify myregistry.io/myapp:latest # --- Kubernetes RBAC auditing --- kubectl auth can-i delete secrets --as=system:serviceaccount:ns:sa-name -n ns # --- DAST (staging only, never production) --- docker run -t zaproxy/zap-stable zap-baseline.py -t https://staging.example.com ``` --- ## Master Cheat Sheet: STRIDE, OWASP Top 10, CAP/SLSA Quick Recall ```mermaid graph TD Cheat["Quick Recall Structures"] --> STRIDE["STRIDE:
Spoofing, Tampering,
Repudiation, Info Disclosure,
Denial of Service,
Elevation of Privilege"] Cheat --> OWASP["OWASP Top 10 (2021):
A01 Broken Access Control
A02 Crypto Failures
A03 Injection
A04 Insecure Design
A05 Security Misconfig
A06 Vulnerable Components
A07 Auth Failures
A08 Data Integrity Failures
A09 Logging Failures
A10 SSRF"] Cheat --> SLSA["SLSA Levels:
L1 Scripted build
L2 Hosted + signed provenance
L3 Tamper-resistant platform
L4 Two-person review + hermetic"] ``` | Quick Question | Quick Answer | |---|---| | SAST looks at? | Source code, without running it | | DAST looks at? | A running app, from the outside | | SCA looks at? | Third-party dependencies vs known CVEs | | Highest-value single mitigation for a leaked secret? | Immediate rotation | | Default Kubernetes pod-to-pod network policy? | Allow everything (no isolation) — must be explicitly restricted | | Are Kubernetes Secrets encrypted by default? | No — only base64-encoded | | Vault's "killer feature"? | Dynamic, short-lived, auto-expiring secrets | | SolarWinds attack targeted what? | The build/CI pipeline itself, not the application | | Best PCI-DSS scope-reduction strategy? | Never touch raw card data — use tokenization via a compliant processor | | SOC 2 Type I vs Type II? | Type I = point-in-time design check. Type II = sustained operation over 6-12 months | | Compliance vs security — which is the checkbox exercise? | Compliance (passing an audit ≠ automatically secure) | --- ## Common Mistakes | Mistake | Why It's Wrong | Fix | |---|---|---| | Treating "we're SOC 2 compliant" as proof of genuine security | Compliance is a checkbox exercise against a defined standard, not a guarantee of real-world resistance to attacks | Design for actual security first; let compliance evidence fall out of doing that well | | Building a fully custom, in-house payment processing flow to "save on processor fees" | Massively expands PCI-DSS audit scope and risk, for often-marginal cost savings | Use tokenization via a compliant processor to shrink scope wherever possible | | Doing the right security practices but keeping no evidence/records | Auditors (and future incident investigations) can't confirm a control was actually followed if there's no record | Automate evidence generation as a byproduct of good tooling (version-controlled configs, audit logs) | | Assuming GDPR only applies to companies based in the EU | GDPR applies based on WHOSE data you process (EU residents), regardless of where your company is located | Assess GDPR applicability based on your user base, not your company's location | | Confusing "we have a control" with "we can prove the control worked continuously" | This is exactly the Type I vs Type II gap | Understand which level of assurance is actually required for your compliance goal | --- ## Worked Practice Problems **Problem 1:** A startup wants to sell to enterprise customers who require SOC 2 Type II. They currently have decent security practices but no formal documentation or evidence trail. How long should they expect this to take, and why can't they get it faster? *Answer:* SOC 2 Type II specifically requires demonstrating that controls operated effectively over a sustained observation period — typically 6-12 months — so there's no way to shortcut this with better documentation alone; the auditor needs to see evidence the controls were actually followed continuously over that real time window, not just designed correctly on day one. They could pursue a SOC 2 Type I report faster (a point-in-time design assessment) as an interim step, but most enterprise customers specifically require Type II for the stronger assurance it provides. **Problem 2:** An e-commerce company is deciding whether to build their own PCI-DSS-compliant card storage system or use a third-party processor with tokenization. What's the strongest engineering argument for tokenization? *Answer:* Tokenization means raw cardholder data never touches the company's own infrastructure at all — it flows directly from the customer's browser to the compliant processor, and the company's systems only ever handle a non-sensitive token. This dramatically shrinks the PCI-DSS compliance scope (often down to the simpler SAQ A self-assessment tier instead of the full standard), meaning far less infrastructure needs to meet the complete set of PCI controls, less audit surface area, and significantly less risk exposure if any other part of the system is ever compromised — since there's no actual card data present to steal in the first place. **Problem 3:** During a SOC 2 audit, the auditor asks for evidence that access to production databases is reviewed quarterly. The team confirms they do this reliably every quarter, but has no records of it. What's the actual gap, and how would you fix it going forward? *Answer:* The gap isn't the practice itself — it's the complete absence of **evidence** that the practice actually happened, which from an auditor's perspective is indistinguishable from the practice never having occurred at all. Fix: formalize the review as a documented, trackable process — e.g., a ticket created each quarter with the reviewer, date, and findings recorded, or better, an automated report generated from the actual RBAC/IAM configuration showing exactly who had access and confirming it was reviewed, stored somewhere durable and easily exportable for future audits. --- ## Series Summary — The Complete DevSecOps Picture This closes out the full six-part DevSecOps series. The complete arc: ```mermaid graph TD P1["Part 1: Fundamentals —
shift-left philosophy,
threat modeling (STRIDE),
shared responsibility"] --> P2 P2["Part 2: SAST/DAST/SCA —
catching code, runtime,
and dependency vulnerabilities"] --> P3 P3["Part 3: Container/K8s —
image hardening, RBAC,
network policies, runtime
detection (Falco)"] --> P4 P4["Part 4: Secrets/IAM —
the highest-stakes category;
dynamic secrets, least
privilege, workload identity"] --> P5 P5["Part 5: CI/CD & Supply
Chain — the pipeline ITSELF
as a target; SBOM, signing,
SLSA"] --> P6 P6["Part 6: Compliance —
how all of the above maps
to SOC 2, ISO 27001,
PCI-DSS, GDPR"] ``` **The single most important takeaway to carry into an interview:** DevSecOps is not a list of tools to memorize — it's a **layered, defense-in-depth discipline** where each layer (code, dependencies, containers, secrets, pipeline, compliance) catches what the layers before and after it structurally cannot. A strong candidate can walk through this entire pipeline end-to-end, naming the specific threat each stage addresses and the specific tool category that addresses it — exactly as demonstrated in the "Secure Pipeline Blueprint" diagram in Part 5. See `questions.md` in this folder for the full interview question bank covering all six parts of this series.