How do you ship software continuously without accidentally deploying a security disaster? For the PCDOE exam, you must understand how to embed security and compliance checks directly into your automated pipelines so that every code change is scanned, every vulnerability is flagged, and every regulation is met before it ever reaches production. This chapter breaks down exactly how those checks work and what you need to know to pass.
Jump to a section
A simple way to picture Security and Compliance in DevOps Pipelines
Ever wondered how an airport keeps millions of passengers safe without stopping the flow of travellers?
Think of your CI/CD pipeline as a busy airport terminal. Developers are passengers, each pushing code (their luggage) through the system. Before anyone boards a plane (releases to production), they must pass through security.
The security checkpoint is your automated security scanning. The X-ray machine checks for prohibited items (vulnerabilities in your code). The metal detector looks for hidden threats (malware or backdoors). The explosive trace detector sniffs for dangerous chemicals (secret keys or passwords accidentally left in the code). If any alarm sounds, the baggage is pulled aside for manual inspection (a security alert sent to the team).
Compliance checks are like the airline's passenger manifest. Every traveller needs the correct visa (identity and access management) and must be on the authorised flight list. Before departure, the gate agent verifies each boarding pass (ensuring only approved, secure code gets deployed).
The entire system must be fast enough that travellers don't miss their flights, yet thorough enough to catch threats. A single skipped check could let a dangerous item onto the plane, risking everyone on board. That's exactly why you integrate scanning and compliance into your pipeline: to catch problems early, every time, without slowing down your developers.
In traditional IT, security checking happened at the end of a project, like a final exam. You'd build the whole application, then hand it to a security team for a review weeks later. If they found a problem, you had to rework everything. This was slow, expensive, and often led to security being skipped to meet deadlines.
DevOps changes this by moving security checks left in the pipeline. Left means earlier in the development process. Instead of checking security at the very end, you check it at every step: as soon as code is written, when it's built into a package, when it's deployed to a test environment, and even after it's live. This is often called shift-left security.
The core concept is the software supply chain. This is everything that goes into making your application: the source code your team writes, the open-source libraries and dependencies it uses, the container images it runs on, and the infrastructure definition files. Each part is a potential attack surface. A vulnerability in an open-source library with a funny name like Log4j can bring down millions of systems worldwide.
Security scanning in the CI/CD pipeline typically includes several types of checks:
Static Application Security Testing (SAST): This scans your source code without running it. It looks for patterns known to be dangerous, like hardcoded passwords, SQL injection points, or buffer overflows. It's like a grammar check for security.
Dynamic Application Security Testing (DAST): This runs your application in a test environment and attacks it from the outside, just like a real hacker would. It checks for issues that only appear when the code is running, such as misconfigured authentication or exposed APIs.
Software Composition Analysis (SCA): This examines all the open-source components and libraries your application uses. It compares them against databases of known vulnerabilities, like the National Vulnerability Database (NVD). If your project uses an old version of a library with a critical flaw, SCA will flag it.
Container Scanning: If you package your application into containers (like Docker images), this scans the image itself. It checks the base operating system, the installed packages, and the application files for known vulnerabilities.
Compliance checks ensure your pipeline meets regulatory or policy requirements. For example, the Payment Card Industry Data Security Standard (PCI DSS) requires that cardholder data is encrypted at rest and in transit. A compliance check in your pipeline could automatically verify that all database connections use TLS encryption, and fail the build if they don't.
These checks are integrated using tools like Cloud Build, Cloud Deploy, or third-party security tools integrated via Cloud Build triggers. The pipeline is configured as an automated sequence of steps: a developer pushes code, Cloud Build fetches it, runs SAST and SCA scans, builds a container image, scans the image, deploys to a staging environment, runs DAST, and finally, if all checks pass, deploys to production. If any check fails, the pipeline stops, and an alert is sent.
By doing this automatically, security is no longer a separate phase. It becomes a continuous part of development. Every commit is checked. Every library is vetted. Every deployment is compliant. This replaces the old model of periodic security reviews and manual compliance audits, which were error-prone and easily bypassed.
1. Source Code Commit
A developer pushes code to a source repository like Cloud Source Repositories or GitHub. This triggers the pipeline. This step matters because it is the first opportunity to run SAST scans on the code changes before they are merged.
2. Dependency and Code Analysis
Cloud Build runs a software composition analysis (SCA) tool to check all imported libraries for known vulnerabilities. It also runs a static application security testing (SAST) tool to scan the code for insecure patterns. This catches issues like hardcoded secrets or SQL injection.
3. Container Image Building and Scanning
The application is packaged into a container image using Docker. The image is pushed to Artifact Registry, which automatically scans it against vulnerability databases. If critical vulnerabilities are found in the base OS or packages, the pipeline can be configured to fail.
4. Staging Deployment and Dynamic Testing
If the image passes all scans, it is deployed to a staging environment. Here, dynamic application security testing (DAST) is performed by simulating real-world attacks against the running application. This uncovers issues that only appear at runtime.
5. Signing and Approval
The verified image is cryptographically signed using Cloud KMS and Google Cloud's Binary Authorization service. A human can also give manual approval at this stage. The signature proves the image passed all security checks.
6. Production Deployment with Policy Enforcement
Binary Authorization enforces that only signed images can be deployed to production. The deployment is verified against compliance policies (e.g., encryption checks). If everything passes, the new version goes live.
Consider a real company, FinPay, that processes online payments. They must comply with PCI DSS. They use Google Cloud and have a CI/CD pipeline built with Cloud Build.
Here's what their DevOps engineer does:
Define the security baseline: The engineer writes a set of rules in a configuration file. These rules specify that all containers must run on a Google-provided base image with no critical vulnerabilities, that the code must not contain any hardcoded API keys, and that all network connections must use TLS.
Integrate scanning into the pipeline: They add a step in the cloudbuild.yaml file that runs an SCA scan using a tool like Snyk or WhiteSource. They add another step that runs SAST using a tool like Checkmarx or Google Cloud's own security scanner. They configure a container scan using Cloud Build's built-in vulnerability scanner or a third-party integration.
Automate compliance checks: They create a custom compliance check that scans the deployment YAML for the correct security context, like ensuring the container does not run as root. This check runs after the container is built but before it is deployed.
Set up failure handling: If a high-severity vulnerability is found in a library, the pipeline is configured to fail immediately. The team receives a notification in Cloud Monitoring and a message in a Slack channel. The build is blocked from proceeding to staging.
Remediate and re-scan: The developer receives the report. They update the vulnerable library version. They commit the fix. The pipeline runs again from scratch. This time, the SCA scan passes.
Deploy with approval: After all scans pass, the pipeline deploys to a staging environment where DAST runs. If that passes, the engineer or a security lead must manually approve the deployment to production (a gated deployment).
Monitor post-deployment: Even after deployment, Cloud Monitoring watches for unusual behaviour that might indicate a security issue that no scan caught. This is a defence-in-depth approach.
The engineer uses tools like Binary Authorization to ensure only verified container images are deployed, and Cloud KMS to manage encryption keys. The whole process ensures that FinPay meets PCI DSS requirements without slowing down releases. Every deployment is automatically verified against their security policy.
The PCDOE exam will test your understanding of integrating security scanning, vulnerability management, and compliance checks into CI/CD pipelines. This is a major topic in Objective 5.4. The exam expects you to know which Google Cloud services are used for each type of check, and how they fit together in a pipeline.
Key exam topics include:
The difference between SAST, DAST, and SCA: You must know what each acronym stands for and when each type of scan is appropriate. The exam loves to ask which tool is used for scanning source code versus scanning running applications.
Binary Authorization: This is a Google Cloud service that ensures only container images that have been signed by an authorised signer (e.g., after passing all scans) can be deployed. You must understand how it works with Cloud Build and Container Registry.
Artifact Registry vulnerability scanning: The exam will test that you know Artifact Registry automatically scans container images and OS packages for known vulnerabilities, and that you can set policies to block deployments based on the severity of findings.
Cloud Build integration with third-party security tools: The exam expects you to know that Cloud Build can run custom steps for any security tool that has a containerised version. This includes tools like Snyk, Twistlock, or Aqua Security.
Compliance checks for regulations like PCI DSS, HIPAA, and FedRAMP: The exam may present scenarios where you need to implement a compliance check, such as encrypting data at rest using Cloud KMS and verifying it in the pipeline.
Secret management: Using Secret Manager to avoid hardcoding secrets in the pipeline. The exam will test that you know how to inject secrets securely into build steps.
Common traps in the exam:
Choosing a manual process instead of an automated one: The DevOps model is all about automation. Any answer that suggests manual security reviews as a primary mechanism is wrong.
Confusing SAST with DAST: SAST is source code scanning. DAST is runtime scanning. The exam will give you a scenario where a vulnerability only appears when the application is running, and you must pick DAST.
Ignoring the software supply chain: The exam emphasises that vulnerabilities in open-source dependencies are a major threat. SCA is the correct answer for scanning third-party libraries.
Choosing the wrong IAM role: You must know which service account or roles are needed to make the scanning work, such as roles/artifactregistry.reader or roles/cloudbuild.builds.editor.
The correct answer pattern for scenario questions often involves: identifying the type of vulnerability, selecting the appropriate scanning tool (SAST for code, SCA for dependencies, DAST for runtime), integrating it into the Cloud Build pipeline, and using Binary Authorization or Artifact Registry policies to enforce the results. Memorise the flow: commit, scan, build, sign, deploy.
Shift-left security means running vulnerability scans as early as possible in the CI/CD pipeline to catch issues before they reach production.
SAST scans the source code without running it, DAST scans the running application, and SCA scans third-party dependencies.
Artifact Registry automatically scans container images for known vulnerabilities and can block deployments based on severity policies.
Binary Authorization ensures only signed, verified container images are deployed to production environments.
Compliance checks must be automated as code in the pipeline, not performed as manual post-deployment audits.
Secret Manager should be used to inject secrets (like API keys) into pipeline steps without hardcoding them in source code.
Every security scan and compliance check should fail the pipeline if a critical or high-severity issue is found, preventing unsafe deployments.
The software supply chain includes source code, third-party libraries, container images, and infrastructure definitions, and every component must be scanned.
These come up on the exam all the time. Here's how to tell them apart.
SAST (Static Application Security Testing)
Scans source code without running it
Catches vulnerabilities early in development
Cannot find runtime configuration issues
DAST (Dynamic Application Security Testing)
Scans the running application
Finds vulnerabilities only visible at runtime
Requires a deployed test environment
SCA (Software Composition Analysis)
Focuses on third-party libraries and dependencies
Checks against known vulnerability databases
Does not analyse custom application logic
SAST (Static Application Security Testing)
Focuses on the team's own source code
Looks for insecure coding patterns
Does not check external libraries
Binary Authorization
Enforces that images are cryptographically signed
Controls which images can be deployed
Relies on a separate signing process
Artifact Registry Vulnerability Scanning
Automatically scans images for known vulnerabilities
Provides a severity report for each image
Does not enforce deployment policies
Shift-Left Security
Runs security tests early in the pipeline
Catches issues when they are cheap to fix
Happens before production deployment
Shift-Right Security
Runs security tests after production deployment
Catches issues that only appear in production
Happens as part of live monitoring and testing
Cloud Build
Orchestrates the CI pipeline (build, test, scan)
Runs custom steps for security tools
Triggers on code commits
Cloud Deploy
Manages CD pipeline (continuous delivery)
Handles progressive deployments (canary, blue-green)
Integrates with Binary Authorization for approval
Mistake
If my code is scanned in the CI pipeline, I only need to scan it once there.
Correct
Security scanning should happen at multiple stages: when code is committed, when dependencies are added, when images are built, and when deployed to each environment.
People think a single scan is enough, but vulnerabilities can be introduced at any stage, and a scan at the wrong point may miss issues that only appear later in the pipeline.
Mistake
Compliance checks are manual paperwork that happens after deployment.
Correct
Compliance checks should be automated code-as-policy checks that run inside the pipeline before deployment, automatically verifying that the deployment meets regulatory requirements.
Beginners often picture compliance as a separate audit process, not understanding that in DevOps, compliance is automated and enforced in code.
Mistake
Security scanning is only for finding bugs in the code I wrote.
Correct
Most security vulnerabilities in modern applications come from third-party open-source libraries and dependencies, not from the code the team writes. SCA scanning is critical.
New developers often focus only on their own code, not realising that the software supply chain is a huge attack vector.
Mistake
If the pipeline passes all scans, the deployment is completely secure.
Correct
No scan catches everything. Security scanning reduces risk but does not eliminate it. You still need monitoring, logging, and manual security reviews for complex logic.
There is a false sense of finality. Beginners want a pass/fail to mean 'safe', but security is a continuum, not a binary state.
Mistake
I should run security scans only in the production environment because that is where attacks happen.
Correct
Security scans should be run as early as possible in the pipeline (shift left) so that vulnerabilities are found and fixed before they reach production, reducing cost and risk.
People think production is the only place that matters, but finding a flaw in production is much more expensive and dangerous than finding it in development.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SAST (Static Application Security Testing) scans your source code without running it, finding vulnerabilities like hardcoded passwords. DAST (Dynamic Application Security Testing) runs tests against the live application to find runtime issues like misconfigured authentication.
Binary Authorization ensures that only container images signed by an authorised authority (like after passing all scans) can be deployed to production, preventing unverified or compromised images from being used.
Yes, because over 90% of modern applications use open-source libraries, and these libraries often have known vulnerabilities. Software Composition Analysis (SCA) tools check them automatically.
Secret Manager securely stores sensitive information like API keys and database passwords, and injects them into pipeline steps at runtime, so secrets are never hardcoded in source code or configuration files.
You write custom policy-as-code rules that check for specific requirements, such as encryption at rest (using Cloud KMS) and secure network configurations, and run these checks as automated steps in Cloud Build before deployment.
The pipeline stops at the failing step, the build is marked as failed, alerts are sent to the team (e.g., via email or Slack), and the unsafe code is prevented from reaching production. The developer then fixes the issue and re-runs the pipeline.
Cloud Build is the CI/CD service that orchestrates the pipeline. It runs the security scanning tools as custom steps, handles dependencies, and manages the flow from code commit to deployment, triggering scans at each stage.
You've finished Security and Compliance in DevOps Pipelines. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?