CSSLP Exam Prep · Topic 5 of 5

Deployment, Operations & Supply Chain

Secure Deployment · DevSecOps · Container Security · SBOM · Supply Chain Attacks · Patch Management

Study with Practice Tests →

Secure Software Deployment, Operations & Supply Chain

Domains 7 & 8 of the CSSLP CBK (~23% combined). These domains cover how secure software is deployed, operated, maintained, and how the integrity of the software supply chain is protected throughout the lifecycle.

~23% of Exam · Domains 7 & 8

CSSLP 8-Domain Overview

DomainWeightKey Topics
1 — Secure Software Concepts~10%CIA triad, design principles, security governance
2 — Secure Software Requirements~14%Security requirements elicitation, use/misuse cases, privacy
3 — Secure Software Architecture & Design~14%Threat modeling, STRIDE, security patterns, Zero Trust
4 — Secure Software Implementation~14%Secure coding, OWASP Top 10, injection, memory safety
5 — Secure Software Testing~14%SAST, DAST, IAST, pen testing, fuzzing
6 — Secure Software Lifecycle Management~11%SDLC models, risk management, security metrics, EOL
7 — Secure Software Deployment, Operations & Maintenance~12%Change management, patch mgmt, IR, config hardening
8 — Supply Chain & Software Acquisition~11%SBOM, third-party risk, SLSA, dependency management

Core Concept Cards

Secure Deployment

  • Environment separation: dev / staging / prod
  • Change management & 4-eyes principle
  • Configuration hardening before go-live
  • Immutable infrastructure pattern

Patch Management

  • Vulnerability SLAs by severity (Critical 24–48 hrs)
  • Patch testing in staging before production
  • Rollback plan required for every patch
  • Compliance rate metric: % patched within SLA

Incident Response

  • IR lifecycle: Prepare → Identify → Contain → Eradicate → Recover → Learn
  • Forensic evidence preservation before remediation
  • Post-mortem and control improvements

Container Security

  • Minimal base images: Alpine, distroless
  • Run as non-root user (USER nonroot in Dockerfile)
  • Image scanning: Trivy, Snyk Container, Clair
  • Never bake secrets into images

SBOM

  • Machine-readable inventory of all software components
  • Formats: SPDX (ISO/IEC 5962) and CycloneDX (OWASP)
  • US Executive Order 14028 mandates SBOM for federal software
  • Enables rapid CVE impact assessment across products

Supply Chain Attacks

  • SolarWinds (2020): compromised build system, malicious update
  • Log4Shell (CVE-2021-44228): critical RCE in widely-used library
  • XZ Utils (CVE-2024-3094): malicious maintainer inserted backdoor
  • Bypass perimeter security via trusted software channels

🎯 Exam Tips — Domains 7 & 8

  • Supply chain security is a growing exam emphasis — expect scenario questions on SBOM and SLSA
  • SBOM is mandated by US Executive Order 14028 (2021) for software sold to federal agencies
  • Zero trust extends to the build pipeline — treat every pipeline component as potentially compromised
  • Know the IR phases in order and what actions belong in each phase (especially Containment vs. Eradication)
  • Immutable infrastructure = deploy new images rather than patching running systems

Secure Deployment & Operations

Covers the practices that ensure software reaches production securely and is operated and maintained with integrity throughout its operational life.

Secure Deployment Checklist

  • Environment separation: dev/staging/prod with separate credentials, configs, and access controls
  • Configuration hardening: disable unused features/ports/services, remove default accounts, enforce TLS
  • Secret management: inject secrets at runtime via secrets manager — never bake into container images or config files
  • Change management: 4-eyes principle, CAB approval for production changes, rollback plan required
  • Least privilege for deployment pipeline: deploy accounts have minimum permissions needed
  • Immutable infrastructure: deploy new images rather than patching running systems (cattle not pets)

Patch Management

SeverityCVSS ScoreSLAProcess
Critical9.0–10.024–48 hoursEmergency patch, skip normal change window
High7.0–8.97 daysExpedited change process
Medium4.0–6.930 daysNormal release cycle
Low<4.090 daysPlanned maintenance window
  • Vulnerability scanning on schedule (weekly/monthly) and on CVE disclosure
  • Patch testing in staging before production rollout — verify functionality and security
  • Rollback plan for every patch deployment — be ready to revert within defined RTO
  • Emergency patching process for zero-day vulnerabilities bypasses normal CAB process
  • Patch compliance rate metric: percentage of systems patched within SLA — track monthly

Incident Response Lifecycle for Software

1 — Preparation

IR plan, runbooks, security contacts, forensic tools ready before an incident. Tabletop exercises.

2 — Identification

Detect the incident via SIEM alert, vulnerability report, or user report. Triage and classify severity.

3 — Containment

Isolate affected systems, preserve forensic evidence, stop spread. Do NOT wipe yet — evidence needed.

4 — Eradication

Remove malware/backdoor, patch vulnerability, revoke compromised credentials. Eliminate root cause.

5 — Recovery

Restore from clean backup, verify integrity, resume operations with enhanced monitoring.

6 — Lessons Learned

Post-mortem within 2 weeks, improve controls, update IR plan, share threat intelligence.

Configuration Management

Infrastructure as Code (IaC)

Terraform, CloudFormation — all configs stored in version control. Changes reviewed like code. Enables repeatable, auditable deployments.

Configuration Drift Detection

Ansible, Chef, Puppet compare actual vs desired state continuously. Alert or auto-remediate when drift detected.

CIS Benchmarks

Hardening standards for OS, cloud platforms, containers. Baseline for secure configuration. Audited via CIS-CAT scanner.

IaC Security Scanning

tfsec and Checkov scan Terraform/CloudFormation templates for misconfigurations before they reach production.

CI/CD & Container Security

Securing the build pipeline and container ecosystem is essential to preventing supply chain attacks and ensuring only trusted, verified software reaches production.

CI/CD Pipeline Security Stages

Pre-commit Build Test Pre-release Deploy Runtime
StageSecurity ControlsTools
Pre-commitGit hooks, secret scanningtruffleHog, git-secrets, GitGuardian
BuildSAST, SCA (dependency scan), image scanningSemgrep, Snyk, Trivy
TestDAST, IAST, security regression testsOWASP ZAP, Burp Suite Enterprise
Pre-releasePen test sign-off, IaC scanning, SBOM generationtfsec, Checkov, CycloneDX
DeploySigned artifacts, attestation, deployment controlscosign/Sigstore, OPA/Gatekeeper
RuntimeRASP, WAF, anomaly detection, SIEMFalco, Wazuh, Datadog

Artifact Integrity & SLSA Framework

Code & Artifact Signing

  • Sign commits with GPG — verify author identity in version history
  • Sign container images with Sigstore/cosign — verify provenance before deployment
  • Sign release artifacts — prevents tampered artifacts reaching users
SLSA LevelRequirementsGuarantees
L0 — NoneNo requirementsNo guarantees
L1 — DocumentedBuild process documentedBasic provenance available
L2 — HostedBuild service generates provenanceTamper-evident provenance
L3 — HardenedNon-falsifiable provenanceSource and build integrity
L4 — Two-partyTwo-person review, hermetic buildHighest assurance, no single point of compromise

Container Security Best Practices

Minimal Base Images

Use Alpine or distroless images — drastically smaller attack surface. Fewer packages = fewer CVEs to patch. Distroless has no shell, making exploitation harder.

Run as Non-Root

Add USER nonroot in Dockerfile. Container escape or RCE as root gives attacker host-level access. Non-root limits blast radius.

No Privileged Mode

Avoid the --privileged flag — grants excessive host access. Use specific capabilities (--cap-add) rather than full privilege escalation.

Image Scanning

Trivy, Snyk Container, Clair scan for CVEs in base image layers and application dependencies. Scan at build time, in registry, and at runtime for new CVEs.

Read-Only Filesystem

Mount container filesystem as read-only where possible — prevents runtime modification. Use tmpfs volumes for writable scratch space when needed.

Signed Images & Admission Control

Sign images with cosign/Sigstore. Use Kubernetes admission controllers (OPA/Gatekeeper) to enforce only signed, scanned images can be deployed.

Secrets in CI/CD

Rules for Secrets in Pipelines

  • Never store secrets in source code, Dockerfiles ENV instructions, or committed env files
  • Use CI platform secrets (GitHub Actions Secrets, GitLab CI Variables) — masked in logs
  • Use OIDC-based short-lived credentials for cloud auth — no long-lived static keys
  • Rotate secrets regularly; detect and alert on unusual secret access patterns
  • Scan repositories for accidentally committed secrets (truffleHog, git-secrets, GitGuardian)

Supply Chain Security

The software supply chain includes source code, build tools, dependencies, CI/CD pipeline, deployment infrastructure, and update mechanisms. Any compromise in this chain can inject malicious code into the final product.

Major Supply Chain Attack Examples

SolarWinds (2020) — Build System Compromise

Attackers compromised SolarWinds' build system. Malicious code injected into Orion software updates affected 18,000+ organizations including US government agencies. Signed by SolarWinds' own certificate — bypassed all signature verification.

Log4Shell / Log4j (CVE-2021-44228, 2021) — Dependency Vulnerability

Critical RCE vulnerability in the widely-used Log4j library affected millions of applications. Fixed via SCA scanning to detect affected versions + rapid patching within SLAs. Demonstrated the cascading risk of transitive dependencies.

XZ Utils Backdoor (CVE-2024-3094) — Malicious Maintainer

Sophisticated social engineering attack — a malicious actor became a trusted maintainer of the xz compression library over many months, then inserted a backdoor targeting SSH servers on Linux. Caught before widespread deployment.

Codecov Breach (2021) — CI/CD Script Tampering

Attackers modified Codecov's bash uploader script, exfiltrating CI/CD environment variables (secrets) from thousands of organizations that piped the script directly into bash without verification.

SBOM — Software Bill of Materials

What is an SBOM?

A machine-readable inventory of all components in a software product — libraries, frameworks, open-source dependencies, versions, licenses, and relationships.

  • SPDX (Software Package Data Exchange): ISO/IEC 5962, Linux Foundation standard, widely adopted for license compliance
  • CycloneDX: OWASP standard, security-focused, rich vulnerability metadata, increasingly preferred for security tooling
  • US EO 14028 (2021): mandates SBOM for software sold to federal agencies
  • Generated at build time; must be kept current with each release
  • Enables rapid impact assessment when a new CVE drops — instantly identify affected products
  • VEX (Vulnerability Exploitability eXchange): companion doc stating which CVEs are NOT exploitable in your context

Third-Party Risk Management

Vendor Assessment

  • Security questionnaires before onboarding
  • Review SOC 2 Type II reports
  • Review pen test results and certifications
  • Audit rights in contract

Contractual Requirements

  • Incident notification SLAs (e.g., 24-hr notify)
  • Right to audit and assess vendor security
  • Data handling and retention requirements
  • Liability and indemnification clauses

Open Source Risk

  • License compliance: GPL virality risk
  • Maintainer abandonment risk
  • Hidden vulnerabilities in popular packages
  • Dependency confusion and typosquatting attacks

Dependency Management Best Practices

PracticePurposeImplementation
Pin exact versionsPrevent unexpected updatespackage-lock.json, go.sum, Pipfile.lock
Verify integrityDetect tampered packagesHash verification, --integrity flag, pip --require-hashes
Private registryControl approved packagesNexus, Artifactory, AWS CodeArtifact
SCA scanningFind known CVEs in dependenciesSnyk, OWASP Dependency-Check, Dependabot, Grype
Minimize dependenciesReduce attack surfaceAudit and remove unused libraries regularly

Practice Quiz

10 questions covering Domains 7 & 8 — Secure Deployment, Operations & Supply Chain Security.

1. Which principle supports deploying new server images rather than patching running systems in place?
2. The SolarWinds attack (2020) is an example of which type of threat?
3. What does SBOM stand for and what is its primary purpose?
4. Which US executive order mandated SBOMs for software sold to federal agencies?
5. In container security, running a container process as root is problematic because:
6. What is SLSA (Supply chain Levels for Software Artifacts)?
7. Which Incident Response phase involves removing malware, patching vulnerabilities, and revoking compromised credentials?
8. Dependency pinning to specific versions and hash verification primarily protects against:
9. The XZ Utils backdoor (CVE-2024-3094) was introduced via:
10. Which SBOM format is maintained by OWASP and is widely used for security-focused supply chain transparency?

Memory Hooks

Six memorable frameworks and mnemonics to lock in the key CSSLP Domain 7 & 8 concepts for exam day.

🏗️
Immutable Infrastructure
"Deploy New, Don't Patch Running"
Instead of patching live servers (mutable = cattle that get sick), deploy fresh images with patches applied (immutable = replace the whole cow). Benefits: no configuration drift, consistent state, easy rollback (redeploy previous image), repeatable. Terraform + Docker enable this pattern.
📦
SBOM Essentials
"Ingredient List for Software"
Like a food nutrition label but for software. Lists every component, version, and license. Formats: SPDX (ISO standard) and CycloneDX (OWASP). US EO 14028 mandates for federal software. Critical when a new CVE drops — instantly know which products are affected without manual analysis.
⛓️
Supply Chain Attacks
"SolarWinds=Build · Log4j=Dependency · XZ=Maintainer"
Three attack vectors: compromise the BUILD SYSTEM (inject malicious code into signed updates — SolarWinds). Exploit a DEPENDENCY vulnerability (Log4Shell — CVE in popular library). SOCIAL ENGINEERING a project maintainer to insert a backdoor (XZ Utils). All bypass perimeter security.
🐳
Container Security Rules
"Minimal · Non-Root · Read-Only · No Privileged · Signed"
Use Alpine/distroless base images. Run as non-root (USER nonroot). Read-only filesystem where possible. Never --privileged. Set CPU/memory limits. Scan with Trivy/Snyk. Sign with cosign/Sigstore. Never bake secrets into images — inject at runtime via secrets manager.
🔄
IR Lifecycle
"Prepare → Identify → Contain → Eradicate → Recover → Learn"
6 phases. Preparation = IR plan, runbooks, forensic tools ready BEFORE an incident. Identification = detect it. Contain = stop spread, preserve evidence. Eradicate = remove the threat. Recover = restore clean, monitor closely. Lessons Learned = post-mortem, improve controls, update plan.
🔐
CI/CD Secret Rules
"Never in Code · CI Platform Secrets · Short-Lived · Rotate"
Never hardcode in source, Dockerfiles, or env files committed to git. Use CI platform secrets (GitHub Actions Secrets, GitLab Variables) — masked in logs. Use OIDC-based short-lived credentials for cloud auth (no long-lived keys). Rotate regularly. Scan repos for secrets (truffleHog, git-secrets).

Flashcards & Study Advisor

Click any card to flip it and reveal the answer. Use the Study Advisor to explore specific topics in depth.

Flashcards

Click a card to flip it ↩

SBOM Formats
Two main machine-readable formats for software component inventory
SPDX (ISO/IEC 5962): Linux Foundation standard, widely used for license compliance. CycloneDX: OWASP standard, security-focused, rich vulnerability metadata. Both JSON/XML/tag-value. US EO 14028 accepts both. CycloneDX increasingly preferred for security tooling integration.
Supply Chain Attack Types
Four vectors for injecting malicious code via trusted channels
Build system compromise: modify pipeline or signing key (SolarWinds). Dependency confusion: malicious package published to public registry with same name as internal package. Typosquatting: similar name to popular package. Malicious maintainer: social engineering project contributors (XZ Utils).
Container Image Scanning
Tools and timing for scanning container images for CVEs
Trivy: fast, open-source, scans images + IaC + repos. Snyk Container: commercial, CI/CD integrated. Clair: CoreOS open-source. Scan at: build time (catch early), registry (continuous), runtime (detect new CVEs in deployed images). Scan OS layer + language packages + app dependencies.
IR Phase — Containment
Goals and key actions in the third IR phase
Goal: stop spread, preserve evidence. Actions: isolate affected systems (network segment, disable accounts), take forensic snapshots BEFORE remediation (preserve chain of custody), notify stakeholders, engage IR team. Do NOT immediately wipe — forensic evidence required for root cause and legal action.
SLSA Framework
Supply chain Levels for Software Artifacts — 5 levels
L0 = no guarantees. L1 = build process documented. L2 = build service generates provenance. L3 = hardened, non-falsifiable provenance. L4 = two-party review, hermetic build (highest assurance). Google open-sourced it; increasingly required for critical open-source projects.
Patch Management SLAs
Severity-based timelines for applying security patches
Critical (CVSS 9–10): 24–48 hrs — emergency, skip change window. High (7–8.9): 7 days. Medium (4–6.9): 30 days — normal cycle. Low (<4): 90 days. Requires: vuln scanning, SCA for dependencies, patch testing pipeline. Measure compliance rate monthly.
Secrets in CI/CD
Bad vs good patterns for handling secrets in pipelines
Bad: secrets in env files committed to git, secrets in Dockerfile ENV, echoed in build logs. Good: CI platform secrets (encrypted, masked in logs), OIDC federated identity (no long-lived keys), runtime injection via Vault/AWS Secrets Manager, short-lived tokens with automatic rotation. Audit access logs.
Dependency Pinning
Technique to prevent supply chain attacks via package substitution
Pin exact version + hash: requests==2.31.0 with hash in requirements.txt. Prevents maintainer pushing malicious update to a version range. Lock files (package-lock.json, go.sum, Pipfile.lock) enforce exact versions. Private registries: only approved packages installable. Verify with --integrity / pip hash checking mode.

Study Advisor

Select a topic to explore key concepts, tools, and exam pointers.

Secure Deployment

    Ready to Pass the CSSLP?

    Practice with full-length adaptive exams, all 8 domains covered.

    Start Free Practice Tests →