Quality Control and Security Testing

Introduction to Security Testing on GCP

In the cloud, security is a shared responsibility. While Google secures the infrastructure, you are responsible for securing your applications and data. Security Testing is the practice of proactively finding weaknesses in your cloud environment. This involves Vulnerability Scanning (automated discovery) and Penetration Testing (simulated manual attacks).

For the GCP Professional Cloud Architect, the goal is to integrate security testing into the SDLC to ensure that vulnerabilities are caught before they can be exploited.

Plain-Language Explanation: Security Testing

Analogy 1 — The Home Security System

Vulnerability Scanning is like having an automated robot that walks around your house every night and checks if any doors or windows are unlocked. It's fast and covers everything. Penetration Testing is like hiring a professional locksmith to try and actually "break in" to your house. They will look for clever ways to bypass the locks that the robot might have missed.

Analogy 2 — The Physical Exam vs. Stress Test

A Vulnerability Scan is like a routine physical exam. The doctor checks your blood pressure, heart rate, and basic health markers (Standard vulnerabilities). A Penetration Test is like a cardiac stress test. The doctor makes you run on a treadmill to see how your heart behaves under extreme pressure to find hidden weaknesses.

Analogy 3 — The Castle Walls

You can build the thickest walls in the world, but if the back door is left open, the castle is not secure. Vulnerability Scanning ensures the doors are shut. Penetration Testing checks if someone can tunnel under the walls or climb over them using a ladder you didn't see.

Key Security Testing Tools on GCP

1. Security Command Center (SCC)

SCC is the centralized security management and risk platform for Google Cloud.

• Vulnerability Management: Automatically scans for common misconfigurations (e.g., public buckets, open firewall ports) and software vulnerabilities.
• Event Threat Detection: Monitors logs for signs of active attacks (e.g., brute force, malware).

2. Cloud Security Scanner

A specialized tool for Web Security Scanning (DAST) of App Engine, GKE, and Compute Engine applications.

• Scans for: XSS, Cleartext passwords, Outdated libraries, and Mixed content.
• Note: It only scans public URLs or those reachable within a VPC.

3. Container Analysis

Automatically scans container images in Artifact Registry for known vulnerabilities (CVEs) as part of your CI/CD pipeline.

Planning a Penetration Test

Google Cloud allows you to perform penetration testing on your own resources without prior notification, but you must follow certain rules:

• No Impact on Others: You cannot attack Google's infrastructure or other customers' resources.
• Legal Compliance: You must comply with the Cloud Data Processing Addendum (CDPA) and other terms of service.
• Third-Party Scanners: If using third-party tools (like Burp Suite or Nessus), ensure they are configured to only target your specific project IDs and IP addresses.

Authorized Testing Rules of Engagement (RoE)

Before any pen test against GCP resources, the architect signs off on a Rules of Engagement document so legal, security, and platform teams agree on the boundaries. The RoE is what keeps the test from being mistaken for a real attack and triggering automated incident response.

Mandatory RoE clauses on GCP

• Scope by project ID and CIDR: List the specific projects/<id> and external/internal IP ranges that are in scope. Anything outside is off-limits, including shared VPC host projects unless explicitly added.
• Testing window: Define a UTC start/end window. Outside that window, any traffic from the tester's source IPs is treated as hostile and may trigger Cloud Armor auto-blocks or Event Threat Detection findings.
• Source IP allowlist: Capture the tester's source IPs so the SOC can correlate scanner traffic. Some teams whitelist those IPs in Cloud Armor edge-security policies during the window to avoid false positives.
• Data handling rules: State whether the tester may exfiltrate sample data, screenshots of customer PII, or Secret Manager values. Production data is usually masked or replaced with synthetic records.
• Emergency stop contact: Name a Google Cloud admin who can revoke the tester's IAM access via gcloud projects remove-iam-policy-binding if the test goes wrong.

Pre-test checklist

1. Snapshot Persistent Disks and Cloud SQL instances so destructive tests can be rolled back.
2. Tag all test resources with a label like pen-test=true so logs in Cloud Logging can be filtered.
3. Notify the on-call SRE rotation; some organizations also notify Google Support if the test will generate >1 Gbps of traffic (which can look like a DDoS).
4. Confirm with legal that the CDPA and customer contracts permit the test.

Web Security Scanner (Free Tier)

Web Security Scanner is the GCP-native DAST tool, formerly called Cloud Security Scanner. It is the cheapest entry point for web app vulnerability scanning and is included with the Security Command Center Standard tier.

What it scans

• Public URLs hosted on App Engine, Compute Engine, or GKE
• Internal URLs reachable from the scanner's worker pool inside your VPC (with Custom scans)
• Authenticated areas via Google account, non-Google account, or custom login

Vulnerability classes detected

• Cross-site scripting (XSS) — both reflected and stored
• Mixed content (HTTPS pages loading HTTP assets)
• Outdated libraries with known CVEs (jQuery, AngularJS, etc.)
• Cleartext password forms served over HTTP
• Insecure cookies missing Secure or HttpOnly
• Flash injection (legacy)

Scan modes

• Managed scans (Premium tier) — automatically discover public App Engine apps weekly, no configuration needed.
• Custom scans — you specify start URL, authentication, blacklist patterns, and User-Agent. Useful for staging environments before production deploys.

Limitations the exam loves

• Cannot test API-only backends (no UI to crawl) — use a third-party DAST or SAST instead.
• Will not perform destructive tests like SQL injection that modify state.
• No authenticated GraphQL mutation coverage.
• Rate-limited; pair with Cloud Armor rate-limiting rules so the scanner's own traffic doesn't trip your WAF.

Third-Party DAST: Burp Suite and OWASP ZAP

When Web Security Scanner is too shallow, architects bring in Burp Suite Professional or OWASP ZAP. Both run fine against GCP workloads but require careful configuration to stay inside the RoE.

Deployment patterns

• From a tester laptop: Quickest. Public IP must be in the Cloud Armor allowlist. Suitable for external surface testing.
• From a GCE jump host inside the VPC: Required to test internal load balancers, Cloud Run with INTERNAL ingress, or GKE Services with private IPs. Spin up a hardened e2-standard-4 VM in a tester subnet, install Burp/ZAP, and reach it via IAP TCP tunneling (gcloud compute start-iap-tunnel).
• From Cloud Build for CI/CD DAST: Use the official ZAP image in a Cloud Build step to baseline-scan staging URLs on every deploy. Fail the build on High findings.

Configuration musts

• Target scope locked to your project domains/IPs to prevent accidental cross-tenant attacks.
• Throttling: Limit concurrent requests so you don't trigger Cloud Armor rate-based bans on your own scanner.
• Authentication recording: Use Burp's session handling rules to log in via Identity Platform or IAP before fuzzing.
• Findings export: Push JSON results to a Cloud Storage bucket and ingest into Security Command Center as custom findings via the SCC API.

Container Threat Detection (CTD)

Container Threat Detection is a Security Command Center Premium service that watches GKE node behavior at runtime, complementing the image-scanning done by Container Analysis.

Detection signals

• Added Binary Executed — a new binary not in the original image is executed (classic post-exploit indicator).
• Added Library Loaded — a shared library loaded that wasn't in the image.
• Reverse Shell — a process redirects stdin/stdout to a remote socket.
• Suspicious Shell Activity — heuristics for crypto-miners and known offensive tools.
• Execution: Added Malicious Binary — hash matches a known threat-intel feed.

How it works

A small kernel-level instrumentation runs on each Container-Optimized OS (COS) node. Events are streamed to SCC and surfaced as THREAT findings. No sidecar required, no per-pod overhead config.

Enablement

1. Use Container-Optimized OS node images (the default for GKE Autopilot and most Standard clusters). Ubuntu images are NOT supported by CTD.
2. Enable GKE Security Posture dashboard.
3. Turn on the Container Threat Detection service in SCC at the org or project level.

What CTD does NOT cover

• Cloud Run workloads — no runtime visibility there; rely on Cloud Logging and image scanning.
• GKE on-prem / Anthos clusters outside Google Cloud — use GKE Enterprise security features instead.
• Pre-deploy vulnerabilities in images — that's Container Analysis's job.

Container Analysis Vulnerability Scanning

Container Analysis continuously scans container images in Artifact Registry (and legacy Container Registry) for known CVEs. It is the canonical "shift-left" CVE control on GCP.

Two scanning modes

• On-push scanning — every new image pushed is scanned once, results cached.
• Continuous scanning — images pulled within the last 30 days are rescanned as new CVEs appear in the upstream database. This is how you catch a CVE published after you shipped.

OS and language support

• OS packages: Debian, Ubuntu, Alpine, CentOS, RHEL.
• Language packages: Go, Java (Maven), Python (PyPI), Node.js (npm). Coverage expands periodically — check docs before exam.

Integration with Binary Authorization

The most exam-relevant pattern: Container Analysis results feed Binary Authorization attestors. An admission controller in GKE refuses to deploy any image without a "no critical CVEs" attestation. This is the GCP-blessed way to enforce "no vulnerable images in production" — far stronger than periodic scanning alone.

gcloud commands worth memorizing

• gcloud artifacts docker images list --show-occurrences — list scan findings.
• gcloud artifacts docker images describe <image> --show-package-vulnerability — drill into one image.
• gcloud container binauthz attestations create ... — sign an image after a clean scan.

OSS Vulnerabilities Database (OSV) and OSV-Scanner

Google maintains the OSV (Open Source Vulnerabilities) database at osv.dev — a distributed, language-agnostic feed of vulnerabilities affecting open-source packages. Container Analysis consumes OSV data internally, but architects also use it directly.

Why OSV matters

• One schema, many ecosystems: npm, PyPI, Go, Maven, crates.io, RubyGems, NuGet, Linux distros, Android, OSS-Fuzz.
• Precise version ranges: Vulnerabilities map to exact affected commits/versions, so scanners avoid the false-positive churn of CVE-only databases.
• Public API: Free, no auth — query by package name, ecosystem, or commit hash.

OSV-Scanner CLI

The osv-scanner Go binary scans lockfiles (package-lock.json, Pipfile.lock, go.sum, etc.), SBOMs (SPDX, CycloneDX), or container images and reports OSV matches:

osv-scanner --lockfile=package-lock.json
osv-scanner --sbom=app.spdx.json
osv-scanner -r ./repo

Where it fits in CI/CD

• Run osv-scanner in Cloud Build alongside docker build. Fail the build on HIGH/CRITICAL.
• Use Cloud Scheduler + Cloud Run job to rescan production manifests weekly and post deltas to Pub/Sub for ticketing.
• For SBOM-driven workflows, generate an SPDX SBOM at build time, store in Cloud Storage, and scan it on a schedule independent of rebuilds.

OSV vs Container Analysis

• OSV-Scanner = lockfile/SBOM-driven, runs anywhere, free, open source.
• Container Analysis = registry-driven, managed, integrates with Binary Authorization, charged per image scan beyond the free tier.

Use both: OSV for source-side gating, Container Analysis for registry/runtime gating.

Compliance Scanner Alignment (PCI DSS, HIPAA, NIST)

Pen-test results have to feed compliance audits. Security Command Center Premium ships Compliance reports that map SCC findings to specific control frameworks so auditors can see coverage without you hand-mapping every CVE.

Frameworks pre-mapped in SCC

• PCI DSS v3.2.1 and v4.0 — relevant whenever cardholder data flows through GCP.
• HIPAA / HITECH — for protected health information; pair with a signed BAA.
• NIST 800-53 moderate and high baselines.
• NIST CSF.
• ISO 27001:2013.
• CIS GCP Foundations Benchmark v1.x / v2.x.

How alignment works

Each SCC detector (e.g., PUBLIC_BUCKET_ACL, MFA_NOT_ENFORCED, OPEN_FIREWALL) carries metadata tagging which compliance controls it satisfies. Run an organization-level compliance export and you get a coverage report: e.g., "PCI DSS 1.2.1 — pass on 47/50 in-scope projects, fail on 3."

Aligning pen test reports

A practical pattern:

1. Tester produces findings in OWASP Risk Rating or CVSS v3.1 format.
2. Map each finding to a control ID (PCI DSS 6.5.1, HIPAA 164.312(e)(1), etc.) — often as a column in the report.
3. Ingest the report into SCC as custom findings via the SCC API so the compliance dashboard shows tester-derived issues alongside automated scanner findings.
4. Compliance auditor exports a single dashboard view at audit time.

This prevents the classic problem where the pen-test PDF lives in SharePoint while SCC shows "all green" — making the org look compliant when it isn't.

CIS Benchmark for Google Cloud

The CIS Google Cloud Platform Foundation Benchmark is the de-facto baseline configuration audit. It enumerates ~70 controls across IAM, logging, networking, KMS, Compute, Storage, and GKE.

Sample controls

• 1.1 — Ensure that corporate login credentials are used (no @gmail.com for org admins).
• 1.4 — Ensure that there are only GCP-managed service-account keys for each service account.
• 3.6 — Ensure that SSH access is restricted from the internet (no 0.0.0.0/0 on port 22).
• 5.1 — Ensure that Cloud Storage buckets are not anonymously or publicly accessible.
• 6.2.x — Ensure Cloud SQL instances use TLS and have backups.
• 7.x — BigQuery dataset ACLs.

Automated assessment options

• Security Command Center Premium — CIS Benchmark is one of the built-in compliance reports; no extra setup.
• Cloud Asset Inventory + Policy Analyzer — write Organization Policy constraints that prevent CIS violations (e.g., constraints/compute.requireOsLogin).
• Forseti (legacy) or Cloud Custodian (open source) — for orgs that pre-date SCC Premium or want declarative rules.
• Open Policy Agent (OPA) in CI/CD — check Terraform plans against CIS rules before apply.

CIS Benchmark for GKE

A separate CIS GKE Benchmark covers Kubernetes-specific items: PSP/PSS, RBAC, network policy, audit log destinations, control-plane endpoint exposure. SCC's GKE Security Posture dashboard auto-checks most CIS GKE items on every cluster.

Cadence

Run a full CIS scan monthly at minimum; SCC actually checks continuously, but compile a snapshot monthly for the security review meeting.

GKE Security Posture Dashboard

The GKE Security Posture dashboard is the single pane of glass for cluster security in the Cloud Console. It rolls up findings from multiple scanners.

What it surfaces

• Workload configuration audits — flags pods running as root, missing resource limits, hostPath mounts, privileged containers, etc., mapped to CIS GKE Benchmark controls and Pod Security Standards (Baseline / Restricted).
• Vulnerability scanning — language-package CVEs in running workloads, sourced from Container Analysis continuous scans.
• Misconfiguration severity — Critical, High, Medium, Low.
• Cluster-level checks — control-plane endpoint exposure, RBAC, audit logging destinations.

Enabling it

For Autopilot clusters, posture is on by default. For Standard clusters:

gcloud container clusters update CLUSTER_NAME \
    --location=REGION \
    --security-posture=standard \
    --workload-vulnerability-scanning=standard

standard (free) covers configuration auditing and basic language-package CVEs. enterprise (paid) adds advanced vulnerability scanning and additional CIS coverage.

How it links to other tools

• Findings appear in the GKE → Security posture tab AND in Security Command Center as MISCONFIGURATION / VULNERABILITY findings.
• Combine with Binary Authorization for preventive control and Container Threat Detection for runtime detection — together those three form the GCP-native equivalent of a CNAPP for GKE.

In-Scope vs Out-of-Scope GCP Services for Pen Testing

Google's Customer Penetration Testing policy lets you test resources you own — but the policy draws sharp lines around what constitutes "your resource" vs Google's shared infrastructure.

Clearly in-scope (test freely)

• Compute Engine VMs in your project
• GKE clusters and workloads in your project
• Cloud Run and Cloud Functions services you deployed
• App Engine Standard and Flex apps you deployed
• Web apps fronted by Cloud Load Balancing that you own
• Cloud SQL and Spanner instances you own (network and authentication surface)
• Custom code running on Dataflow, Dataproc, or Composer jobs you own

Out-of-scope (do NOT test)

• Google's control plane — the APIs at *.googleapis.com, IAM endpoints, the Cloud Console itself.
• Other tenants' resources — anything in a project you don't own, even if you find it via misconfigured public access.
• Google-managed services' internals — the backing storage of BigQuery, the internal nodes of a managed Memorystore Redis, the Cloud KMS HSMs.
• Underlying physical infrastructure — datacenter networks, hypervisors, the production fleet.
• Phishing or social engineering against Google employees.

DoS / load testing nuance

Denial of service testing is a special category:

• You may NOT perform a real DoS test against your own GCP resources without prior written approval from Google Support — high-volume traffic can affect shared infrastructure.
• You CAN run load tests within published service quotas and your own bandwidth budget.
• Cloud Armor's adaptive protection can be tested with simulated traffic only in test projects, and never targeting production endpoints used by external customers.

Reporting Google vulnerabilities

If during your authorized test you discover a vulnerability in Google's platform itself (e.g., an IAM bypass, a control-plane bug), do NOT exploit it. Report it through the Google Vulnerability Reward Program (VRP) at bughunters.google.com. Exploiting it violates the AUP and may end your account.

SAST vs. DAST

• SAST (Static Analysis): Analyzes source code before it's compiled. Finds issues like hardcoded secrets or insecure coding patterns. (e.g., GitHub Advanced Security, Snyk).
• DAST (Dynamic Analysis): Analyzes the running application. Finds issues like session management flaws or injection vulnerabilities. (e.g., Cloud Security Scanner).

Architect's Insight: On the PCA exam, if a scenario asks how to "Continuously monitor for security risks and misconfigurations across the entire organization," the answer is Security Command Center (Standard or Premium). ::

FAQ — Security Testing on GCP

Q1. Do I need Google's permission to run a pen test?

No. For the majority of services (GCE, GKE, App Engine), you can perform your own security testing at any time without notifying Google.

Q2. Is Cloud Security Scanner the same as SCC?

Cloud Security Scanner is a feature or detector within SCC. SCC is the broader platform, while Security Scanner specifically focuses on web application vulnerabilities.

Q3. How can I automate security scanning in my CI/CD pipeline?

Use Cloud Build to trigger Container Analysis for your images and run SAST tools on your code. You can also trigger a Cloud Security Scanner run after deploying to a staging environment.

Q4. What is a "False Positive"?

A false positive is when a security tool reports a vulnerability that isn't actually a risk. Managing false positives is a key part of an architect's job to avoid wasting the security team's time.

Q5. Can SCC find vulnerabilities in my on-premises servers?

By default, SCC focuses on Google Cloud. However, by using the Ops Agent or exporting logs from on-premises systems to Cloud Logging, SCC can analyze certain events and threats in a hybrid environment.