Foundational • Platform-Agnostic • ~3 hours

Introduction to DevSecOps

DevSecOps integrates security practices into every stage of the software development and operations lifecycle. Rather than treating security as a gate at the end of development, DevSecOps shifts security left — making it part of how code is written, reviewed, built, deployed, and operated. This model produces more secure software, faster, at lower remediation cost, by finding and fixing vulnerabilities when they are cheapest to address: at design and code time, not after production deployment.

~3 hours 6 modules + assessment Foundation Platform-agnostic with CloudSignals callouts

Who this course is for

Software developers building secure applications
DevOps engineers adding security to their pipelines
Security engineers working with development teams
Platform/cloud engineers managing container workloads
Architects designing new systems or migrating legacy apps
GRC professionals assessing application security programs

Prerequisites

Basic understanding of software development lifecycle concepts
Familiarity with how CI/CD pipelines work (build, test, deploy)
Basic awareness of container concepts (Docker/Kubernetes helpful but not required)
Introduction to Modern Cybersecurity Operations recommended

What you will be able to do

Articulate the business case for DevSecOps and explain what "shift-left" means operationally.
Conduct a basic threat model using STRIDE and identify mitigating controls.
Distinguish between SAST, DAST, SCA, and IAST and select the right tool for each testing scenario.
Identify the key security controls required in a secure CI/CD pipeline.
Apply CIS Kubernetes Benchmark controls and container image hardening practices.
Measure application security program maturity using OWASP SAMM or BSIMM and define improvement roadmaps.

Framework references in this course: OWASP Top 10 (2021), OWASP SAMM v2.0, OWASP ASVS v4.0, BSIMM v13, STRIDE/PASTA threat modeling, NIST SSDF (SP 800-218), CIS Software Supply Chain Security Guide, CIS Kubernetes Benchmark v1.8, NIST SP 800-190 (Container Security), SLSA Framework (Google/OpenSSF), OpenSSF Scorecard, SBOM/SPDX/CycloneDX standards.

DevSecOps Fundamentals

25 min • Shift-left, culture, the cost of late detection, shared ownership

What DevSecOps is and why it matters

DevSecOps is the cultural and technical integration of security practices into the DevOps workflow. Traditional security models gate security review at the end of development — a "security as a checkpoint" model that creates friction, delays release cycles, and, most importantly, finds vulnerabilities when they are most expensive to fix. The IBM Systems Science Institute estimated the cost to fix a defect found in production is 6–100× more expensive than fixing the same defect found during design or coding. DevSecOps shifts this economics by embedding security testing, threat modeling, code analysis, and configuration validation into the earliest stages of the development process.

Shift-left does not mean adding security tests before deployment — it means integrating security thinking into requirements and design, security tooling into the developer workflow (IDE plugins, pre-commit hooks), and security validation into every pipeline stage. A mature DevSecOps program treats a failing security check in CI/CD the same as a failing unit test: the build does not proceed until it is resolved. This requires security tooling that is developer-friendly, fast (adding seconds to a build, not minutes), and produces low false positive rates to avoid developer fatigue.

The three pillars: People, Process, Technology

People: Security champions — developers with additional security training who serve as embedded security representatives within product teams. Security champions bridge the cultural gap between security engineering and development, answer security questions without requiring a formal security review, and review pull requests for security issues. The OWASP Security Champion Guide recommends one champion per team of 8–10 developers as a starting point. Process: Security requirements in user stories, threat modeling as part of design reviews, security in Definition of Done (DoD), and post-incident review that feeds back into design improvements. Technology: Automated security testing in CI/CD (SAST, SCA, DAST), secrets scanning, SBOM generation, infrastructure-as-code scanning, container image scanning, and policy-as-code enforcement.

DevOps stage	DevSecOps additions	Primary tool types
Plan	Security requirements, threat modeling, DPIA triggers	Threat modeling tools (OWASP Threat Dragon, Microsoft TMT)
Code	IDE security plugins, pre-commit hooks, peer review checklists	IDE SAST plugins (Snyk Code, SonarLint), Semgrep
Build	SAST, SCA, secrets scanning, IaC scanning	SAST: Semgrep, Checkmarx, CodeQL. SCA: Snyk, Dependabot, Black Duck. Secrets: Trufflehog, GitGuardian. IaC: Checkov, tfsec
Test	DAST, IAST, API security testing, fuzz testing	DAST: OWASP ZAP, Burp Suite. IAST: Contrast Security. API: 42Crunch, APIsec
Deploy	Image scanning, admission controllers, policy-as-code	Trivy, Grype, OPA/Gatekeeper, Kyverno
Operate	CSPM, CWPP, runtime security, WAF	Falco, Aqua, Prisma Cloud Runtime, AWS GuardDuty

CloudSignals connection: CloudSignals bridges the DevSecOps and GRC worlds: findings from your application security testing pipeline can be ingested as asset findings in CloudSignals, automatically mapped to control families (e.g., OWASP Top 10 findings map to ISO 27001 A 8.28 Secure Coding), and tracked for remediation in the RiskOps treatment queue. This closes the loop between developer-level vulnerabilities and executive-level compliance reporting.

In Practice — Assess your current DevSecOps posture

Map your current SDLC: identify each stage (plan, code, build, test, deploy, operate). For each stage, list what security activities currently occur. The gaps you discover are your DevSecOps backlog.

Identify your security champions: do you have developers who voluntarily learn security and help their teams? If not, this is the highest-ROI first investment — security champions multiply security capacity without requiring dedicated security headcount.

Audit your CI/CD pipelines: do any pipelines run code to production without automated security testing? Every pipeline reaching production without at minimum SAST and SCA is a supply chain risk in your software delivery process.

Calculate the average time from vulnerability discovery to remediation in your codebase. If it exceeds 30 days for critical findings, your DevSecOps program lacks the workflow integration needed to drive timely fixes.

Map your SDLC security activities: Document what security activities exist at each SDLC stage. Identify the three stages with the most critical gaps and prioritize them for tooling or process additions.

Identify or recruit security champions: Identify two or three developers who have shown interest in security. Propose a security champions program with defined time allocation (e.g., 10% of sprint capacity for security activities).

Add security to your Definition of Done: Work with engineering leadership to add at minimum: "SAST scan passes with no new Critical findings" and "All new dependencies reviewed for known vulnerabilities" to your team's DoD criteria.

Knowledge Check

A development team deploys a DAST scanner that runs weekly against the production environment to detect vulnerabilities. This is a good start. What is the primary limitation of this approach from a DevSecOps perspective?

DAST scanners should run monthly, not weekly — more frequent scanning creates unnecessary server load and may trigger rate limiting from the application's WAF.

Testing only in production finds vulnerabilities at the most expensive point to fix — when code is already deployed. DevSecOps shifts testing left: vulnerabilities found in production require a hotfix cycle, regression testing, and potentially a security incident. The same vulnerability found at the code stage is a one-line fix with no deployment overhead. Production DAST is valuable but must be complemented by pipeline-integrated SAST and SCA at the build stage.

DAST is not a valid security control — only SAST tools that analyze source code can reliably detect vulnerabilities, since DAST can't see inside the application logic.

The approach is fully compliant with DevSecOps principles — production monitoring is the final stage of the DevSecOps lifecycle and weekly scanning meets best practice requirements.

Move on when you've mapped your SDLC security gaps, identified champions, and updated your DoD.

Secure SDLC and Threat Modeling

25 min • SDLC phases, STRIDE, PASTA, DREAD, attack surface analysis

The Secure Development Lifecycle (SDL)

Microsoft introduced the Security Development Lifecycle (SDL) in 2004, and it remains the foundational reference for how security integrates into each phase of software development. The modern SDL aligns with agile and DevOps workflows: security requirements are elicited alongside functional requirements; threat modeling occurs in the design phase and is revisited when the architecture changes significantly; code review for security is part of the PR/MR process; security testing gates release approval; security operations feed findings back into the backlog. NIST SP 800-218 (Secure Software Development Framework, SSDF) provides the US government framework for secure SDLC, organized into four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV).

Security requirements in the SDLC are not just "don't have SQL injection" — they include authentication and authorization requirements (who can access what data and how is that enforced), input validation requirements, encryption requirements (data at rest and in transit), logging and audit trail requirements, session management requirements, and third-party component security requirements (are you accepting components with no known CVEs? With what CVSS threshold?). Many security requirements derive directly from compliance obligations: PCI DSS requires TLS 1.2+ and no PAN in logs; HIPAA requires PHI encryption and access logging. Security requirements at design time are architectural decisions; security fixes in production are crisis management.

Threat modeling: STRIDE

Threat modeling is the process of identifying potential threats to a system at design time, before the system is built, so that mitigations can be incorporated into the design rather than bolted on afterward. STRIDE is the most widely used threat modeling methodology, developed by Microsoft. STRIDE categorizes threats by type: Spoofing (attacker impersonates another user or system), Tampering (attacker modifies data in transit or at rest), Repudiation (attacker denies having performed an action), Information Disclosure (attacker accesses data they should not), Denial of Service (attacker degrades or eliminates service availability), Elevation of Privilege (attacker gains higher permissions than authorized). For each STRIDE category, the modeler asks: where in my system is this threat applicable? What mitigations address it?

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric threat modeling methodology that works from business objectives through technical analysis to attack simulation. PASTA's seven stages produce a risk-aligned threat profile suitable for presenting to business stakeholders who need threat context in terms of business impact rather than technical vulnerability categories. PASTA is more resource-intensive than STRIDE but produces more actionable risk-level outputs for complex systems with multiple business stakeholders.

STRIDE category	Threat example	Primary mitigation
Spoofing	Session token theft, credential stuffing, JWT forgery	Strong authentication, token binding, MFA
Tampering	SQL injection, CSRF, man-in-the-middle, parameter manipulation	Input validation, CSRF tokens, TLS, signed messages
Repudiation	Covering tracks, log tampering, disabling audit trail	Tamper-evident audit logs, centralized log storage, log integrity
Information Disclosure	IDOR, excessive error messages, API data over-exposure, XXE	Authorization checks, error message sanitization, field-level filtering
Denial of Service	Rate limit bypass, resource exhaustion, ReDoS, XML bomb	Rate limiting, input size limits, circuit breakers, CDN
Elevation of Privilege	SSTI, OS command injection, insecure deserialization, privilege escalation	Principle of least privilege, sandboxing, input sanitization

CloudSignals connection: Threat models produced during design can be formalized as risk entries in CloudSignals RiskOps, with each STRIDE threat mapped to a risk record containing: the threat description, the asset at risk, the inherent risk rating, the mitigation controls, and the residual risk score. This creates traceability from design-time security decisions to the enterprise risk register, enabling auditors to trace a compliance control back to the threat it mitigates.

In Practice — Run a STRIDE threat model

Select a feature or system component currently in design or early development. Draw a simple Data Flow Diagram (DFD) showing: external users/systems, internal processes, data stores, and the data flows between them. Mark trust boundaries — the lines across which trust changes (public internet → API gateway, API gateway → backend service, backend service → database).

For each element in your DFD, apply STRIDE: which categories apply to this element? An API endpoint is a candidate for Spoofing, Tampering, Information Disclosure, and Denial of Service. A database is a candidate for Tampering, Information Disclosure, and Repudiation. A message queue is a candidate for Tampering and Spoofing.

For each identified threat, define the mitigation control and confirm it is in the design. Any threat without a mitigation becomes a security requirement backlog item to be addressed before deployment.

Score each threat using DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) on a 1–3 scale per category. Threats with a score of 10+ are your highest-priority mitigations.

Add threat modeling to your design review process: Require a STRIDE-based threat model for all new systems and significant architectural changes. Create a one-page DFD template your teams can use in design sessions.

Threat model an existing system: Select one production system that has never had a formal threat model. Conduct a 2-hour workshop with the system's developer and architect. Document the output and create tickets for any identified mitigations not currently implemented.

Define when threat modeling is triggered: Create a written policy specifying when threat modeling is required: new system with external-facing components, new data store handling sensitive data, significant authentication/authorization changes, third-party integration handling PII.

Knowledge Check

During a STRIDE analysis of a REST API, the team identifies that an attacker could send a specially crafted JSON payload to exhaust all available database connections. Which STRIDE category does this threat belong to?

Tampering — the attacker is modifying the JSON payload, which is a form of data tampering.

Information Disclosure — the JSON payload could leak database connection information to the attacker.

Denial of Service — exhausting all database connections prevents the application from serving legitimate requests. While the attacker manipulates the payload (a Tampering element), the primary security outcome is service degradation for all users. Mitigations include connection pool limits, request rate limiting, input size validation, and circuit breakers to prevent connection exhaustion.

Elevation of Privilege — gaining control over database connections could allow the attacker to escalate privileges within the database tier.

Move on when you've added threat modeling to your design process, conducted one existing-system exercise, and defined your trigger criteria.

Application Security Testing

30 min • SAST, DAST, SCA, IAST, OWASP Top 10, ASVS

The application security testing spectrum

SAST (Static Application Security Testing) analyzes source code, bytecode, or binary without executing it. SAST finds injection flaws, insecure API calls, hardcoded credentials, buffer overflows, and other code-level vulnerabilities. SAST tools integrate into CI/CD and IDE. They produce false positives and require tuning — but run in seconds and find issues before any code is deployed. Leading tools: Semgrep, Checkmarx SAST, Fortify, CodeQL (GitHub), SonarQube. DAST (Dynamic Application Security Testing) tests a running application by sending malicious inputs and observing responses — the same technique an attacker uses. DAST requires a running target (staging or test environment) and finds issues SAST misses: business logic flaws, authentication failures, and runtime configuration issues. Leading tools: OWASP ZAP, Burp Suite Pro, Invicti, StackHawk. SCA (Software Composition Analysis) identifies open-source and third-party dependencies and checks them against vulnerability databases (NVD, GitHub Advisory Database, Sonatype OSS Index). SCA is critical because the majority of modern application code is third-party libraries. Leading tools: Snyk Open Source, Dependabot, FOSSA, Black Duck.

IAST (Interactive Application Security Testing) instruments the running application from within — using agents that observe application behavior during functional testing to identify security flaws in context. IAST provides the accuracy of runtime analysis with much lower false positive rates than SAST. Leading tools: Contrast Security, Seeker. MAST (Mobile AST) applies SAST/DAST/IAST to mobile applications. API security testing applies DAST-like fuzzing and schema validation to REST/GraphQL APIs — a critical gap since most DAST tools were designed for web applications and miss API-specific vulnerabilities like excessive data exposure, broken object-level authorization (BOLA/IDOR), and mass assignment.

OWASP Top 10 (2021)

The OWASP Top 10 is the most widely referenced list of critical application security risks. The 2021 edition identifies: A01 Broken Access Control (moved to #1 — most prevalent finding), A02 Cryptographic Failures, A03 Injection (SQL, LDAP, OS command), A04 Insecure Design (new — design-level flaws not fixable by implementation patches), A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures, A08 Software and Data Integrity Failures (new — covers unsigned updates, deserialization, CI/CD pipeline integrity), A09 Security Logging and Monitoring Failures, A10 Server-Side Request Forgery (SSRF, new). OWASP ASVS (Application Security Verification Standard) v4.0 provides specific verification requirements for each of these categories — offering a measurable, testable security baseline for any application.

Testing type	When in pipeline	What it finds best	Key limitation
SAST	Code commit / PR / build stage	Injection flaws, hardcoded secrets, unsafe APIs, code-level CWEs	High false positive rate; misses runtime and business logic issues
SCA	Build stage / PR	Vulnerable open-source dependencies, license compliance issues	Only finds known CVEs — zero-day library vulnerabilities are invisible
DAST	Test stage / staging environment	Runtime issues, auth failures, SSRF, business logic, config errors	Needs running app; can't test code paths not covered by crawl
IAST	During functional testing	High accuracy runtime issues in tested code paths; low FP rate	Requires agent instrumentation; only tests code paths exercised
Secrets scanning	Pre-commit / build	Hardcoded API keys, credentials, tokens, private keys in code	Only finds secrets not already committed historically (need separate audit for history)

CloudSignals connection: CloudSignals asset security posture extends to application-layer findings: SAST and DAST output can be integrated as security findings against the application asset record. OWASP Top 10 category mappings automatically link application findings to the relevant compliance controls in your UCB framework, providing GRC teams with evidence that application security testing is occurring and producing tracked results.

In Practice — Improve your AppSec testing coverage

Audit your CI/CD pipelines: which pipelines include SAST? Which include SCA? Which include secrets scanning? Any pipeline reaching production without at minimum SCA (to detect vulnerable dependencies) is a supply chain security gap that should be addressed within 30 days.

Run a secrets scan on your git history using a tool like Trufflehog or GitGuardian. Long-lived repositories often contain committed credentials that were never rotated. Any valid credentials found must be rotated immediately and the exposure must be assessed for unauthorized use.

Review your SAST tool's false positive rate for your most active repositories. If developers are suppressing more than 50% of findings as false positives, the tool needs tuning. Suppressions should be documented with a rationale, not used as a way to make security gates pass.

Map your current testing coverage to the OWASP Top 10: which of the 10 categories can your current test suite detect? Which have no coverage? A01 Broken Access Control and A04 Insecure Design typically require manual review or DAST with business logic awareness — not just automated SAST.

Add SCA to all production pipelines: Every pipeline deploying to production should have SCA (Snyk, Dependabot, or equivalent) configured to fail builds on Critical severity CVEs with no applied exceptions policy.

Scan your git history for secrets: Run a secrets scanning tool against your primary code repositories' full history. Document and rotate any valid credentials discovered, and add pre-commit secrets scanning to prevent future occurrences.

Map OWASP Top 10 to your test coverage: For each of the 10 categories, identify whether your current tooling can detect it. Create backlog items to add testing coverage for any categories with no current detection capability.

Knowledge Check

A team runs SAST on every pull request and reports zero Critical findings for six months. A penetration tester then finds a critical Broken Object Level Authorization (BOLA) vulnerability in the API. Why did SAST miss it?

SAST was not configured correctly — with proper ruleset configuration, SAST can detect all OWASP Top 10 vulnerabilities including access control flaws.

BOLA/IDOR is a business logic vulnerability: the code correctly retrieves the object the user requests, but fails to verify the user is authorized to access that specific object. SAST analyzes code syntax and patterns — it cannot determine authorization intent without understanding business rules. BOLA detection requires runtime testing (DAST or manual penetration testing) that can observe actual authorization enforcement behavior with different user contexts.

SAST cannot detect API vulnerabilities — it is designed only for traditional web applications and cannot analyze REST API endpoints.

The penetration tester likely found a false positive — BOLA vulnerabilities require authentication that automated SAST tools are not configured to test, so the finding cannot be confirmed without re-running SAST with authentication configured.

Move on when you've added SCA to production pipelines, scanned git history for secrets, and mapped OWASP Top 10 coverage.

CI/CD Pipeline Security

25 min • Pipeline hardening, secrets management, SBOM, software supply chain

Why CI/CD pipelines are a primary attack target

CI/CD pipelines have become a primary target for sophisticated attackers because they sit at the intersection of broad code access, cloud credentials, production deployment capability, and often relatively weak access controls. The 2020 SolarWinds supply chain attack compromised the build pipeline to inject malicious code into a signed software update reaching 18,000+ organizations — without ever compromising a production environment directly. In 2023, the 3CX supply chain compromise used a trojanized upstream dependency. The CISA/NSA joint advisory on "Defending Continuous Integration/Continuous Delivery (CI/CD) Environments" (2023) identified pipeline access control, secrets management, and build integrity as the three highest-priority security controls for CI/CD environments.

Pipeline hardening controls

Key pipeline security controls include: Least privilege for pipeline credentials — CI/CD service accounts should have only the permissions needed to deploy to the target environment, not admin access to cloud accounts or the ability to modify the pipeline itself. Branch protection and approval gates — direct pushes to production branches should be blocked; all changes require PR review and passing security gates. Ephemeral build environments — each build runs in a clean, isolated environment and is destroyed after completion, preventing cross-build contamination. Pinned dependencies — use commit SHA pinning for pipeline actions and tool versions rather than floating tags (e.g., `actions/checkout@v4` is a floating tag; `actions/checkout@abc123def` is a pinned SHA that cannot be tampered with by pushing a new tag). Signed commits and artifacts — require Signed commits (GPG/SSH) on protected branches; sign build artifacts and container images to establish provenance chain.

Secrets management in pipelines

Hardcoded secrets in pipelines are a critical failure mode: credentials stored as plaintext environment variables in pipeline YAML files, embedded in Dockerfiles, or committed to the repository. Pipeline secrets must be stored in a dedicated secrets management system: GitHub Actions Secrets/Environments, GitLab CI/CD Variables (protected), HashiCorp Vault, or cloud-native secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Secrets injected at runtime should use short-lived credentials where possible (OIDC federation with cloud providers eliminates long-lived cloud credentials from pipelines entirely — the pipeline authenticates to AWS/Azure/GCP using a short-lived OIDC token rather than a stored access key).

Software Bill of Materials (SBOM) and supply chain security

An SBOM is a machine-readable inventory of all software components in an application: libraries, frameworks, licenses, versions, and known vulnerabilities. US Executive Order 14028 (May 2021) mandated SBOM production for software sold to the US federal government. SBOM formats: SPDX (Linux Foundation standard, ISO/IEC 5962:2021) and CycloneDX (OWASP standard, widely used in DevSecOps tooling). The SLSA (Supply chain Levels for Software Artifacts) framework from Google/OpenSSF provides four maturity levels for build integrity: Level 1 (documented build process), Level 2 (build service generates provenance), Level 3 (build environment and provenance are verified), Level 4 (reproducible builds with two-party review). Organizations targeting federal sales or regulated markets should target SLSA Level 2 minimum.

Pipeline tokens are high-value targets: Many CI/CD platforms automatically provide the pipeline with a token granting access to the repository and, in cloud environments, to infrastructure. Attackers who compromise a pipeline job via a malicious PR or a dependency confusion attack gain access to these tokens. Always restrict what pipeline tokens can do to the minimum necessary and treat a pipeline compromise as a cloud infrastructure incident, not just a code integrity event.

In Practice — Harden your CI/CD pipeline

Audit pipeline permissions: for each CI/CD pipeline, identify what cloud credentials are available to the pipeline job. Remove all permissions not required for the build and deploy steps. If using GitHub Actions, switch to OIDC authentication with cloud providers to eliminate long-lived credentials.

Scan pipeline YAML files for hardcoded secrets using a secrets scanning tool. Review environment variable definitions in all pipeline files. Any secrets stored as plaintext values (not references to secrets manager) must be migrated to proper secret storage immediately.

Review your third-party pipeline actions/plugins: are any using floating tags (e.g., @latest, @v3)? Pin all third-party actions to a specific commit SHA. Review the OpenSSF Scorecard for any third-party tools you use to assess their supply chain security posture.

Add SBOM generation to your build pipeline for at least your production-deployed applications. Use Syft, CycloneDX Generator, or Snyk to generate SBOM at build time. Store SBOM artifacts alongside release artifacts for vulnerability retrospective analysis.

Implement OIDC authentication: For AWS, Azure, or GCP, configure OIDC federation so your CI/CD pipelines authenticate using short-lived tokens rather than stored access keys. This eliminates the entire class of long-lived credential exposure from pipelines.

Pin third-party pipeline actions to commit SHAs: Audit all uses of third-party actions in your CI/CD pipelines and replace floating tag references with pinned commit SHAs. Add Dependabot or Renovate automation to keep pinned versions current.

Add SBOM generation to your build pipeline: Select an SBOM format (CycloneDX recommended for DevSecOps tooling compatibility) and add SBOM generation as a build stage artifact. Configure your vulnerability scanner to monitor SBOM components for new CVE disclosures post-release.

Knowledge Check

A development team stores all CI/CD secrets in the pipeline platform's built-in secrets store (e.g., GitHub Actions Secrets, GitLab Variables) and never hardcodes them in pipeline YAML. Is this a complete secrets management solution?

Yes — using the platform's native secret store rather than hardcoding is fully aligned with CI/CD secrets management best practices and requires no further improvement.

This is a good start but incomplete. Platform secrets stores are better than hardcoding, but they typically store long-lived static credentials. Best practice additionally includes: (1) using short-lived OIDC tokens instead of stored credentials for cloud access where possible, (2) secret rotation policy with defined rotation schedules, (3) access auditing to track which pipelines access which secrets, (4) least-privilege access to secrets (not all pipelines accessing all secrets), and (5) scanning for secrets that may have already been committed to pipeline YAML history before the store was adopted.

Platform secret stores are not secure enough for production credentials — all secrets must be stored in a dedicated secrets management system like HashiCorp Vault or AWS Secrets Manager.

The main gap is that all secrets should be encrypted at rest using a customer-managed encryption key (CMEK) — platform-managed encryption is not acceptable for production credentials.

Move on when you've implemented OIDC authentication, pinned third-party actions, and added SBOM generation to your pipeline.

Container and Kubernetes Security

25 min • Image hardening, RBAC, network policies, Pod Security, runtime security

Container image security

Container security begins at image build time. Image hardening best practices from NIST SP 800-190 and CIS Docker Benchmark include: use minimal base images (distroless, Alpine, scratch) to reduce attack surface — a full Ubuntu base image contains thousands of packages, most unnecessary; build as a non-root user (90%+ of public container images run as root, violating least privilege); scan images for CVEs using Trivy, Grype, or Snyk Container at build time and in the registry, not just at push time; sign images using Cosign (from the Sigstore project) to establish a cryptographic provenance chain that admission controllers can verify; set image to read-only filesystem and drop all Linux capabilities except those explicitly required; never include secrets, credentials, or sensitive configuration in image layers — use Kubernetes Secrets or external secrets management at runtime.

Image registry security includes: vulnerability scanning on push (ECR, ACR, GCR all include native scanning; enable it and configure block-on-Critical policy), enforce signed image policies (OPA Gatekeeper or Kyverno admission controllers can reject images without valid Cosign signatures), and configure registry access controls (pull-only access for production workloads — production should never be able to push to the registry, only pull).

Kubernetes RBAC and network policies

Kubernetes RBAC (Role-Based Access Control) governs what API operations users and service accounts can perform within the cluster. Key RBAC principles: use the default ServiceAccount for pods only when explicitly needed — most workloads should not have any cluster API access; bind the minimum permissions required and scope them to specific namespaces (RoleBindings), not cluster-wide (ClusterRoleBindings); never use the cluster-admin ClusterRoleBinding for application workloads; avoid the "catch-all" wildcard (*) in resource and verb specifications. The CIS Kubernetes Benchmark provides specific RBAC control configurations that are the industry-accepted baseline.

Network Policies are the Kubernetes equivalent of security groups for pod-to-pod communication. By default, all pods in a Kubernetes cluster can communicate with all other pods — a flat network that enables unrestricted lateral movement. Network Policies implement default-deny ingress and egress, permitting only explicitly specified traffic flows. A properly configured production namespace should have: a default deny-all policy, explicit allow rules for each service's required inbound and outbound traffic, and monitoring of policy violations using a CNI plugin that supports observability (Calico, Cilium, Weave).

Pod Security and runtime detection

Kubernetes Pod Security Standards (PSS, replacing deprecated PodSecurityPolicy in K8s 1.25+) define three profiles: Privileged (no restrictions — for system-level workloads), Baseline (prevents known privilege escalation vectors — suitable for most workloads), and Restricted (most secure — requires non-root, read-only root filesystem, dropped capabilities — for internet-facing or high-sensitivity workloads). Pod Security Admission (PSA) enforces these profiles at the namespace level via labels. Runtime security tools (Falco, Aqua, Prisma Cloud Compute) detect anomalous container behavior at runtime: unexpected outbound connections, process execution not in the image's baseline, filesystem writes to unexpected locations — the behavioral signatures of container escape, lateral movement, and cryptomining.

CloudSignals connection: CloudSignals continuously assesses Kubernetes posture using rules mapped to the CIS Kubernetes Benchmark and NIST SP 800-190. Findings — privileged pods, missing network policies, exposed services, RBAC misconfigurations — are surfaced as posture findings against the Kubernetes asset, linked to your compliance framework mappings, and available for RiskOps treatment tracking. This extends the same unified governance model from cloud infrastructure to container workloads.

In Practice — Harden your container environment

Scan your running container images for vulnerabilities using Trivy: `trivy image [your-image-name]`. How many Critical and High CVEs are in your production images? Any Critical CVE in a production image requires a remediation timeline.

Check how many of your pods run as root: `kubectl get pods --all-namespaces -o json | jq '.items[].spec.containers[].securityContext.runAsNonRoot'`. Any pod running as root that doesn't need to is a privilege escalation risk if the container is compromised.

Check for default network policy: `kubectl get networkpolicy --all-namespaces`. Namespaces with no NetworkPolicy objects have unrestricted pod-to-pod communication. Add a default-deny ingress/egress NetworkPolicy to any namespace that lacks one, then add explicit allow rules for required traffic.

Review ClusterRoleBindings for broad permissions: `kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'`. Each subject with cluster-admin rights is a potential full-cluster compromise vector. Reduce to the minimum required subjects.

Add Kubernetes network policies: Implement default-deny NetworkPolicies in all production namespaces. Add explicit allow rules for each service's required communication paths. Test that application functionality is maintained after policy enforcement.

Enforce Pod Security Standards: Apply Pod Security Admission labels to production namespaces at minimum Baseline profile, targeting Restricted for high-sensitivity workloads. Identify and remediate any pods that fail the Baseline profile.

Add image vulnerability scanning to your registry: Enable registry scanning (ECR, ACR, GCR, or Harbor) and configure admission control to reject images with Critical CVEs that have available patches from being deployed to production namespaces.

Knowledge Check

A Kubernetes deployment runs a web application container. The container is compromised via a web vulnerability and the attacker executes code within it. The pod runs as root with no security context restrictions and no NetworkPolicy. What is the most significant consequence of these misconfigurations?

The container will be automatically terminated by the Kubernetes runtime when the anomalous process execution is detected — no further action is needed.

Running as root enables container escape attempts using kernel exploits (root in container = root on host node if cgroup/namespace isolation is bypassed). No NetworkPolicy means the attacker can reach all other pods in the cluster from within the compromised container — unrestricted lateral movement across namespaces. Together, these misconfigurations transform a single web vulnerability into a potential full-cluster compromise rather than an isolated container incident.

The impact is limited to the application itself — Kubernetes namespace isolation prevents any movement beyond the affected pod, regardless of security context or NetworkPolicy configuration.

The main risk is that root access will allow the attacker to modify the container image in the registry, affecting all future deployments of the application.

Move on when you've added network policies, enforced Pod Security Standards, and added image scanning to your registry.

Program Maturity and Governance

20 min • BSIMM, OWASP SAMM, policy-as-code, developer security metrics

Measuring application security program maturity

BSIMM (Building Security In Maturity Model) is an observational model based on measuring what real organizations actually do in their software security initiatives. Now in version 13, BSIMM studies over 130 firms and documents security activities across 4 domains (Governance, Intelligence, SSDL Touchpoints, Deployment) and 16 practices. BSIMM is used to compare your program against peer organizations and identify which activities the top-quartile performers do that you don't. OWASP SAMM (Software Assurance Maturity Model) v2.0 is a prescriptive framework organized into 5 business functions (Governance, Design, Implementation, Verification, Operations) with 15 security practices, each scored 0–3 for maturity. Unlike BSIMM (descriptive), SAMM is a prescriptive roadmap — it tells you what to do to reach each maturity level. Most organizations start a formal AppSec program at SAMM overall maturity 1.0–1.5 and should target 2.0 within 24 months for critical systems.

Policy-as-code: governance at pipeline speed

Policy-as-code is the practice of expressing security and compliance policies as machine-readable, testable code rather than documents. Instead of a policy document that says "all containers must run as non-root," a policy-as-code approach implements this as an OPA/Gatekeeper or Kyverno constraint that the Kubernetes admission controller enforces at deployment time. This creates the critical shift: policy violations are caught before deployment, not in audits after the fact. Policy-as-code frameworks: OPA (Open Policy Agent) with its Rego policy language — the most widely deployed general-purpose policy engine; Kyverno — Kubernetes-native policy using YAML syntax; Checkov and tfsec — IaC policy scanning for Terraform, CloudFormation, and Kubernetes manifests; Conftest — testing structured configuration files against OPA policies.

The compliance benefit of policy-as-code extends beyond enforcement: policies stored in Git create a version-controlled, auditable record of what security requirements are enforced, when they were added, who approved them, and whether they pass. This is evidence of control operating effectiveness — exactly what auditors for SOC 2 Type II, ISO 27001, and FedRAMP require to certify your controls.

DevSecOps metric	What it measures	Target
Mean Time to Remediate (AppSec)	Average time from SAST/DAST finding to fix commit	Critical: <7 days; High: <30 days
Security Gate Pass Rate	% of PRs/builds passing security gates without exception	≥90% pass without exception over 90 days
Suppression/Exception Rate	% of findings suppressed vs. fixed	Suppressions <10% of total findings; all require documented rationale
New Critical Vulnerabilities Introduced	New Criticals per release cycle	Zero new Criticals reaching production
SBOM Currency	% of production applications with current SBOM	100% of production apps with SBOM generated at last build
SAMM Maturity Score	OWASP SAMM overall program score (0–3)	Target 2.0+ within 24 months of program launch

CloudSignals connection: DevSecOps governance metrics — SAST finding resolution rates, SCA component currency, image scan compliance, and pipeline security gate pass rates — can be tracked as control metrics in CloudSignals UCB. When these metrics are linked to controls in your ISO 27001 or SOC 2 framework, they become evidence of operating effectiveness, visible in your GRC dashboard alongside infrastructure posture findings. This creates the unified application + infrastructure + governance view that eliminates siloed reporting.

In Practice — Build your DevSecOps improvement roadmap

Take the OWASP SAMM self-assessment survey (owaspsamm.org). For each of the 15 security practices, score your current maturity 0–3. The output is a spider diagram showing your program shape and the specific practice gaps to address.

Identify your highest-priority gap: which SAMM practice with a current score of 0 or 1 would produce the most security improvement if raised to 2? For most early-stage programs, that gap is in Design (threat modeling) or Implementation (security testing in CI/CD).

Select one policy to implement as code: choose a security policy currently documented only in a PDF or wiki (e.g., "all production containers must run as non-root"). Implement it as a Kyverno or OPA/Gatekeeper admission control policy. Test it and deploy it in audit mode first, then enforce mode.

Set quarterly DevSecOps metric targets: define target values for Mean Time to Remediate (Critical findings), Security Gate Pass Rate, and New Critical Vulnerabilities introduced per quarter. Share these with engineering leadership and track them as a program KPI.

Complete OWASP SAMM self-assessment: Complete the full SAMM survey for your application security program. Export the results and share with your security leadership. Identify the top 3 practice areas for improvement in the next 12 months.

Implement one policy-as-code control: Convert one written security policy into a testable, enforced policy-as-code control (Kyverno, OPA, Checkov, or equivalent). Deploy in audit mode, remediate violations, then switch to enforce mode.

Define and track your three DevSecOps KPIs: Select three metrics from the table above. Set 12-month targets. Assign ownership and a review cadence (monthly review, quarterly executive reporting).

Knowledge Check

An organization has a written security policy that states "all Kubernetes pods must run as non-root." Security audits annually find violations of this policy. The team implements this as a Kyverno admission control policy. What is the primary governance benefit of this change, beyond just enforcement?

The primary benefit is performance — admission controllers execute faster than manual policy review, reducing time to production deployment for compliant workloads.

Policy-as-code provides continuous, automated enforcement (violations caught at deploy time, not in annual audits) and produces audit evidence: the policy is version-controlled in Git with approval history, and admission controller logs provide real-time evidence of enforcement. Auditors can verify the control is both designed and operating effectively from Git history and controller metrics — eliminating the gap between "policy exists" and "policy is actually enforced."

The primary benefit is that violations are now visible in the SIEM — security teams can receive real-time alerts when a pod attempts to run as root, enabling faster incident response.

The governance benefit is minimal — policy-as-code only addresses technical controls and cannot satisfy the documentation requirements that governance frameworks like SOC 2 or ISO 27001 require for evidence of control operation.

Move on when you've completed your SAMM assessment, implemented one policy-as-code control, and defined your three DevSecOps KPIs.

Course Assessment — Introduction to DevSecOps

Completing all six modules qualifies you for the knowledge assessment. This course completes the four foundational knowledge courses and is a recommended prerequisite for the practitioner-level Application Security and Cloud-Native Security tracks.

Assessment domain	Weight
DevSecOps fundamentals and shift-left economics	20%
Secure SDLC and threat modeling	20%
Application security testing (SAST/DAST/SCA)	20%
CI/CD pipeline security and supply chain	20%
Container/Kubernetes security and governance	20%

Capstone scenario

A software team is building a new API-first SaaS product. The product handles PII and is targeting SOC 2 Type II certification within 18 months. They use GitHub, GitHub Actions, Docker, Kubernetes (EKS), and Terraform. Currently: no SAST in the pipeline, SCA runs weekly as a separate report, no threat modeling process, images run as root, no network policies, no policy-as-code. Your task:

Design a prioritized 90-day DevSecOps implementation roadmap: what are the first, second, and third priorities, and why?
Run a high-level STRIDE threat model for an API endpoint that accepts user-uploaded files and stores them in S3. What threats apply to each component?
Design the CI/CD pipeline security controls: which tools at which stages, and what causes a build to fail?
Describe how OIDC authentication would replace the current static AWS access key stored in GitHub Secrets.
Explain how your container and Kubernetes security controls would be evidenced for SOC 2 Type II auditors.

Passing criteria: 90-day roadmap correctly prioritizes SCA+secrets scanning first (quickest wins), SAST+pipeline hardening second, threat modeling+IaC scanning third. STRIDE model correctly identifies Tampering and Information Disclosure for file upload endpoint, Denial of Service for S3 bucket, Spoofing for API authentication. OIDC explanation covers the token exchange flow and elimination of long-lived credentials. SOC 2 evidence answer mentions policy-as-code in Git as design evidence and admission controller enforcement logs as operating effectiveness evidence.

🏅

Course complete!

You've completed all four foundational knowledge courses. You're ready for the practitioner certification tracks.

Explore Practitioner Courses