SCC Automation Design

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

SCC AUTOMATION DESIGN

Date: January 30, 2024

Context and Problem Statement

• In the Information Security Continuous Monitoring initiative, security tools were compared and SCC was chosen for cost effective, GCP native asset and compliance reporting, logging and endpoint threat detection, and dynamic application security testing (DAST). Additional security integrations are possible with third-parties like Cloudflare.
• Automation is the preferred configuration method, however the SCC API, SDK, and Terraform modules do not yet provide the full scope of SCC changes. Services can be configured with gcloud commands, with many settings still in alpha.
• Security scanning should be turned on by default, but we do not want to just enable everything globally without following best practices and proper testing.

Decision Drivers

• Provide a scalable, automated way to configure security services
• Ease of use

Decision Outcome

Automation with Information Security owned service account and organization-level permissions

• Good, because security services with no impact can be configured and managed at the organization level with an auditable process, i.e. event threat detection in Cloud Logging.
• Good, because there is not an additional service account that has to be configured in each project.
• Good, because there is a single account with the least privilege when the key needs to be rotated.
• Good, because users can follow the familiar change workflow.
• Good, because there is already a pattern for using a service account with key saved in GSM.
• Bad, because an OPA exception is required to allow the account to have the securitycenter.setttingsEditor role at the organization level. We do not want to add this role in the allowed list because it is not something that most engineers will need for a project. It is strictly a security function.

Consequences/Tech Debt Incurred

As the GCP SCC API matures, the SDK or Terraform modules may replace the bash script. There should be a periodic review for this capability.

Alternatives Considered

Automation with per project service accounts

• Good, because no OPA exception is required.
• Good, because users can follow the familiar change workflow.
• Good, because accounts would be configured with the least privilege.
• Bad, because an additional service account that has to be configured in each project.
• Bad, because organizational level configurations would be a longer process, requiring Lumos approval to request editor permissions.

Manual configuration on console.cloud.google.com, controlled by Lumos

• Good, because no service accounts are required so no OPA failures.
• Bad, because it does not provide configuration automation.
• Bad, because it is not scalable, requiring a single team to perform all of the changes.