What it scans
Each workload type is a separate toggle. Turn off the ones you don’t want scanned. See 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 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 labelplerion-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.