Managing operations and threat detection

Automating infrastructure and application security

Vulnerability scanning in CI/CD

Artifact Analysis (formerly Container Analysis) scans images and packages in Artifact Registry and produces vulnerability occurrences (CVE, severity, fix available).

• Automatic scanning runs when an image is pushed, and continuous analysis re-checks stored images for newly published CVEs for a period afterwards (images not pulled for a long time stop being updated).
• On-demand scanning (gcloud artifacts docker images scan) scans a local image or one in a registry before pushing, so a pipeline can fail early.
• Supports OS packages and language packages (Java, Go, Node, Python and others). It can also generate SBOMs.
• In Cloud Build, run a scan step and check results with --format to fail the build above a chosen severity. Cloud Build also creates SLSA build provenance attestations (verifiable record of what built the image from which source), and can run in private pools inside your VPC and perimeter.
• Shift left: also scan Infrastructure as Code (Terraform plans) with policy checks, scan source dependencies, and use Assured Open Source Software or an internal remote repository for dependencies.

Binary Authorization

Binary Authorization is a deploy-time control for GKE and Cloud Run (and GKE on-premises/attached clusters). It admits only images that satisfy a policy.

Two-person flow: the build pipeline signs after tests; a separate security process signs after vulnerability review. The policy requires both attestors, which enforces separation of duties. The signing keys live in Cloud KMS with IAM limited to the pipeline identity. Binary Authorization needs images in a registry the cluster can reach, and it doesn’t stop an already running workload unless continuous validation is on.

Hardened images and patching

• Build golden images with an automated pipeline (Packer or EC-style image builders on Cloud Build), applying CIS-style hardening and baking in agents. Publish in an image family and deprecate older ones. Restrict use to your projects with compute.trustedImageProjects.
• Prefer Shielded VM images (secure boot, vTPM, integrity monitoring) and enforce with compute.requireShieldedVm.
• For containers: minimal or distroless base images, no root user, rebuild regularly, scan in the registry, and sign. On GKE use Container-Optimized OS, Autopilot or node auto-upgrade, private nodes, Pod Security Standards, network policy and Workload Identity Federation.
• VM Manager OS Patch Management (OS Config agent) runs patch jobs (on demand), patch deployments (scheduled, recurring, with rollout in zones), reports OS inventory and vulnerability reports for installed packages. Use maintenance windows and rollout budgets, and combine with managed instance group rolling replacement for immutable updates.
• Prefer replacing instances with a new image over patching in place when workloads are in managed instance groups.

Policy and drift detection at scale

Cloud security posture management (CSPM) keeps the estate in line with your standard.

Custom modules for Security Health Analytics let you write a detector in CEL over a resource’s properties (for instance “any Compute instance whose label data is pci has an external IP”), with severity, recommendation and scope. They are available in SCC Premium and Enterprise. Custom organization policy constraints block it at creation. Detection finds what already exists, prevention covers what’s new. Use both.

Logging, monitoring and detection

Designing the logging strategy

• Central security logging project receives an aggregated sink at the organisation (with includeChildren) so no project can opt out. Keep application logs and security logs separate.
• Decide retention by regulation, put it on a locked bucket (retention that cannot be shortened) or an exported Cloud Storage bucket with Bucket Lock.
• Use CMEK for log buckets and restrict who can read. Separate admin roles from viewers.
• Define log-based metrics and alerts for the sensitive operations (IAM policy changes, custom role changes, firewall and VPC changes, audit configuration changes, key destruction) like the CIS benchmark recommends.

Cloud Audit Logs

You can exempt principals from Data Access logs (for noisy service accounts), but don’t exempt humans. Log entries show the caller, method, resource and request/response. Data Access logs are the answer to “who read this table or secret”, and you must have enabled them before the event.

Reading them: roles/logging.viewer sees Admin Activity and not Data Access. roles/logging.privateLogViewer sees both. In buckets, use log views to give narrower access.

Log Router, buckets and sinks

The Log Router processes every log entry through sinks. Each sink has a destination, an inclusion filter and optional exclusion filters.

Facts:

• A sink has a writer identity (service account) that you must grant on the destination (bigquery.dataEditor, storage.objectCreator, pubsub.publisher, logging.bucketWriter). A common failure is a sink that exports nothing because that grant is missing.
• Aggregated sinks at organization or folder level export logs from all child projects (set includeChildren). Sinks are not retroactive.
• Built-in buckets: _Required (400 days, fixed, Admin Activity, System Event, Access Transparency), _Default (30 days, configurable). User-defined buckets allow retention from 1 to 3,650 days, a chosen region, CMEK, and locking.
• To keep logs out of _Default (and avoid ingestion charges) edit or disable the _Default sink and exclude.
• Log Analytics: upgrade a bucket to run SQL over logs in the console, and create a linked BigQuery dataset to join logs with other data without copying.
• Exporting to external security systems: Pub/Sub sink plus a Dataflow template to the SIEM, or ingest to Google Security Operations through its native Google Cloud integration. Pub/Sub preserves order of delivery only within limits and has retention, so plan for replays.

Network logs and traffic analysis

Choose: Flow logs to see who talked to whom, Packet Mirroring when payload is needed, Cloud IDS for managed signature-based detection, Cloud NGFW Enterprise when blocking is needed.

Securing access to logs

Treat logs as sensitive (they can hold user data and secrets). Use dedicated projects, privateLogViewer only for security analysts, log views to expose subsets, CMEK on buckets, VPC-SC around Logging and BigQuery, and an exported evidence bucket with retention lock so even admins can’t delete it. Don’t give developers roles/logging.admin.

Security Command Center

Security Command Center (SCC) is the central security and risk platform. It is activated at the organisation level.

Key detectors:

Working with findings:

• Findings have severity, state (ACTIVE / INACTIVE), a category, the resource, and security marks. Mute rules hide known-accepted findings (static or dynamic). Filter by attack exposure.
• Export: continuous exports to Pub/Sub and BigQuery, and notifications (NotificationConfig with a filter) to Pub/Sub for automation.
• Roles: securitycenter.admin, securitycenter.adminEditor, findingsViewer, findingsEditor. Grant narrowly. Use folder or project-level roles for teams.
• Compliance dashboard maps findings to CIS Benchmarks, PCI DSS, NIST 800-53, ISO 27001.
• Remediate by workflow: finding to Pub/Sub, to Cloud Run or a Workflows definition, to fix (for example remove a public IAM binding), with human approval for risky actions.

Incident response on Google Cloud

1. Detect: SCC finding, log alert, Cloud IDS alert.
2. Contain: isolate a VM with a deny-all firewall rule using a secure tag or service account target, remove external IP, remove or disable service account keys, revoke sessions, suspend a user, remove IAM bindings.
3. Preserve evidence: snapshot the disk (and memory if needed) into a separate forensics project, keep logs in a locked bucket. Don’t terminate the VM before snapshotting if you need disk evidence.
4. Investigate: Log Analytics SQL across audit and flow logs, SCC attack paths, Cloud Asset Inventory history (what changed and when).
5. Eradicate and recover: rebuild from a clean image, rotate secrets and keys, patch root cause.
6. Learn: update detections and org policies.

Choosing the control

Common traps

• Data Access logs are off by default and not retroactive.
• Admin Activity cannot be turned off, and the _Required bucket can’t be changed.
• Sinks need their writer identity granted. Exclusions apply before storing.
• Cloud IDS only alerts. It’s not a firewall.
• Binary Authorization checks at deploy, not running Pods unless continuous validation is used.
• Rotating an image tag doesn’t re-trigger attestation, so use digests.
• SCC Standard doesn’t include threat detection services.