Professional Cloud Security Engineer

Automating security scanning for Common Vulnerabilities and Exposures (CVEs) through a continuous integration and delivery (CI/CD) pipeline.

When a team builds container images or deploys artifacts, they can automatically check for known vulnerabilities before the code reaches production. The pipeline uses Container Analysis to scan images stored in Artifact Registry or Container Registry as soon as a build finishes. The scan compares the image's software packages against the latest CVE database and produces a list of vulnerabilities with severity levels. A Cloud Build step can then fail the pipeline if a vulnerability exceeds a defined severity threshold, preventing the image from being deployed. This process moves the security check to the left — earlier in the development cycle — so that developers fix issues before they merge or release. The same scanning can also run on a schedule to catch newly disclosed CVEs in images that are already running.

Configuring Binary Authorization to secure GKE clusters or Cloud Run.

Binary Authorization enforces that only trusted container images can be deployed to GKE or Cloud Run. An attestor, such as a third-party tool or the project's own cryptographic key, signs an image after it passes required checks, like a vulnerability scan or a manual review. The pipeline must create an attestation and store it in Container Analysis before the image can be deployed. A Binary Authorization policy, attached to a platform or a project, specifies what attestors are required and whether images without attestation are allowed or blocked. When a deployment request arrives, Binary Authorization checks the attestation and either permits or denies the action. For GKE, the admission controller intercepts the request at the AdmissionReview stage; for Cloud Run, the check happens during the service or revision creation. This setup ensures that only images that have been verified by the agreed-upon process reach production.

Automating virtual machine and container image creation (e.g., hardening, maintenance, VM patch management).

Teams can automate the creation of hardened virtual machine images and container images so that every new instance starts with a secure baseline. For VMs, tools like Packer or Compute Engine's custom image builder can provision a VM, apply security hardening scripts (disable unnecessary services, tighten permissions, install agents), and then capture an image. For containers, a Dockerfile or Cloud Build configuration can start from a minimal base image, apply security patches, and run a vulnerability scan before tagging the image as ready. VM patch management can be automated through OS Config Management or Patch Deployment in Compute Engine, which lets you apply operating system updates to running instances on a schedule or on demand. For container images, you rebuild and redeploy whenever a base image receives a patch; the Cloud Build trigger can watch for changes to a base image in Artifact Registry and automatically rebuild dependent images. These automation practices reduce the window of exposure and keep both VMs and containers consistent across environments.

Managing policy and drift detection at scale (e.g., cloud security posture management, custom organization policies and custom modules for Security Health Analytics).

When an organization manages many projects, it needs automated ways to enforce security policies and detect when resources drift from the desired state. Organization Policy Service lets you set constraints at the organization or folder level, such as “deny public IP on VMs” or “require CMEK for disks,” and those constraints apply to all child resources. Cloud Security Posture Management features in Security Command Center continuously evaluate your GCP environment against compliance benchmarks (like CIS, PCI DSS) and flag resources that violate the rules. You can also write custom modules for Security Health Analytics to detect patterns that matter specifically to your organization, such as a custom logic that checks for a specific tag on resources or a particular IAM binding. Drift detection works by comparing the current state of resources against a desired configuration, which you can define using Infrastructure as Code templates (e.g., Terraform) or through Cloud Asset Inventory snapshots. When a change occurs outside your IaC pipeline, automated alerts or remediation workflows (using Cloud Functions or Cloud Build triggers) can revert the change or notify the security team. This layered approach ensures that policies are consistently applied and any deviations are caught quickly.