Google Cloud Security Command Center Integration with DefectDojo

Google Cloud Security Command Center Integration with DefectDojo

Google Cloud Security Command Center (SCC) is Google Cloud's built-in security and risk service. Once activated on an organization, it collects findings from Google's own detectors and integrated sources across projects, covering misconfigurations, threats, observations, and software vulnerabilities on resources such as Compute Engine instances, Cloud Storage buckets, and IAM settings. Findings can be listed through the SCC API or the gcloud CLI as JSON, which is the format DefectDojo reads.

Google Cloud Security Command Center Integration with DefectDojo

We already pay attention to Google Cloud Security Command Center, but its console only knows about Google Cloud. Our remediation work happens in DefectDojo, next to the SAST, SCA, and pentest results for the same services. Bringing SCC findings into DefectDojo puts a public bucket or an unpatched VM on the Asset that owns it, with an SLA clock, an assignee, and a history we can report on. We can pull findings with the DefectDojo Pro connector, or import a gcloud export where granting a service account to an outside system is not an option yet.

Why Google Cloud Security Command Center Matters

SCC sees the live state of a Google Cloud organization, which code scanning cannot.

• It reports configuration drift on running resources, including changes someone made in the console that never touched infrastructure as code.
• One export can mix several finding classes: misconfigurations, threats, observations, and vulnerabilities with CVE data.
• Each finding carries a category such as PUBLIC_BUCKET_ACL or MFA_NOT_ENFORCED, which works as a stable rule identifier.
• The Standard tier costs nothing, so most Google Cloud customers already have the data available.
• On its own, SCC is scoped to Google Cloud. Teams running other clouds or on-premises systems still need one place to prioritize everything together.

Advantages of This Integration

What changes once SCC findings flow through DefectDojo:

• File and connector findings line up. The parser and the DefectDojo Pro connector report the same scan type, Google Cloud SCC - Connectors Import, so an organization that starts with file uploads and later turns on the connector keeps one set of findings instead of two.
• Exact deduplication. The hash is built from unique_id_from_tool alone, which is the finding's full SCC resource name. That name is unique across the organization, so a repeat import of the same finding matches cleanly.
• Lifecycle from SCC state. The connector imports only active, unmuted findings. When a finding is deactivated or muted in SCC, the next sync mitigates it in DefectDojo.
• Per-project ownership. The connector creates a Record for each Google Cloud project with open findings, and you map each Record to a DefectDojo Asset owned by the right team.
• The usual triage tools. SLAs per severity, risk acceptance with expiry, false positive marking, notes, and Jira pushes all apply to cloud findings the same way they apply to scanner output.

How This Integration Works

DefectDojo supports three ways in. All of them use the scan type Google Cloud SCC - Connectors Import.

Option 1: Export with gcloud and import the file. Write the SCC ListFindings response to JSON:

gcloud scc findings list ORGANIZATION_ID --format=json > scc.json

The parser reads results under listFindingsResults, and also accepts a bare array (which is what gcloud writes) or an export where the finding fields sit at the top level. Each result pairs a finding with the resource it was found on. Keep both halves: the resource supplies the display name and type that make a title readable.

In the UI, open the Engagement, choose Import Scan Results, select Google Cloud SCC - Connectors Import, and upload scc.json. For automation, use the API in Community Edition or DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=Google Cloud SCC - Connectors Import" 
  -F "file=@scc.json" 
  -F "product_name=gcp-production" 
  -F "engagement_name=SCC Weekly" 
  -F "auto_create_context=true"

Option 2: Universal Importer (DefectDojo Pro).

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "Google Cloud SCC - Connectors Import" 
  --report-path "./scc.json" 
  --product-name "gcp-production" 
  --engagement-name "SCC Weekly" 
  --auto-create-context

Option 3: The Google Cloud SCC connector (DefectDojo Pro). The connector calls the Security Command Center v2 REST API on a schedule. Setup needs:

1. SCC activated on the organization, and a dedicated service account with the Security Center Findings Viewer role at the scope you want.
2. A JSON key for that service account, pasted into the Service Account Key field.
3. A Parent Resource of organizations/{id}, folders/{id}, or projects/{id}. Leave Location at the default https://securitycenter.googleapis.com.
4. An optional Minimum Severity.

By default you get one Record per project. The Asset Grouping setting can split findings further by resource type or by individual resource, and Organization Placement can create a DefectDojo Organization per project or per folder for newly created assets.

Data Granularity: What Gets Imported

Within one file, results that share a finding name are collapsed to a single finding. The parser does not filter on SCC state or mute, so whatever the export contains is imported.

Use Cases

When a service account is not approved yet: A security team waiting on a vendor review exports SCC findings weekly with gcloud and imports them. When the connector is approved later, its findings deduplicate against the uploaded ones because the scan type and unique IDs match.

For multi-cloud reporting: An organization running Google Cloud alongside another provider imports each cloud's posture tool into DefectDojo. Leadership gets one view of open Critical and High cloud findings by team, rather than one console per provider.

For per-resource ownership: A platform team sets the connector's Asset Grouping to Resource so each Compute Engine instance or bucket becomes its own Asset under its project. Teams that own specific workloads see only their findings, and the Asset Hierarchy feature keeps the project relationship visible.

During audits: Cloud misconfigurations carry discovery dates, SLA status, and closure history in DefectDojo, which answers "how long was that bucket public" without digging through console screenshots.

Operational Tips

• Filter the gcloud export to active findings (for example with gcloud's --filter flag on state) before importing. The parser imports every result in the file, while the connector only takes active, unmuted ones.
• Reimport each export into the same Test so findings that disappeared from SCC are mitigated and returning ones are reactivated.
• Use minimum_severity on file imports, or Minimum Severity on the connector, if low-severity observations would bury real issues.
• SEVERITY_UNSPECIFIED lands as Info. If one of your SCC sources never sets severity, review its Info findings rather than ignoring them.
• CVE and CVSS data appear only on vulnerability-class findings, so filter on Vulnerability IDs when you want patching work and on category when you want configuration work.
• When switching the connector to a finer Asset Grouping, enable Auto Map on the connection so findings move to the new Assets without a gap.