Skip to content

Chapter 35 Quiz: DevSecOps Pipeline

Test your knowledge of CI/CD security integration, secrets management, container scanning, IaC security, software supply chain, and developer security practices.

Questions

1. A developer accidentally commits an AWS access key to a public GitHub repository. The key is live and active. What is the correct immediate response sequence?

  • A) Delete the commit from git history and monitor for suspicious AWS activity
  • B) Rotate/revoke the AWS key immediately, then investigate what was accessed during the exposure window, then remediate the git history
  • C) Set the repository to private and notify the security team within 30 days
  • D) Open a ticket with AWS support to report the exposed key
Answer

B — Rotate/revoke the AWS key immediately, then investigate what was accessed during the exposure window, then remediate the git history

Rotating the key is the only action that actually stops the threat — it must happen first, measured in minutes. Once revoked, investigate AWS CloudTrail logs for unauthorized actions during the exposure window. Then address the git history (git history rewrite or GitHub secret scanning advisory). Setting the repo to private (C) is insufficient — the key is already exposed and GitHub's secret scanning may have already indexed it.

2. A CI/CD pipeline security engineer wants to prevent hardcoded secrets from reaching any git branch. Which control is most effective as a preventive measure?

  • A) Require developers to self-certify that no secrets are committed
  • B) Pre-commit hooks and CI pipeline secret scanning tools (e.g., Gitleaks, truffleHog) that block commits containing high-entropy strings or known credential patterns
  • C) Store all secrets in environment variables in the CI/CD platform's UI
  • D) Scan repositories monthly for secrets using a scheduled SAST job
Answer

B — Pre-commit hooks and CI pipeline secret scanning tools (e.g., Gitleaks, truffleHog) that block commits containing high-entropy strings or known credential patterns

Pre-commit hooks provide immediate feedback before the commit enters git history. CI pipeline scanning catches any secrets that bypass local hooks (e.g., developers who skip the hook). Tools like Gitleaks, truffleHog, and GitHub Advanced Security's secret scanning use entropy analysis and pattern matching. Monthly scanning (D) is too late — secrets may be exposed for weeks. Storing secrets in CI/CD environment variables (C) is correct for runtime but doesn't prevent accidental hardcoding.

3. HashiCorp Vault is integrated into a Kubernetes-based CI/CD pipeline. Applications retrieve secrets at runtime using Vault's Kubernetes auth method. What is the primary security benefit of this approach over environment variable injection?

  • A) Vault is faster than environment variable injection at scale
  • B) Secrets are not stored in the container image, environment, or filesystem — they are retrieved dynamically at runtime and can be short-lived with TTLs
  • C) Vault eliminates the need for TLS between application pods
  • D) Vault environment variable injection is not supported on Kubernetes
Answer

B — Secrets are not stored in the container image, environment, or filesystem — they are retrieved dynamically at runtime and can be short-lived with TTLs

Dynamic secrets from Vault (or similar — AWS Secrets Manager, GCP Secret Manager) are: not baked into images (no image scanning reveals them), not present in environment variable dumps, short-lived (TTL-based), and audited per access. Environment variables are visible via printenv, exposed in process listings, and logged in debug output. Dynamic secrets with short TTLs dramatically reduce the value of any single credential exposure.

4. A container image scanning tool (Trivy) reports 23 critical CVEs in the base image ubuntu:20.04. The application only uses 3 of the packages containing these CVEs. What is the best remediation approach?

  • A) Accept all findings — container CVEs are not exploitable in production
  • B) Upgrade to a minimal base image (e.g., ubuntu:22.04 or a distroless image), removing unneeded packages and eliminating the vulnerable components
  • C) Add a WAF rule to block exploitation of each CVE
  • D) Add all 23 CVEs to the exception list and rescan next quarter
Answer

B — Upgrade to a minimal base image (e.g., ubuntu:22.04 or a distroless image), removing unneeded packages and eliminating the vulnerable components

The most effective container security remediation is attack surface reduction: use minimal base images (distroless, Alpine, slim variants) that contain only what the application needs. Unused packages cannot be exploited. Distroless images (Google's approach) contain only the application runtime and its dependencies — no shell, no package manager. This is preferable to patching individual CVEs in bloated base images.

5. Checkov is run against a Terraform configuration and reports: CKV_AWS_18: Ensure the S3 bucket has access logging enabled and CKV_AWS_21: Ensure all data stored in the S3 bucket have versioning enabled. What type of security tool is Checkov?

  • A) DAST — it dynamically tests S3 bucket configurations in the live AWS account
  • B) IaC security scanner (SAST for Infrastructure as Code) — it analyzes Terraform/CloudFormation/ARM templates for misconfigurations before deployment
  • C) CSPM — Cloud Security Posture Management, which scans deployed cloud resources
  • D) SCA — Software Composition Analysis for AWS SDK dependencies
Answer

B — IaC security scanner (SAST for Infrastructure as Code) — it analyzes Terraform/CloudFormation/ARM templates for misconfigurations before deployment

Checkov (and tfsec, Terrascan, KICS) are IaC security scanners — they perform static analysis of infrastructure-as-code templates (Terraform, CloudFormation, Kubernetes YAML, ARM) before the infrastructure is deployed. This is the IaC equivalent of SAST: finding misconfigurations at the code level prevents them from reaching production. CSPM (C) scans already-deployed cloud environments; Checkov runs in the CI pipeline.

6. An SBOM (Software Bill of Materials) is generated for a production application. What is the primary security use case for maintaining an SBOM?

  • A) SBOMs are required by SOX for financial application auditing
  • B) SBOMs provide a machine-readable inventory of all components and dependencies, enabling rapid identification of whether a newly disclosed CVE (e.g., a zero-day in a library) affects the application
  • C) SBOMs replace penetration testing for compliance purposes
  • D) SBOMs are used exclusively for software license compliance, not security
Answer

B — SBOMs provide a machine-readable inventory of all components and dependencies, enabling rapid identification of whether a newly disclosed CVE (e.g., a zero-day in a library) affects the application

An SBOM (in CycloneDX or SPDX format) lists every component, library, and dependency in an application. When a new vulnerability is disclosed (like Log4Shell), organizations with SBOMs can query their inventory in minutes to identify affected applications rather than manually auditing every codebase. US Executive Order 14028 (2021) mandated SBOMs for software supplied to the federal government.

7. A security gate in a CI/CD pipeline blocks merges to the main branch if a SAST scan finds any HIGH or CRITICAL severity findings. A developer argues that this blocks legitimate code with false positives. What is the best policy response?

  • A) Remove all security gates — developer velocity is the priority
  • B) Maintain the gate for CRITICAL findings, require documented risk acceptance with security team sign-off for HIGH findings, and invest in tuning SAST rules to reduce false positives
  • C) Change all security gates to warnings only, never blocking
  • D) Require developers to bypass the gate with a justification comment in the commit message
Answer

B — Maintain the gate for CRITICAL findings, require documented risk acceptance with security team sign-off for HIGH findings, and invest in tuning SAST rules to reduce false positives

Security gates must balance protection with developer experience. Best practice: CRITICAL findings are hard blockers (no exceptions without CISO sign-off), HIGH findings require formal risk acceptance from the security team, and SAST tuning reduces noise over time. Bypasses via commit comments (D) are unauditable and unenforceable. Removing gates (A) eliminates the preventive control entirely.

8. SLSA (Supply chain Levels for Software Artifacts) is a framework for software supply chain security. Which SLSA level guarantees that the build process is fully scripted, uses an isolated build environment, and the provenance is signed by a trusted build service?

  • A) SLSA Level 1 — provenance exists but may be unsigned
  • B) SLSA Level 2 — build is scripted and uses a build service
  • C) SLSA Level 3 — build service generates signed provenance; source and build platforms meet specific security requirements
  • D) SLSA Level 4 — two-party review of all build changes
Answer

C — SLSA Level 3 — build service generates signed provenance; source and build platforms meet specific security requirements

SLSA levels: L1: provenance exists (unsigned). L2: hosted build service, signed provenance. L3: hardened build platform — build service produces signed provenance, the build is isolated, and the source/build platforms meet specific security requirements preventing insider tampering. L4 (deprecated in SLSA v1.0) added two-party review. L3 is the practical target for most organizations providing meaningful supply chain guarantees.

9. DORA (DevOps Research and Assessment) metrics include Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery. How does a security program use Change Failure Rate as a security metric?

  • A) Change Failure Rate measures how often security patches fail to install correctly
  • B) A rising Change Failure Rate correlated with skipped security gates signals that bypassing security controls introduces instability — demonstrating the security-reliability link
  • C) Change Failure Rate directly measures the number of security incidents per deployment
  • D) DORA metrics are engineering metrics unrelated to security programs
Answer

B — A rising Change Failure Rate correlated with skipped security gates signals that bypassing security controls introduces instability — demonstrating the security-reliability link

Security teams can use DORA metrics to demonstrate value: organizations with mature DevSecOps (automated security testing, fast feedback, no manual gates) show lower Change Failure Rates and faster MTTR than those with bolted-on security. If bypassing security gates correlates with increased failures, this provides data-driven justification for maintaining security controls. Security and reliability are correlated, not opposing.

10. A software supply chain attack compromises a popular npm package used by thousands of applications. The malicious version executes cryptocurrency mining code post-install. Which combination of controls would have best detected and limited this attack's impact?

  • A) Antivirus scanning of npm packages during download
  • B) SCA pinning to specific package versions with hash verification (lockfiles), SBOM tracking, and runtime anomaly detection for unexpected outbound network connections
  • C) Requiring all npm packages to be open source
  • D) Using yarn instead of npm for package management
Answer

B — SCA pinning to specific package versions with hash verification (lockfiles), SBOM tracking, and runtime anomaly detection for unexpected outbound network connections

Defense-in-depth for supply chain attacks: (1) lockfiles with hash verification (package-lock.json/yarn.lock) prevent automatic upgrade to malicious versions, (2) SBOM enables rapid impact assessment when a compromise is disclosed, (3) runtime anomaly detection flags unexpected outbound connections (mining traffic to pool). No single control is sufficient — this is why supply chain security requires layered defenses.

Scoring

Score Performance
9–10 Expert — DevSecOps pipeline security and software supply chain concepts fully mastered
7–8 Proficient — Ready to design and implement secure CI/CD pipelines
5–6 Developing — Review Chapter 35 sections on secrets management, IaC scanning, and SLSA framework
<5 Foundational — Re-read Chapter 35 before proceeding

Return to Chapter 35 | Next: Chapter 36