⭐ Add GCP Security Command Center and VPC Service Controls resources

[tas50]

Summary

• Add Security Command Center (SCC) resources: Sources, Findings, NotificationConfigs, MuteConfigs, BigQueryExports — available at org level (gcp.organization.scc*) and project level (gcp.project.sccFindings)
• Add VPC Service Controls (Access Context Manager) resources: AccessPolicies, AccessLevels, ServicePerimeters — available at org level (gcp.organization.accessPolicies) with lazy-loaded sub-resources
• Both are critical security services that were previously missing from the GCP provider

Details

Security Command Center

Resource	Org-level	Project-level
gcp.scc.source	gcp.organization.sccSources	—
gcp.scc.finding	gcp.organization.sccFindings	gcp.project.sccFindings
gcp.scc.notificationConfig	gcp.organization.sccNotificationConfigs	—
gcp.scc.muteConfig	gcp.organization.sccMuteConfigs	—
gcp.scc.bigQueryExport	gcp.organization.sccBigQueryExports	—

Findings use the - wildcard (sources/-) to list across all sources. Project-level findings include a isServiceEnabled check.

VPC Service Controls

Resource	Access
gcp.accesscontextmanager.accessPolicy	gcp.organization.accessPolicies
gcp.accesscontextmanager.accessLevel	accessPolicy.accessLevels (lazy)
gcp.accesscontextmanager.servicePerimeter	accessPolicy.servicePerimeters (lazy)

Example queries

gcp.organization.sccFindings { category severity state resourceName }
gcp.organization.accessPolicies { title servicePerimeters { title perimeterType status } }
gcp.project.sccFindings { category severity findingClass }

Test plan

• Build provider: make providers/build/gcp && make providers/install/gcp
• Test SCC at org level: mql shell gcp --organization-id <ORG_ID> → query gcp.organization.sccSources, gcp.organization.sccFindings
• Test SCC at project level: mql shell gcp --project-id <PROJECT_ID> → query gcp.project.sccFindings
• Test VPC SC: mql shell gcp --organization-id <ORG_ID> → query gcp.organization.accessPolicies { accessLevels servicePerimeters }
• Verify graceful handling when SCC API is not enabled (project-level returns null)

🤖 Generated with Claude Code

[mondoo-code-review]

New GCP SCC and VPC Service Controls resources are missing required IAM permissions in gcp.permissions.json, and the unused service_accesscontextmanager constant suggests a missing service-enabled guard.

Superseded by new review

[mondoo-code-review]

GCP permissions file still missing SCC and Access Context Manager entries needed for least-privilege documentation.

[mondoo-code-review]

Adds GCP Security Command Center and VPC Service Controls resources with clean implementation following existing patterns.

[github-actions]

Test Results

6 119 tests  ±0   6 115 ✅ ±0   2m 4s ⏱️ -12s
  439 suites ±0       4 💤 ±0 
   35 files   ±0       0 ❌ ±0 

Results for commit 879c097. ± Comparison against base commit 21f6518.

♻️ This comment has been updated with latest results.

[mondoo-code-review]

New GCP SCC and VPC Service Controls resources are functional but have a minor correctness issue in organization ID handling.

[mondoo-code-review]

Missing service-enabled guards on some GCP API methods will cause errors when the service is disabled

Additional findings (file/line not in diff):

• 🟡 providers/gcp/resources/logging.go:151 — metrics() is missing the if !g.serviceEnabled { return nil, nil } guard that was added to buckets(). This will cause API calls to fail when the logging service is not enabled. Add the same guard at the top of this method.
• 🟡 providers/gcp/resources/logging.go:263 — sinks() is also missing the serviceEnabled guard. Same fix needed.
• 🟡 providers/gcp/resources/cloudrun.go:260 — operations() is missing the serviceEnabled guard while regions(), services(), and jobs() all have it. Add the same check here for consistency.

Superseded by new review

[mondoo-code-review]

Adds missing service-enabled guards to prevent API calls when logging/cloudrun services are disabled.