> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plerion.com/llms.txt
> Use this file to discover all available pages before exploring further.

# GCP workload scanning overview

> What GCP workload scanning covers, how each workload type is scanned, and what stays inside your Google Cloud organization

With **[GCP workload scanning](/guides/integrations/gcp/workload-scanning/getting-started)**, Plerion scans the software inside your Compute Engine instances, the container images behind your Cloud Run services and Cloud Functions, and the deployed source of your 1st gen functions. Plerion reports vulnerabilities, a software bill of materials (SBOM), and secrets. No agent is installed, and no disk contents, images, or source leave your Google Cloud organization.

Workload scanning is a capability of the [GCP organization integration](/guides/integrations/gcp/overview). You turn it on for an organization you've already connected, and one re-run of the onboarding script or Terraform template creates everything it needs. In Plerion, the capability toggle is called **Workload scanning**. The badge on an integration reads **Workload** in the integrations list and **CWPP** (Cloud Workload Protection Platform) on the detail page, and the platform docs call the same feature [workload security (CWPP)](/guides/platform/cwpp/overview).

***

## What it scans

| Workload type | How Plerion scans it | Findings attach to |
| - | - | - |
| **Compute Engine instances** | Snapshots the instance's boot disk, copies the snapshot to a scan disk in the scanning project, and scans it from a short-lived scanner VM | The instance |
| **Compute Engine custom images** | Creates a scan disk directly from the image (no snapshot) and scans it the same way | The image |
| **Compute Engine managed instance groups** | Samples one member per distinct boot image in the group, scans each sample like an instance, and merges the results | The group, not its members |
| **Cloud Run services** | Pulls the exact container image the serving revision runs and scans it in a Cloud Run job | The service |
| **Cloud Functions (2nd gen)** | Pulls the image Google built for the function and scans it in a Cloud Run job | The function |
| **Cloud Functions (1st gen)** | Downloads the function's deployed source archive and scans it in a Cloud Run job | The function |

Each workload type is a separate toggle. Turn off the ones you don't want scanned. See [Coverage](/guides/integrations/gcp/workload-scanning/coverage) for what is excluded and why.

***

## Scan types

* **Vulnerabilities**: known Common Vulnerabilities and Exposures (CVEs) in operating system packages and application dependencies. On by default.
* **Software bill of materials (SBOM)**: the full package inventory of each workload. On by default.
* **Sensitive data**: secrets such as API keys, tokens, and private keys left on disk, in an image, or in source. Off by default. Turn it on per integration.

***

## What runs where

All scanning compute runs inside a **scanning project** that onboarding creates in your own organization, never in a Plerion-owned project. The scanning project holds the scanner VMs, the scan disks, the Cloud Run scan jobs, and the network they use. These resources are visible in your own console during a scan and billed to your account.

Only scan **results** are sent to Plerion. Snapshots, scan disks, pulled images, and downloaded source are deleted when the scan finishes. See [How scanning works](/guides/integrations/gcp/workload-scanning/how-scanning-works) for each flow step by step.

***

## Terms used in these pages

* **Scanning project**: the project onboarding creates for scanning compute. Its ID starts with `plerion-scan-` and it carries the label `plerion-scan=true`.
* **Tenant service account**: the service account that onboarding created for Plerion in your Plerion service project. Plerion reaches it through Workload Identity Federation, with no key. It drives every GCP API call workload scanning makes.
* **Scanner VM**: the short-lived Compute Engine instance that scans a disk. It runs under its own service account with no IAM roles.
* **Access command**: the onboarding script command or Terraform apply that grants Plerion access. Plerion generates it for your current settings, and you re-run it whenever you change what Plerion is allowed to scan.

***

## Next steps

* [Prerequisites](/guides/integrations/gcp/workload-scanning/prerequisites)
* [Getting started](/guides/integrations/gcp/workload-scanning/getting-started)
* [How scanning works](/guides/integrations/gcp/workload-scanning/how-scanning-works)
* [Access and permissions](/guides/integrations/gcp/workload-scanning/access-and-permissions)
* [Coverage](/guides/integrations/gcp/workload-scanning/coverage)
* [Managing workload scanning](/guides/integrations/gcp/workload-scanning/managing-workload-scanning)
* [FAQ](/guides/integrations/gcp/workload-scanning/faq)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.