Mitigate OWASP Top 10:2025 on Google Cloud

This document identifies the Google Cloud services and mitigation strategies that can help you defend against the application-level attacks that are outlined in OWASP Top 10:2025. Created by the Open Web Application Security (OWASP) Foundation, OWASP Top 10:2025 is a list of the top 10 security risks in a software development lifecycle (SDLC). Although no service can guarantee full protection against these risks, applying these services when they make sense in your architecture can contribute to a strong multi-layer security solution.

Google infrastructure is designed to help you build, deploy, and operate services with robust security controls. Physical and operational security, data encryption at rest and in transit, and many other foundational infrastructure protections are managed by Google. You inherit these benefits by deploying your applications to Google Cloud, but you might need to take additional measures to help protect your application against specific attacks.

Note: Even though Google Cloud provides robust perimeter and runtime defenses, security is a shared responsibility. Mitigating OWASP risks effectively requires integrating security early in your software development lifecycle (SDLC). Use the following services alongside secure-by-default coding frameworks, regular developer training, and proactive threat modeling.

Compliance matrix

The Google Cloud services listed in the following table can help defend against the top 10 security risks that are identified by OWASP Top 10:2025:

OWASP Top 10:2025 category	Primary Google Cloud and Wiz controls
A01: Broken Access Control	Access Context Manager, Agent Gateway, Agent Identity, Apigee, Google Cloud Armor, Firebase App Check, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Identity-Aware Proxy (IAP), Identity and Access Management (IAM), Organization Policy Service, VPC Service Controls, Wiz Cloud
A02: Security Misconfiguration	Access Context Manager, Cloud Asset Inventory, Google Security Operations, Organization Policy, Security Command Center Premium, VPC Service Controls, Wiz Cloud
A03: Software Supply Chain Failures	Artifact Registry, Assured Open Source Software (Assured OSS), Binary Authorization, Cloud Build, Cloud Deploy, Cloud Workstations, CodeMender, Wiz Code
A04: Cryptographic Failures	Apigee, Certificate Authority Service, Certificate Manager, Cloud Key Management Service, Cloud Load Balancing, Cloud Workstations, Confidential Computing, Organization Policy, Secret Manager, Sensitive Data Protection, Wiz Cloud
A05: Injection	Apigee, Cloud Armor, CodeMender, Firebase Security Rules, Cloud Next Generation Firewall (Cloud NGFW), Model Armor, Security Command Center Premium, VirusTotal, Wiz Code
A06: Insecure Design	Apigee, CodeMender, Mandiant, Wiz Cloud
A07: Authentication Failures	Access Context Manager, Agent Identity, Apigee, Cloud Armor, Cloud Identity, Firebase App Check, Firebase Authentication, Google Cloud Fraud Defense, IAM (Privileged Access Manager, Workload Identity Federation, and Workforce Identity Federation), IAP, Identity Platform, Security Command Center Premium, Secret Manager, Titan Security Keys, Wiz Code
A08: Software or Data Integrity Failures	Artifact Analysis, Assured OSS, Binary Authorization, Cloud Armor, Cloud Build, Cloud Deploy, Firebase App Check, Security Command Center Premium, VirusTotal, Wiz Defend
A09: Security Logging & Alerting Failures	Access Approval and Access Transparency, Apigee, Google SecOps, Cloud Logging, Cloud Monitoring, Sensitive Data Protection, Wiz Defend
A10: Mishandling of Exceptional Conditions	Cloud Armor, Cloud Load Balancing, Error Reporting, Model Armor

Google Cloud services

The following sections describe OWASP Top 10 best practices for core Google Cloud services.

Access Approval and Access Transparency

Access Transparency and Access Approval enable verification of cloud provider access. Using Access Transparency, you can record the reason for each access that Google personnel make. Access Approval lets you approve or dismiss requests for access by Google personnel who are working to support your service.

Applies to A09: Security Logging & Alerting Failures.

Review the following best practices:

• Automate the access approval process. To do so, configure Access Approval to send incoming access approval request metadata to a Pub/Sub topic. Create a Pub/Sub subscription that pushes the JSON payload to your custom webhook endpoint (such as an authenticated Cloud Run service, Cloud Run functions, or an enterprise API gateway) for processing.
• Treat Access Transparency logs as critical security telemetry. Create logs-based metrics and alerting policies in Monitoring to flag your security operations center (SecOps) if Google personnel access sensitive resources without an active, corresponding support ticket.
• Export Access Transparency logs directly to Google SecOps or your centralized enterprise SIEM.
• Create a compliance policy to audit your log streams regularly and verify that auto_approved emergency access events correlate to a documented, high-severity incident.
• For cryptographic control, use Key Access Justifications to force the system to programmatically request a key-decryption approval.

Access Context Manager

Access Context Manager is Google Cloud's context-aware access engine. Access Context Manager lets you define attribute-based access levels (such as client IP address ranges, device security posture, and geographic location) for IAP, VPC Service Controls, and IAM.

Applies to the following:

• A01: Broken Access Control
• A02: Security Misconfiguration
• A07: Authentication Failures

Review the following best practices for A01: Broken Access Control:

• Build reusable, tiered security levels for your organization's access policy. Create basic access levels to test standard attributes. For complex, multi-factor conditions, deploy custom access levels to evaluate advanced device states and third-party endpoint signals.
• Use Endpoint Verification or Chrome Enterprise Core to enforce device-level constraints such as full-disk encryption, an active screen lock, and an approved operating system version.
• To help protect high-value data repositories with VPC Service Controls, add access levels to your VPC Service Controls ingress rules. If a service account key is leaked, an attacker cannot use only the key to query BigQuery or Cloud Storage from an unauthorized public IP address or untrusted machine.
• To extend zero-trust protection to web applications and VM administrative tunnels, attach access levels directly to your IAP-secured resources.

Review the following best practices for A02: Security Misconfiguration:

• Implement scoped access policies that are bound to specific folders to delegate local policy management to individual project teams and isolate their changes from the rest of the organization.
• To keep orphaned ingress rules from becoming silent backdoors, regularly review and remove decommissioned IP ranges, expired partner subnets, and obsolete device attributes.

Review the following best practices for A07: Authentication Failures:

• Use user access bindings to set strict maximum session durations. Configure the reauthentication policy to require SECURITY_KEY (FIDO2 or WebAuthn). To apply stricter constraints to high-risk environments, configure scopedAccessSettings to override default session durations for sensitive applications.

Agent Gateway and Agent Identity

Agent Gateway and Agent Identity provide dedicated network policy enforcement, identity lifecycle management, and cryptographic authentication for AI agents and agentic workflows.

Applies to the following:

• A01: Broken Access Control
• A07: Authentication Failures

Review the following best practices for A01: Broken Access Control:

• In environments with multi-agent systems, external MCP tools, or autonomous pipelines, use Agent Gateway as a dedicated network and policy enforcement point to help mitigate agentic access control failures.
• Configure granular authorization policies for agent identities to restrict tool access and data retrieval to only the resources required for the agent's specific workflow.

Review the following best practices for A07: Authentication Failures:

• To authenticate autonomous agents and tool integrations without embedding static API keys or passwords, generate and assign an Agent Identity to each agent.
• Configure Agent Identity to issue an X.509 certificate as the agent's credentials. These certificates help prevent token theft so that if an access token is intercepted, that token is unusable from other environments.

Apigee

Apigee provides centralized, gateway-level mechanisms using API proxies to enforce cryptographic standards, validate signed payloads, and encrypt application data in transit and at rest. By acting as a reverse-proxy gateway for API traffic, Apigee runs boundary and structure checks to help validate payloads. Apigee provides built-in API authentication, OAuth, and JSON Web Token (JWT) verification policies to establish strong identity boundaries. Apigee includes several ways to perform logging, monitoring, error handling, and audit logging.

Applies to the following:

• A01: Broken Access Control
• A04: Cryptographic Failures
• A05: Injection
• A06: Insecure Design
• A07: Authentication Failures
• A09: Security Logging & Alerting Failures

Review the following best practices for A01: Broken Access Control:

• Use API proxies to complete the following:

  • Intercept requests where an attacker attempts to access another user's records by manipulating ID variables in the API request path.

  • Block standard clients from executing restricted administrative methods or high-privilege operations.

• For the API management plane, enforce access controls, authentication, and secret storage using encrypted Key Value Maps, Secret Manager, or Kubernetes Secrets (hybrid deployments only).

• Use OAuth policies and JWT tokens to verify signatures. Map sensitive endpoints and actions to high-privilege, granular OAuth scopes (for example, delete:account or write:billing). Use the OAuthV2 policy to validate these scopes at the API entry point, and return an HTTP 403 Forbidden status code to any client that doesn't have the correct permissions.

• Enable Advanced API Security to analyze traffic for anomalous behavioral patterns and start security actions.

Review the following best practices for A04: Cryptographic Failures:

• Encrypt sensitive data in your application and enforce strict cryptographic validation before traffic reaches your backend application. Configure your Apigee environment with customer-managed encryption keys (CMEK) using Cloud KMS.
• Use one-way and two-way TLS to encrypt sensitive information at the protocol level. For server-to-server or high-risk business integrations, configure mutual TLS (mTLS) at the Apigee ingress gateway.
• Use the VerifyJWT and VerifyJWS policies to require that incoming tokens have a valid cryptographic signature before the request is processed. Use standard OAuth techniques and consider implementing HMAC, payload hashing, state or nonce validation, and Proof Key for Code Exchange (PKCE) to cryptographically harden each request.
• Mask sensitive data so that data is encrypted and hidden when using the Apigee Debug tool.

Review the following best practices for A05: Injection:

• Deploy Apigee threat protection policies to sanitize input parameters and block SQL, NoSQL, and command injection attempts at the gateway layer:
  • JSONThreatProtection
  • XMLThreatProtection
  • RegularExpressionProtection
  • SOAPMessageValidation

Review the following best practices for A06: Insecure Design:

• Validate incoming requests with the OASValidation policy for incoming request or response messages against the OpenAPI Specification.
• Mitigate traffic spikes and backend overload by implementing the SpikeArrest policy and the Quota policy.
• Use Fault handling rules to intercept backend errors (like a database crash) and rewrite them into generic HTTP responses.

Review the following best practices for A07: Authentication Failures:

• Implement API key validation for your developer-facing APIs so that Apigee can check whether a client application's API key is present, valid, and authorized to access the requested API resource.
• To help prevent session token theft and replay attacks, implement Demonstrating Proof-of-Possession (DPoP). DPoP binds tokens to the sender's public key to mitigate token replay.
• Defend token generation and login endpoints against automated brute-force attacks by combining SpikeArrest rate limits with reCAPTCHA Enterprise integration.

Review the following best practices for A09: Security Logging & Alerting Failures:

• Asynchronously stream structured API transaction metadata to Logging or third-party SIEMs. Attach your MessageLogging policy to PostClientFlow, which runs after the response is delivered to the client.
• Centralize platform audit logs to track modifications to API proxies, credentials, and deployment environments. To help prevent unauthorized proxy modifications from going unnoticed, integrate Apigee with Cloud Audit Logs.
• Configure Advanced API Security alerts in Monitoring to notify SecOps teams of automated scraping campaigns, credential abuse, and security score regressions.
• Sanitize user-provided variables in your log message templates by wrapping them in the escapeJSON() function.
• If you stream log metadata to an external SIEM, configure the MessageLogging policy to use Syslog over TLS (TCP port 6514) to encrypt your data in transit.

Artifact Registry and Artifact Analysis

Artifact Registry is a single place for your organization to manage container images and language packages. Artifact Analysis provides integrated vulnerability scanning, Software Bill of Materials (SBOM) generation, and metadata storage for artifacts stored in Artifact Registry.

Applies to the following:

• A03: Software Supply Chain Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Reduce attack surface and help prevent the deployment of vulnerable legacy images by configuring cleanup policies to delete unversioned, untagged, or stale release candidate images after a predefined retention period.
• Protect against dependency confusion attacks by configuring virtual repositories with upstream repository priorities that prioritize internal artifact repositories over public registries.
• Enforce immutable image tags or deploy strictly by cryptographic digest (sha256:...) to prevent tag-mutation attacks.

Review the following best practices for A08: Software or Data Integrity Failures:

• Enable automatic vulnerability scanning and SBOM generation in Artifact Analysis to detect critical CVEs before deployment.
• Configure continuous vulnerability analysis to monitor stored images against new vulnerabilities published in the National Vulnerability Database (NVD).
• Integrate Artifact Analysis metadata with Binary Authorization attestations to block the deployment of images that fail security thresholds.

Assured OSS

Assured OSS lets you incorporate the OSS packages that Google validates and uses into your own developer workflows.

Applies to the following:

• A03: Software Supply Chain Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Configure remote repositories to point upstream to Assured OSS.
• Verify that the open-source libraries in your builds contain a valid Google signature and verifiable SLSA build provenance record. Configure quality gates in Cloud Build to verify these attestations before compiling application binaries.
• Configure the package managers (such as pip.conf, settings.xml, or build.gradle) in your Cloud Workstations base images to point only to your internal Assured OSS repositories.
• Use the metadata that's generated by Assured OSS to determine whether a newly disclosed CVE in an open-source package is exploitable in your specific deployment context.

Review the following best practices for A08: Software or Data Integrity Failures:

• Promote package integrity across build pipelines by configuring virtual upstream repositories in Artifact Registry to enforce Google-verified cryptographic signatures.
• Use the Assured OSS Premium tier (part of Security Command Center Premium) to automate repository provisioning, access curated JavaScript (npm) packages, and obtain access to package metadata and vulnerability notifications.

Binary Authorization

Binary Authorization verifies the integrity of containers so that only trusted container images are deployed. You can create policies to allow or deny deployments based on the presence or absence of attestations. Binary Authorization applies policies at a cluster level, so you can configure different policies for different environments.

Applies to the following:

• A03: Software Supply Chain Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Configure deployment pipelines to reference and enforce container images by their unique, immutable SHA-256 cryptographic digest (such as @sha256).
• Deploy Binary Authorization Continuous Validation on your GKE clusters to monitor active Pods against your platform policy, and generate alerts in Logging if running containers are no longer compliant.

Review the following best practices for A08: Software or Data Integrity Failures:

• Enforce automated attestation generation in your Cloud Build or GitHub Actions pipelines. Create progressive attestation requirements so that images pass through sequential validation gates as they move closer to production.
• For high-severity production incidents, enable breakglass emergency deployments. Configure Monitoring alerting policies on breakglass audit log events to notify your SecOps team when an admission bypass occurs.

CA Service and Certificate Manager

Certificate Authority Service (CA Service) simplifies the deployment and management of private certificate authorities (CAs). Certificate Manager provides centralized provisioning, renewal, and management of TLS certificates for Cloud Load Balancing and Cloud CDN.

Applies to A04: Cryptographic Failures.

Review the following best practices:

• Use CA Service to automate the issuance and lifecycle management of private certificates. Deploy root and intermediate CAs backed by Cloud HSM to protect private keys, and use certificate templates to enforce cryptographic policies (such as minimum key lengths and allowed extended key usages).
• Configure ACME clients for automated certificate issuance and renewal.
• Enable Cloud Audit Logs to monitor for high-risk administrative events (such as CA revocation, policy updates, or a sudden spike in certificate requests). Route alerts to Google SecOps to detect potential insider threats or compromised CI/CD pipelines.
• Configure Certificate Manager to use Google-managed certificates paired with DNS authorizations. Certificate Manager validates domain ownership, issues the X.509 certificate, and handles renewals 30 days before expiration.
• Attach certificate maps to target HTTPS proxies to enable dynamic certificate selection and certificate rotation without requiring proxy restarts or load balancer reconfigurations.
• For internal microservices or hybrid load balancing, configure certificate maps to issue private certificates directly from a private CA Service CA pool.
• Configure certificate maps to match incoming Server Name Indication (SNI) requests to specific certificates.

Cloud Asset Inventory

Cloud Asset Inventory lets you monitor your infrastructure on Google Cloud for orphaned or unauthorized IT infrastructure.

Applies to A02: Security Misconfiguration.

Review the following best practices:

• Set up notifications to alert you for unexpected running resources, which might be improperly secured or using outdated software.
• Use IAM policy search and analysis to discover misconfigured access controls, such as public storage buckets with the allUsers permission, over-privileged service account roles, or orphaned identities.
• Export asset snapshots to BigQuery to audit infrastructure configurations over time and maintain a baseline compliance record across multi-project environments.

Cloud Armor

Cloud Armor is an adaptive web application firewall (WAF) that you deploy at your Google Cloud network's edge to help defend against DDoS attacks and block SQLi or XSS injection payloads. Cloud Armor includes preconfigured WAF rules to defend against OWASP Top 10 vulnerabilities, limit the attack surface of your authentication endpoints, and block compromised credentials.

Applies to the following:

• A01: Broken Access Control
• A05: Injection
• A07: Authentication Failures
• A08: Software or Data Integrity Failures
• A10: Mishandling of Exceptional Conditions

Review the following best practices for A01: Broken Access Control:

• Apply preconfigured WAF rules such as evaluatePreconfiguredWaf('lfi-stable') to block local file inclusions and path traversal attacks.
• Enforce geographic access controls (also known as geo-fencing) by configuring a security policy rule that matches incoming traffic based on its originating country code using the origin.region_code attribute.
• Block known malicious IP addresses using a threat intelligence feed.
• Restrict external access to sensitive URLs (such as /admin, /login, or /config) by writing a match rule.
• Enable Cloud Armor path normalization on your load balancer, forcing Cloud Armor to decode and standardize incoming URLs before evaluating your security policies.

Review the following best practices for A05: Injection:

• Detect and block SQL injection (sqli-v422-stable), cross-site scripting (xss-v422-stable), PHP command injection (php-v422-stable), and Java injection (java-v422-stable) at the network edge.
• Tune preconfigured WAF rules to different sensitive levels to address false positives before configuring the rules to actively deny traffic.
• Enable the preconfigured remote code execution (RCE) rule (rce-v422-stable) and the remote file inclusion (RFI) rule (rfi-v422-stable) to catch additional, complex command-injection techniques.
• For injection attacks other than attacks that target SQL or PHP, create custom rules. Custom rules let you block requests when specific keywords or escape patterns in protocols are used in the request path or query.

Review the following best practices for A07: Authentication Failures:

• Restrict access to authentication and administrative endpoints to authorized IP addresses or countries.
• Enable evaluatePreconfiguredWaf to intercept and block requests designed to exploit session-state vulnerabilities and session hijacking.
• Use the securityPolicies.patchRule API to block any incoming requests that contain a compromised parameter in the query string or headers at the network edge.

Review the following best practices for A08: Software or Data Integrity Failures:

• Restrict endpoints that accept high-risk serialized objects from untrusted sources to a set of trusted IP addresses with a deny rule similar to the following:

  request.path.contains('/endpoint') && !inIpRange(origin.ip, '192.0.2.1/32')
  

• Deploy custom rules to inspect request body keywords for language-specific execution patterns and unsafe deserialization signatures.

Review the following best practices for A10: Mishandling of Exceptional Conditions:

• Enable Google Cloud Armor Adaptive Protection on your security policies to baseline normal traffic patterns, configure alerts on L7 anomalies, and generate targeted WAF rules with attack signatures.
• Configure Cloud Armor rate limiting rules on critical endpoints (for example, /login, /checkout, or search APIs). Rate limiting rules throttle requests on a per-client IP or HTTP header basis (for example, limiting clients to 100 requests per minute) and return an HTTP 429 Too Many Requests status code.
• Set the lowest-priority default rule in your Cloud Armor security policy to Deny (status code: 403 or 404).

Cloud Build and Cloud Deploy

Cloud Build and Cloud Deploy provide an integrated, secure continuous integration and continuous delivery (CI/CD) pipeline on Google Cloud. Cloud Build builds artifacts with verifiable SLSA provenance and cryptographic attestations, and Cloud Deploy manages progressive rollouts, target approvals, and automated verification across GKE and Cloud Run.

Applies to the following:

• A03: Software Supply Chain Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Set requestedVerifyOption: VERIFIED in your cloudbuild.yaml file to require verifiable provenance.
• Deploy Cloud Build private pools that are peered with your private VPC network for sensitive enterprise builds.
• Configure build triggers to run under dedicated, user-managed service accounts. Grant these service accounts only the minimum required IAM allow permissions (such as Artifact Registry Writer (roles/artifactregistry.writer) and Logs Writer (roles/logging.logWriter)).
• Require manual approvals on Cloud Build triggers that target staging or production environments.
• Restrict CI build tools (such as Cloud Build, GitHub Actions, or GitLab) to the Cloud Deploy Releaser (roles/clouddeploy.releaser) role so that build pipelines can create releases only.
• To require manual approvals, configure your delivery pipeline manifest (delivery-pipeline.yaml) with requireApproval: true on your staging and production targets.
• Configure execution environments with target-specific service accounts (for example, one service account with permissions limited to the staging namespace, and a separate, audited service account for production).
• Deploy custom hooks to run out-of-band security assertions during the rollout lifecycle. Use pre-deploy hooks to verify whether target clusters satisfy compliance baselines and post-deploy hooks to start automated vulnerability scans against live container endpoints.

Review the following best practices for A08: Software or Data Integrity Failures:

• Integrate Cloud Build with Cloud KMS and Artifact Analysis to create and sign cryptographic attestations when unit tests and static analysis tests complete successfully.
• Use immutable cryptographic SHA-256 digests (for example, golang@sha256:...) in builder steps in cloudbuild.yaml.
• Store build configurations in version-controlled repositories that are protected by branch protection rules (such as mandating two-person reviews on pull requests). Restrict trigger modification permissions to authorized platform administrators using user-managed service accounts.
• Promote identical, pre-rendered deployment manifests and immutable container image digests across target stages without letting CI pipelines alter manifests between staging and production.
• Define automated deployment verification tasks inside your skaffold.yaml manifest. Cloud Deploy runs these verification containers after pods are deployed to run dynamic health checks, integration tests, and API contract assertions.
• Use canary deployment strategies. If a Skaffold verification test fails or Monitoring detects anomaly thresholds during a canary phase, Cloud Deploy halts the rollout and rolls back traffic to the last-known-good release version.
• Configure GKE clusters and Cloud Run to enforce Binary Authorization policies. When Cloud Deploy applies the manifests, the target admission controller cryptographically verifies the container image digests and rejects untrusted artifacts.

Cloud Identity and Titan Security Keys

Cloud Identity provides centralized identity, credential lifecycle, and access management across Google Cloud and Google Workspace. Titan Security Keys are hardware-based, phishing-resistant security devices that use public-key cryptography based on FIDO2 or WebAuthn standards.

Applies to A07: Authentication Failures.

Review the following best practices:

• To help protect against person-in-the-middle (PITM) phishing attacks, configure 2-Step Verification (2SV) and set the allowed method to Security Keys Only (FIDO2, WebAuthn, or Titan Security Keys).
• Configure SAML 2.0 or OIDC-based single sign-on (SSO) with your corporate identity provider alongside automated provisioning.
• Set the Google Cloud session length policy to a low maximum threshold to force users to re-authenticate periodically.
• Register Titan Security Keys as passkeys to enable passwordless authentication, significantly reducing brute-force and credential-compromise risks.
• Mandate 2FA with Titan Security Keys for your privileged identities (such as project owners, billing administrators, and SecOps teams) by enforcing security key policies in Cloud Identity. Enroll high-risk users in the Advanced Protection Program.

Cloud KMS

Cloud KMS manages symmetric and asymmetric cryptographic keys for compatible Google Cloud services and in your own applications. You can generate, use, rotate, and destroy cryptographic keys for symmetric encryption, asymmetric signing, asymmetric encryption, and MAC signing.

Applies to A04: Cryptographic Failures.

Review the following best practices:

• Use Cloud KMS Autokey to automate provisioning and assignment. With Autokey, you don't need to provision key rings, keys, and service accounts ahead of time. Instead, keys and key rings are generated on-demand as part of resource creation.
• Use Cloud KMS keys to encrypt sensitive payloads before the payloads are sent to storage buckets or databases. You can use the Cloud KMS API or client libraries to use your Cloud KMS keys for client-side encryption.
• Verify end-to-end data integrity by validating checksums during transit.
• For strict compliance and regulatory workloads, store and run your cryptographic operations using Cloud HSM. Cloud HSM stores your keys in FIPS 140-3 Level 3 validated hardware security modules.
• Configure automatic key rotation schedules on a set timeframe (for example, every 90 days).

Cloud Load Balancing

Cloud Load Balancing is a fully distributed, software-defined, managed service that distributes user traffic across multiple backend instances and regions.

Applies to the following:

• A04: Cryptographic Failures
• A10: Mishandling of Exceptional Conditions

Review the following best practices for A04: Cryptographic Failures:

• Configure and assign custom SSL policies to your load balancer's frontend to restrict negotiations to TLS 1.3 or secure TLS 1.2 profiles and disable weak cipher suites.

Review the following best practices for A10: Mishandling of Exceptional Conditions:

• Configure your external Application Load Balancer with custom error response pages to intercept backend failure codes and serve standardized HTML or JSON error responses.
• Deploy multi-region backend services with cross-region failover so that traffic can reroute to secondary regions if outages or unhandled system crashes occur.

Google Cloud Observability (Logging, Monitoring, and Error Reporting)

Google Cloud Observability provides full-stack log management with Logging, metrics and alerting with Monitoring, and real-time application crash tracking with Error Reporting.

Applies to the following:

• A09: Security Logging & Alerting Failures
• A10: Mishandling of Exceptional Conditions

Review the following best practices for A09: Security Logging & Alerting Failures:

• Enable Data Access logs for high-value data repositories (such as Cloud Storage, BigQuery, and Spanner) that store sensitive data. Data Access logs let you audit each read, write, and query event for sensitive data.
• Enforce Bucket Lock and retention policies for the custom Logging bucket to help prevent attackers or unauthorized administrators from deleting logs to cover their tracks.
• Use aggregated sinks to collate and route log entries into a single central repository for your SecOps teams. Configure intercepting aggregated sinks to avoid storing high-volume logs like Data Access logs in more than one place.
• Configure log-based alerting policies for critical indicators of compromise, such as Permission Denied IAM errors, unexpected API key creations, or sudden firewall configuration changes.
• Deploy log-based alerting policies in Logs Explorer or Monitoring. Specify exact filters that target high-severity events, such as unauthorized IAM policy modifications or KMS key revocations, so an incident notification is generated when a matching log entry is ingested.
• Build log-based counter metrics in Logging to convert matching log entries into time-series data. Then, build a metric-based alerting policy in Monitoring that starts an incident when the rate exceeds a specific threshold (for example, greater than 50 failed login attempts in five minutes).
• Configure log-based alerting policies that monitor administrative calls to the Cloud Logging API and alert on unexpected log export sink modifications or bucket deletions.
• Configure notification channels with clear documentation templates. Include direct deep-links to the Logs Explorer query, standard operating procedures (SOPs) for the on-call engineer, and explicit remediation steps to help enable swift incident containment.

Review the following best practices for A10: Mishandling of Exceptional Conditions:

• Integrate Error Reporting SDKs directly into your application code or configure Logging to parse structured JSON exception formats.
• Configure Error Reporting notification channels or Monitoring alerting policies to notify your SecOps teams when a new exception class appears.

Cloud NGFW

Cloud NGFW is a managed firewall service that enables stateful inspection and Layer 7 application control for north-south traffic and east-west traffic.

Applies to the following:

• A01: Broken Access Control
• A05: Injection

Review the following best practices for A01: Broken Access Control:

• Enforce network micro-segmentation using global network firewall policies and IAM-governed resource tags to isolate backend application tiers and restrict east-west communication between subnets.
• Use Google-maintained threat intelligence lists in firewall rules to block inbound connections that originate from known malicious actors, C2 servers, and compromised botnets.

Review the following best practices for A05: Injection:

• Configure the intrusion detection and prevention service with a security profile group that denies threats that match SQL injection, OS command injection, and remote code execution exploit signatures.
• Configure Cloud NGFW TLS inspection to decrypt inbound and outbound HTTPS traffic, apply IPS injection signature checks to the plaintext payload, and re-encrypt the session before delivery to the backend.
• Enforce FQDN-based egress firewall rules on backend databases and Compute subnets. Restrict outbound connections to approved, predefined external domains to help prevent vulnerable applications from creating unauthorized reverse shells.
• Enable firewall rules logging on threat prevention profiles and route these logs into Google SecOps to correlate blocked network injection signatures with host-level telemetry, identifying targeted workloads for priority patching.

Cloud Workstations

Cloud Workstations provides managed development environments on Google Cloud with built-in security and customizations.

Applies to the following:

• A03: Software Supply Chain Failures
• A04: Cryptographic Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Create custom base container images stored in Artifact Registry that pre-install security tools, trusted developer extensions, and approved language runtimes.
• Deploy your workstation clusters with private IP ingress and egress and inside a VPC Service Controls perimeter.
• Configure Cloud Workstations to route session traffic through IAP. Require developers to authenticate using corporate credentials with multi-factor authentication (MFA) enabled and enforce least-privilege roles (for example, Cloud Workstations User (roles/workstations.user)).
• Configure workstation configurations with low timeout limits (for example, auto-stopping after two hours of inactivity). When a workstation restarts, Cloud Workstations pulls the latest security-patched container image, so that developers can work in a clean environment.

Review the following best practices for A04: Cryptographic Failures:

• Configure your workstation configurations to encrypt attached persistent disks using CMEK.

CodeMender

CodeMender is a specialized, autonomous AI engineering agent. CodeMender can patch newly discovered vulnerabilities and rewrite existing legacy code to address existing vulnerabilities. You can install and configure CodeMender in Gemini Enterprise Agent Platform.

Applies to the following:

• A03: Software Supply Chain Failures
• A05: Injection
• A06: Insecure Design

Review the following best practices for A03: Software Supply Chain Failures:

• Integrate the CodeMender CLI into local developer workspaces and CI/CD pipelines to scan targeted modules, verify exploitability, and catch security weaknesses before code is committed.
• Import Software Composition Analysis (SCA) and dependency vulnerability reports into CodeMender to run proof-of-concept exploit verifications, filtering out false positives before developer review.

Review the following best practices for A05: Injection:

• Run automated patch generation inside isolated local sandboxes to rewrite vulnerable logic (such as sanitizing inputs). Verify that unit tests pass and PoCs are no longer exploitable before creating pull requests.

Review the following best practices for A06: Insecure Design:

• Refactor legacy or insecure architectural code logic using CodeMender's iterative patch engine, providing explicit coding constraints to enforce secure design patterns across application modules.
• Maintain human-in-the-loop review for CodeMender-generated pull requests and diffs to verify that proposed changes align with your secure coding guidelines.

Confidential Computing

Confidential Computing helps protect data in use by keeping the data encrypted in memory while the data is being processed. Using hardware-based Trusted Execution Environments (TEEs), Confidential Computing helps ensure that your sensitive data and cryptographic keys cannot be accessed by the hypervisor, the host operating system, or infrastructure administrators.

Applies to A04: Cryptographic Failures.

Review the following best practices:

• Use Confidential VMs or Confidential Google Kubernetes Engine Nodes for highly sensitive workloads (like PII, financial records, or proprietary AI model weights).
• When multiple organizations must pool sensitive data for analysis or AI training (without exposing the raw data to each other), use Confidential Space to enforce cryptographic attestation and data isolation.

Firebase (Firebase Authentication, Firebase App Check, and Firebase Security Rules)

Firebase provides developer-focused security controls across identity, client attestation, and database access. Firebase Authentication handles user identity and session management, App Check validates client app integrity, and Firebase Security Rules enforce attribute-based access control and schema validation for Firestore and Cloud Storage.

Applies to the following:

• A01: Broken Access Control
• A05: Injection
• A07: Authentication Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A01: Broken Access Control:

• Scope reads and writes to the authenticated user's ID in Firebase Security Rules. Never use permissive default rules like allow read, write: if true;.
• For administrative roles, use Firebase Admin SDKs to set custom claims on users' ID tokens, and validate those claims in your security rules rather than allowing client-side profile writes.
• Enforce App Check in Firebase Security Rules to block unauthenticated or spoofed client access at the database layer.

Review the following best practices for A05: Injection:

• Enforce structural payload validation in Security Rules by checking incoming document field types, string lengths, and object sizes to reject malformed or malicious write payloads before database ingestion.

Review the following best practices for A07: Authentication Failures:

• Upgrade to Firebase Authentication with Identity Platform to enable enterprise protections such as MFA with TOTP and blocking functions.
• Verify Firebase ID tokens on your backend using the Firebase Admin SDK before granting access to sensitive application data.
• Use the debug provider to generate temporary, scoped debug tokens for your developers and CI/CD pipelines in staging environments.

Review the following best practices for A08: Software or Data Integrity Failures:

• Enforce hardware-backed attestation providers to verify client integrity. Configure App Check to use Android Play Integrity and Apple App Attest.
• Deploy App Check token verification middleware on Cloud Run and Kubernetes Engine API backends to reject requests that originate from scraped API keys, automated scripts, or emulated environments.

Fraud Defense

Fraud Defense is a unified platform for fraud and abuse defense, including bot, account, and transaction protection for the web. reCAPTCHA, an offering that's part of Fraud Defense, filters for bots and other forms of automation and bulk traffic by scoring the risk level of access attempts.

Applies to A07: Authentication Failures.

Review the following best practices:

• Integrate reCAPTCHA with your existing WAF, such as Google Cloud Armor, to issue automated challenges or block high-risk bot traffic before requests reach authentication endpoints.
• Defend accounts on login, password reset, and session renewal endpoints. Obtain account takeover (ATO) risk scores based on user sign-in velocities and device fingerprints.
• Defend against SMS toll fraud on registration and 2FA forms by evaluating phone number risk profiles before sending outbound SMS messages.
• To reduce false positives and train site-specific risk assessment models, regularly annotate and send transaction feedback.
• Check passwords during user sign-in and account creation flows to detect whether submitted credentials appear in third-party data breach databases across the web.

Google SecOps

Google Security Operations is a security operations platform that combines security telemetry analysis (SIEM), security orchestration, automation, and response (SOAR), and frontline Mandiant threat intelligence into a single platform.

Applies to the following:

• A02: Security Misconfiguration
• A09: Security Logging & Alerting Failures

Review the following best practices for A02: Security Misconfiguration:

• Ingest findings from Security Command Center into Google SecOps to combine static misconfiguration findings (for example, PUBLIC_BUCKET_ACL or CMEK_DISABLED) with live network and firewall telemetry.
• Build automated SOAR response playbooks to run containment actions.
• Use Gemini to accelerate misconfiguration triage and to receive synthesized summaries of misconfigured assets, attached IAM roles, and step-by-step remediation guidance.

Review the following best practices for A09: Security Logging & Alerting Failures:

• Normalize log telemetry to unified data model (UDM) to enable fast, standardized multi-cloud searching and correlation without the overhead of raw log parsing.
• Write YARA-L 2.0 detection rules to monitor for high-risk configuration changes such as disabling of OS Login, deletion of Logging sinks, or modifications to VPC Service Controls perimeters.
• Use Applied Threat Intelligence curated detections to evaluate your event data against Mandiant Threat Intelligence data.
• Use Gemini in Google SecOps to generate YARA-L detection rules from natural language descriptions and summarize complex, multi-stage incident timelines into executive incident summaries.

Identity-Aware Proxy

IAP creates a central authorization layer for applications that are accessed by HTTPS and administrative TCP connections. IAP verifies user identity and context before granting access to Cloud Run, App Engine, Compute Engine, GKE, and on-premises resources.

Applies to the following:

• A01: Broken Access Control
• A07: Authentication Failures

Review the following best practices for A01: Broken Access Control:

• Enforce granular access controls to web applications, VMs, Google Cloud APIs, and Google Workspace applications based on a user's identity, group membership, and the context of the request.
• Integrate with Agent Gateway to enforce access controls for your agent identities.
• Use IAP TCP Forwarding to establish encrypted HTTPS tunnels to your backend instances and remove internet-facing SSH (port 22) and RDP (port 3389) endpoints.

Review the following best practices for A07: Authentication Failures:

• Authenticate users accessing administrative interfaces and web applications through IAP using identities provisioned in IAM or Cloud Identity.
• Verify the signed JWT assertion inside the x-goog-iap-jwt-assertion header at the application layer. Validate the signature against Google's public keys and verify that the audience (aud) claim matches your backend service ID.
• To help prevent attackers from bypassing IAP authentication, configure Cloud Run ingress settings to allow internal and Cloud Load Balancing traffic only, blocking direct public access to your backend container URLs. For VMs or GKE nodes, configure VPC firewall rules to only accept ingress traffic originating from the load balancer's IP ranges.

Identity and Access Management

Identity and Access Management (IAM) lets you manage fine-grained access to services and resources in Google Cloud. IAM includes features such as the following:

• Privileged Access Manager, which manages on-demand, temporary privilege elevation for sensitive Google Cloud resources
• Workload Identity Federation, lets workloads access to Google Cloud resources by using a federated identity.
• Workforce Identity Federation, which lets users access Google Cloud resources using a federated identity.

Applies to the following:

• A01: Broken Access Control
• A07: Authentication Failures

Review the following best practices for A01: Broken Access Control:

• Use predefined roles or custom roles (not basic roles) to restrict permissions to specific resource or user needs.
• Restrict permissions to grant the Service Account User (roles/iam.serviceAccountUser) and Service Account Token Creator (roles/iam.serviceAccountTokenCreator) roles.
• Use IAM Recommender to analyze your organization's active usage logs and remove over-privileged accounts.
• Write IAM Conditions in your role bindings to add context-aware authorization and restrict access by date, time of day, or originating IP address.
• Deploy Principal Access Boundary (PAB) policies to define the organizations, folders, or projects that a principal set can access. If an attacker steals an active session or a service account is accidentally granted broad IAM roles, PAB blocks access if the specified resource is outside the identity's designated boundary.
• Attach IAM deny policies at the organization or folder level to block high-risk permissions (such as iam.serviceAccountKeys.create or resourcemanager.projects.delete).
• When configuring IAM deny rules, declare a dedicated breakglass security group in the exceptionPrincipals list. Use resource tags in your denial conditions (such as resource.matchTag('env', 'prod')) so that destructive actions are blocked on production resources while allowing developers operational flexibility in development sandbox projects.

Review the following best practices for A07: Authentication Failures that apply to Privileged Access Manager:

• Convert critical administrative roles (such as Owner (roles/owner), Organization Administrator (roles/resourcemanager.organizationAdmin), and Security Admin (roles/iam.securityAdmin)) from static IAM bindings into Privileged Access Manager entitlements. Configure these entitlements to require an operational justification before elevation is granted.
• For production environments, configure Privileged Access Manager entitlement policies with mandatory approvers such as a central SecOps group or team leads.
• Configure the maximum duration on Privileged Access Manager entitlements to the shortest realistic operational window (for example, two hours for standard maintenance, 30 minutes for breakglass actions). After the timer expires, Google Cloud removes the temporary IAM role binding.
• Manage Terraform infrastructure using non-authoritative IAM resources (for example, google_project_iam_member or google_folder_iam_member rather than google_project_iam_policy or google_project_iam_binding). This practice avoids overwriting your Terraform pipelines or desynchronizing temporary Privileged Access Manager role bindings while an administrator is actively remediating an incident.
• Enable Cloud Audit Logs on Privileged Access Manager to record entitlement actions and expiration events. Ingest these logs into Google SecOps to alert on suspicious elevation patterns, such as multiple off-hour elevation requests or repeated requests from unexpected geolocations.

Review the following best practices for A07: Authentication Failures that apply to Workforce Identity Federation:

• Deploy workforce identity pools using SAML 2.0 or OpenID Connect (OIDC) to federate external identity providers with Google Cloud.
• Configure the session duration on your workforce identity pool to limit the lifespan of federated user tokens.
• Enforce attribute conditions on workforce identity providers to mitigate multi-tenant IdP token forgery or cross-organization impersonation.
• Map external group memberships to assign IAM roles to federated group principal sets (for example, principalSet://iam.googleapis.com/.../attribute.group/security-engineers).

Review the following best practices for A07: Authentication Failures that apply to Workload Identity Federation:

• Create workload identity pools and providers for external workloads. Use short-lived OIDC tokens, exchanging them dynamically using Security Token Service for temporary access tokens that expire in minutes.
• Enforce attribute conditions on workload identity providers so that external multi-tenant platforms cannot authenticate to your pool from unauthorized repositories or accounts.
• Bind IAM roles directly to specific principal sets that are filtered by custom mapped attributes.
• When configuring workload access, grant IAM roles directly to the federated principalSet:// identifier on the target resource.
• To enforce Workload Identity Federation, set the constraints/iam.disableServiceAccountKeyCreation constraint on your organization.

Identity Platform

Identity Platform is the customer identity and access management (CIAM) platform for Google Cloud customers. Identity Platform provides authentication with multi-protocol support by using SDKs and APIs. Identity Platform supports MFA, integration with third-party authentication services, and auditable activity tracking.

Applies to A07: Authentication Failures.

Review the following best practices:

• Enable MFA across your user base. Prioritize phishing-resistant methods, such as TOTP (authenticator apps) or WebAuthn (biometrics and security keys).
• Deploy blocking Cloud Run functions using beforeCreate and beforeSignIn triggers to run custom security code before a user is saved or issued a token. This practice lets you block disposable email domains, restrict IP addresses, or mandate email verification.
• Integrate with reCAPTCHA Enterprise to assess sign-in, sign-up, and password reset requests for bot traffic, credential stuffing attempts, and automated abuse.
• Configure password policies to enforce minimum character lengths, require specific character complexities (such as numbers and symbols), and block predictable sequences.
• If using phone-based MFA, configure SMS regions and enable reCAPTCHA SMS defense to limit verification messages to the country codes where your target users reside.

Mandiant AI Security Consulting Solutions

Mandiant AI Security Consulting Solutions can evaluate your proposed software architectures, business processes, and cloud deployments early in the development lifecycle. By applying frontline threat intelligence to your system design, Mandiant consultants help expose hidden logical flaws, missing trust boundaries, and architectural risks before a single line of code is written.

Applies to A06: Insecure Design.

Review the following best practices:

• Engage Mandiant consultants before development begins to complete architecture workshops and implement security controls from the beginning.
• Collaborate with threat modeling experts to map out your application's data flow diagrams. Define where sensitive data crosses trust boundaries to identify where strict authentication, encryption, and validation controls must be enforced.
• Use structured threat modeling frameworks (such as STRIDE) during your architecture workshops. Mandiant consultants can help prioritize discovered design flaws based on real-world exploitability and business impact.
• Establish secure AI governance baselines for agentic workflows and LLM deployments, defining clear trust boundaries between AI agents, MCP servers, and enterprise backend data sources.

Model Armor

Model Armor is designed to screen LLM prompts, responses, and MCP tool calls. Model Armor inspects generative AI payloads to help detect and block prompt injection, jailbreak attempts, malicious URLs, toxic content, and sensitive data leakage.

Applies to the following:

• A05: Injection
• A10: Mishandling of Exceptional Conditions

Review the following best practices for A05: Injection:

• Deploy Model Armor policies inline at the API gateway layer using Apigee integration or Agent Gateway to screen incoming prompts and outgoing model responses before traffic reaches inference engines or tool runtimes.
• Configure floor settings at the organization or folder level to create mandatory baseline security guardrails that individual project teams cannot bypass.
• Build customized Model Armor templates with tuned confidence thresholds (for example, LOW_AND_ABOVE or MEDIUM_AND_ABOVE) for prompt injection and jailbreak detection on public endpoints.
• Enable malicious URL detection and PDF and file scanning in your Model Armor template to check embedded URLs against Google's threat intelligence databases. Drop prompts that contain malware or phishing vectors before execution.
• Enable Sensitive Data Protection in your Model Armor template to inspect model egress traffic. Configure automated de-identification or masking to replace detected sensitive data with placeholders before the response leaves the boundary.

Review the following best practices for A10: Mishandling of Exceptional Conditions:

• Configure your application code to intercept MATCH_FOUND verdicts and return a generic response, so that the system doesn't default to executing the prompt or exposing raw exception traces.
• Implement a fail-closed (fail-secure) architecture in your application code to reject incoming generative AI prompts if Model Armor API calls encounter network timeouts, rate limits, or unhandled HTTP 5xx errors.

Organization Policy

The Organization Policy gives you centralized and programmatic control over your organization's Google Cloud resources.

Applies to the following:

• A01: Broken Access Control
• A02: Security Misconfiguration
• A04: Cryptographic Failures

Review the following best practices for A01: Broken Access Control:

• Enforce constraints/storage.publicAccessPrevention to override bucket-level IAM policies or ACLs that attempt to grant access to allUsers or allAuthenticatedUsers.
• Apply constraints/iam.allowedPolicyMemberDomains to restrict IAM policy bindings strictly to your verified Google Workspace or Cloud Identity customer IDs.
• Enforce constraints/iam.disableServiceAccountKeyCreation across production folders to help prevent users from downloading service account keys, forcing engineering teams to adopt short-lived alternatives like Workload Identity Federation.
• Enforce constraints/iam.automaticIamGrantsForDefaultServiceAccounts so that Google Cloud doesn't automatically grant the permissive Editor (roles/editor) role to default service accounts.
• For requirements not covered by predefined constraints, deploy custom organization policies to enforce fine-grained resource configurations. Consider restricting VM creation strictly to approved machine families, limiting persistent disk provisioning sizes, or mandating specific network firewall tag configurations.

Review the following best practices for A02: Security Misconfiguration:

• Use constraints/compute.requireShieldedVm to require Shielded VM, helping to protect VMs against kernel rootkits, bootkits, and firmware tampering.
• Enforce constraints/compute.requireOsLogin to require Linux instances to use OS Login, which links SSH access directly to the user's IAM identities and 2SV.
• Enforce constraints/compute.disableSerialPortAccess to block interactive serial console connections across projects.
• Enforce constraints/compute.skipDefaultNetworkCreation so that the default VPC network isn't created, forcing teams to build custom VPCs with dedicated subnets and strict firewall policies.
• Enforce constraints/sql.restrictPublicIp so that Cloud SQL instances only receive private RFC 1918 internal IP addresses, and use constraints/compute.vmExternalIpAccess to restrict public IPv4 addresses on VMs.
• Apply constraints/gcp.resourceLocations to restrict resource creation to authorized Google Cloud regions.

Review the following best practices for A04: Cryptographic Failures:

• To mandate CMEK, apply constraints/gcp.restrictNonCmekServices at the organization or top-level folder, set the policy type to Deny and list supported Google Cloud services. Before enforcing the constraint, verify that the service agent for each target service exists and is granted the Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) role on the relevant key rings.
• Enforce constraints/gcp.restrictCmekCryptoKeyProjects to restrict key selection to dedicated Cloud KMS projects.

Secret Manager

Secret Manager lets applications and pipelines access the values of named secrets based on permissions granted with IAM. When enabled, interactions with Secret Manager create an audit trail that you can use to assist with forensics and compliance needs.

Applies to the following:

• A04: Cryptographic Failures
• A07: Authentication Failures

Review the following best practices for A04: Cryptographic Failures:

• Encrypt high-value secrets using CMEK to control, rotate, or revoke the primary encryption keys that wrap your secret payloads.
• Use data integrity checksums to maintain and verify the integrity of your secret's data when adding and accessing secret versions.
• Replicate secrets across multiple regions for high availability and disaster recovery across geographic deployment zones.

Review the following best practices for A07: Authentication Failures:

• Remove sensitive values such as API keys from source code, .env files, and container build configurations and store the credentials in Secret Manager. Fetch decrypted values at runtime using Google Cloud client libraries, GKE Secret Store CSI drivers, or Cloud Run secret bindings.
• Apply IAM policy bindings directly to specific individual secrets, granting microservices the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role only on the specific secrets that they require.
• Configure automated rotation schedules on Secret Manager. When a rotation interval starts, Secret Manager publishes a SECRET_ROTATE notification to a designated Pub/Sub topic. Configure a Cloud Run functions or Cloud Run service to read the notification, generate a new secret value, add the new version to Secret Manager, and destroy the retired version.
• Enable Cloud Audit Logs on Secret Manager to track secret version creation, destruction, and payload access events. Route these logs to Google SecOps to alert on suspicious access events, such as a compromised service account accessing secrets outside standard operational hours or attempting to read unapproved secret resources.

Security Command Center Premium

Security Command Center Premium lets you find and address security misconfigurations and active runtime threats, including identification and authentication failures, in your Google Cloud environment and web applications. The Web Security Scanner service can monitor for application vulnerabilities, including XML external entity (XXE) vulnerabilities, with scans designed to cover the OWASP Top 10 controls.

Applies to the following:

• A02: Security Misconfiguration
• A05: Injection
• A07: Authentication Failures
• A08: Software or Data Integrity Failures

Review the following best practices for A02: Security Misconfiguration:

• Apply built-in frameworks (such as the CIS Benchmarks or NIST) using Compliance Manager to assess your cloud configurations against regulatory security frameworks and industry benchmarks.
• Enable Cloud Infrastructure Entitlement Management to manage the identities that have access to resources in your cloud deployments and mitigate potential vulnerabilities that result from misconfigurations.
• Review and remediate Web Security Scanner findings to fix misconfigured HTTP response security headers, invalid CORS origin headers, and mixed-content serving.

Review the following best practices for A05: Injection:

• Enable services such as Virtual Machine Threat Detection and Container Threat Detection. These services scan hypervisor memory and kernel events for malicious scripts, reverse shells, and malware installations (using the Added Binary Executed and Added Library Loaded detectors).
• Configure Web Security Scanner to monitor running applications for cross-site scripting (XSS) and SQL injection (SQLi) flaws.
• Integrate Security Command Center findings into Google SecOps or third-party SIEMs for automated triage and incident response.

Review the following best practices for A07: Authentication Failures:

• Monitor your Logging streams to catch credential-based attacks using the Brute Force: SSH and Persistence: IAM Anomalous Grant detectors.
• Use the Use Multifactor or Passwordless Authentication, Set Application Restriction on API Keys, and Require Rotation of API Key cloud controls to detect when MFA isn't being used and monitor API key usage.
• Remediate Session ID Leak findings by configuring web backends to store session tokens in HTTP cookies with HttpOnly and Secure flags.

Review the following best practices for A08: Software or Data Integrity Failures:

• Configure Web Security Scanner to scan web endpoints for signature-based execution bugs and generate a high-severity STRUTS_INSECURE_DESERIALIZATION finding if an application is running a vulnerable Apache Struts version.
• Remediate the STRUTS_INSECURE_DESERIALIZATION finding by upgrading the vulnerable framework library version or deploying Assured OSS to pull a Google-verified replacement.

Sensitive Data Protection

Sensitive Data Protection lets you scan for any potentially sensitive data stored in buckets, databases, generative AI prompts, or streaming application payloads to help prevent unintended information leakage. If disallowed data is identified, Sensitive Data Protection can flag or redact it.

Applies to the following:

• A04: Cryptographic Failures
• A09: Security Logging & Alerting Failures

Review the following best practices for A04: Cryptographic Failures:

• Enable sensitive data discovery to continuously scan your storage and database assets, generate data profiles, and report metrics for audit reports.
• Use format-preserving encryption, cryptographic hashing, or key-based tokenization to de-identify sensitive data.
• Deploy reusable, centrally managed de-identification templates to enforce consistent cryptographic masking and inspection policies across development teams.
• Analyze prompt payloads to help prevent sensitive corporate data or PII from leaking into generative AI training pipelines.

Review the following best practices for A09: Security Logging & Alerting Failures:

• Configure your Logging sink to send application logs to a Pub/Sub topic. Attach a Cloud Run subscriber that uses the Sensitive Data Protection API to scan and de-identify the log payload before writing clean logs to your final Logging bucket.
• Use exclusion filters in your Logging sinks to route only high-risk, unstructured logs (such as raw application errors, user registration payloads, and transaction logs) through the sanitization pipeline.

VirusTotal

The VirusTotal API is a threat intelligence and file-scanning platform that analyzes suspicious files, URLs, domains, and IP addresses to detect malware, trojans, and malicious payloads. Integrating the VirusTotal API into file ingestion pipelines lets you scan untrusted uploads before files are processed by application systems.

Applies to the following:

• A08: Software or Data Integrity Failures
• A05: Injection

Review the following best practices for A08: Software or Data Integrity Failures:

• Deploy custom YARA-X signature-matching rules to scan incoming file structures for known malicious binary and textual patterns, enabling detection of mutated malware variants.

Review the following best practices for A05: Injection:

• Use the VirusTotal Private Scanning module to scan sensitive uploads in isolation and not share uploaded files with third parties.
• Implement API rate-limiting and exception handling in your ingestion code to catch HTTP 429 Too Many Requests status codes.

VPC Service Controls

VPC Service Controls lets you create perimeters around your Google Cloud resources to help prevent data exfiltration and mitigate Server-Side Request Forgery (SSRF) attacks. VPC Service Controls denies API calls that cross perimeter boundaries unless explicitly permitted by ingress and egress rules.

Applies to the following:

• A01: Broken Access Control
• A02: Security Misconfiguration

Review the following best practices for A01: Broken Access Control:

• Include critical services (such as Cloud Storage, BigQuery, Spanner, and Agent Platform) in a service perimeter to restrict API access to authorized VPC networks and trusted identities.
• Configure egress perimeter rules on serverless resources to block unauthorized data exfiltration that's caused by outbound API calls to external, non-perimeter destinations.
• Restrict cross-perimeter and cross-organization API access using explicit ingress and egress rules that specify approved project sources, target APIs, and caller identities.

Review the following best practices for A02: Security Misconfiguration:

• Group projects into dedicated perimeters that are organized by environment security tier (for example, a production perimeter). Use VPC-accessible services to restrict which internal Google APIs can be invoked inside the perimeter.
• Route outbound API requests from serverless workloads through the VPC network. Configure Cloud Run services and Cloud Run functions to use direct VPC egress or a Serverless VPC Access Connector with ingress set strictly to internal-only.
• Bind Access Context Manager access levels to your perimeter ingress rules that evaluate a combination of corporate IP subnets, authenticated identity claims, and Endpoint Verification device health signals.
• Maintain a pre-approved breakglass administrative process for emergency incident response, and set up Monitoring alerts on any unexpected perimeter violation events.

Wiz services

The following sections describe OWASP Top 10 best practices for Wiz services that integrate with Google Cloud.

Wiz Code

Wiz Code extends cloud security into developer workflows and CI/CD pipelines. Wiz Code correlates code-to-cloud telemetry, scans Infrastructure as Code (IaC), analyzes dependencies (SCA), detects exposed credentials, and performs static application security testing (SAST).

Applies to the following:

• A03: Software Supply Chain Failures
• A05: Injection
• A07: Authentication Failures

Review the following best practices for A03: Software Supply Chain Failures:

• Integrate the Wiz CLI into CI/CD pipelines to block pull requests from merging if they introduce critical CVEs, exposed secrets, or severe IaC misconfigurations into protected branches.
• Generate and export a SBOM for every build to maintain continuous supply chain visibility in Wiz Cloud.
• Deploy Wiz Code IDE extensions to provide real-time developer feedback, catching vulnerable packages, hardcoded API keys, and syntax errors before code commit.
• Integrate Wiz Code with CodeMender in CI/CD pipelines to generate, test, and submit pull requests when vulnerable third-party dependencies are detected.

Review the following best practices for A05: Injection:

• Block pull requests from merging if the SAST scanner detects untrusted user input flowing into database queries or OS commands without proper sanitization.
• Integrate the Wiz Code plugin into developer IDEs to provide real-time alerts if developers type unsafe, concatenating SQL query or command execution patterns.
• When Wiz Code flags an injection flaw, route data-flow traces to CodeMender to draft a verified remediation patch.

Review the following best practices for A07: Authentication Failures:

• Implement automated secret scanning on developer IDEs, local pre-commit hooks, and in CI/CD pipelines to catch exposed credentials.
• To mitigate credential theft, replace static, long-lived credentials with dynamic, short-lived tokens and identity-bound access (such as Workload Identity Federation or OIDC-based authentication).
• Implement an automated incident response playbook to remove detected secrets from code, environment variables, and build logs.

Wiz Cloud

Wiz Cloud analyzes multi-cloud environments to identify security misconfigurations, sensitive data exposures, and identity risks. Using the Wiz Security Graph, Wiz Cloud correlates risk factors across infrastructure layers to highlight critical attack paths.

Applies to the following:

• A01: Broken Access Control
• A02: Security Misconfiguration
• A04: Cryptographic Failures
• A06: Insecure Design

Review the following best practices for A01: Broken Access Control:

• Trace and flag complex, multi-hop privilege escalation paths across IAM roles and policies to identify where attackers could move laterally or elevate privileges.
• Map active access permissions across user accounts, service accounts, and AI agents to critical data stores, and revoke over-privileged entitlements.
• Integrate identity entitlement findings with orchestration platforms to replace permanent administrative role bindings with just-in-time (JIT) access.
• Monitor and visualize data movement to detect when production PII is copied or synced down into insecure staging or development environments.

Review the following best practices for A02: Security Misconfiguration:

• Assess and prioritize cloud configuration risk by correlating misconfigurations with multiple attack factors using the Wiz Security Graph.
• Apply built-in compliance frameworks (such as OWASP Top 10, CIS Benchmarks, and NIST) to measure cloud configurations against industry standards.
• Integrate the Wiz CLI scanner into CI/CD pipelines to review builds or remediate IaC misconfigurations before deployment.

Review the following best practices for A04: Cryptographic Failures:

• Prioritize the remediation of databases and storage buckets that contain plaintext credentials, unhashed keys, or sensitive data stored without encryption.
• Run Wiz Cloud data discovery across AI training directories, vector databases, and RAG pipelines to verify that proprietary data and PII are redacted before LLM ingestion.
• Scan environments to identify unmanaged data assets and delete redundant data to minimize your attack surface.

Review the following best practices for A06: Insecure Design:

• Direct Wiz Red Agent to analyze logical architectural interfaces and simulate attack paths to find insecure design flaws before production deployment.
• Pass validated attack chain context from Wiz Red Agent to CodeMender to identify root causes and generate tested architectural pull requests.

Wiz Defend

Wiz Defend provides cloud detection and response (CDR), workload runtime protection, and Kubernetes admission security. Wiz Defend monitors control plane activity, detects runtime anomalies, enforces container admission policies, and triggers automated containment.

Applies to the following:

• A08: Software or Data Integrity Failures
• A09: Security Logging & Alerting Failures

Review the following best practices for A08: Software or Data Integrity Failures:

• Configure Wiz Defend admission rules to inspect and reject Kubernetes deployment manifests that attempt to run containers with root privileges, request host network namespaces, or enable privileged: true.
• Configure critical security admission webhooks with failurePolicy: Fail (fail-closed) in production to block untrusted containers if the webhook is unreachable.

Review the following best practices for A09: Security Logging & Alerting Failures:

• Export Google Cloud audit logs using a log sink to a Pub/Sub topic so that Wiz Defend can ingest and analyze control-plane activities and workload events.
• Deploy the Wiz Runtime Sensor on GKE clusters and high-value Compute Engine VMs to detect runtime threats, in-memory exploits, and active compromises.
• Automate containment playbooks to immediately disable compromised IAM service accounts or isolate compromised workloads.
• Use Wiz Blue Agent to investigate runtime detections, correlating live process telemetry and identity context to determine root causes and affected assets.

Maintain compliance with OWASP Top 10:2025

Wiz includes an OWASP Top 10 2025 compliance framework that lets you assess and monitor your posture. The OWASP Top 10 2025 compliance framework maps built-in Wiz policies to the relevant OWASP risk categories and creates findings if a control is non-compliant. You can track your compliance score over time. If required, you can customize the OWASP Top 10 2025 compliance framework to meet your business requirements.

What's next

Review the security best practices catalog for additional best practices.