DevSecOps Without a Security Team — How I Embed Security Into GCP Engineering

Most of the engineering teams I work with don’t have a dedicated security hire. They have a CTO who cares about security, a VP Engineering who knows the platform has gaps, and a roadmap that keeps pushing security work to next quarter. The threat doesn’t wait for next quarter.

The good news is that on GCP, a small engineering team can achieve a genuinely strong security posture without a security team — if the platform is built correctly from the start. DevSecOps is not a headcount problem. It’s an architecture and automation problem.

This is how I approach it.

What DevSecOps Actually Means for a GCP Engineering Team

DevSecOps is the practice of embedding security controls into the engineering workflow rather than treating security as a separate gate or audit function. On GCP, that means three things in practice: security controls enforced at the infrastructure layer so engineers can’t accidentally misconfigure them away, security checks in the CI/CD pipeline so findings surface before deployment rather than after, and audit logging and alerting that gives you visibility without requiring a SOC analyst to watch a dashboard all day.

None of this requires a dedicated security engineer. It requires a platform architect who designs the controls in from the start — and automation that keeps them in place as the platform grows.

My approach follows the Security by Design pillar of the SCALE Framework. Security is a property of the architecture, not a layer bolted on top of it.

The Four Layers I Build Into Every GCP Platform

Layer 1 — Org Policy Constraints.
Org policies are the highest-leverage security control in GCP. They enforce restrictions at the organisation or folder level that no project-level configuration can override. I use them to enforce uniform bucket-level access on all GCS buckets, prevent public IPs on VM instances, restrict which regions workloads can be deployed to for data residency, require OS Login on Compute Engine, and disable service account key creation entirely.

The key insight: org policies enforce security without requiring engineers to make the right decision on every resource. The wrong decision becomes impossible, not just discouraged. This is the foundation I establish in every GCP Landing Zone Blueprint engagement.

Layer 2 — IAM Architecture.
The most common security finding I see in GCP platforms that grew without a security team: primitive roles (Owner, Editor) assigned directly to users and service accounts on production projects. It’s fast, it works, and it’s an enterprise security review failure.

I replace this with group-based IAM — access granted to Google Groups, not individuals — with predefined or custom roles scoped to the minimum required permissions. Service accounts get only the roles they need for their specific function. CI/CD pipelines authenticate via Workload Identity Federation — no downloaded keys, no static credentials in GitHub secrets. For privileged operations, GCP Privileged Access Manager provides just-in-time access with a full audit trail.

Layer 3 — Security in the CI/CD Pipeline.
A small engineering team without a security hire can still run security checks on every pull request — the pipeline does it automatically. I integrate three tools into every GCP CI/CD pipeline:

Checkov runs on every Terraform plan and blocks deployment of misconfigured resources — open GCS buckets, missing CMEK encryption, overpermissioned IAM bindings. Container image scanning via Artifact Registry catches known CVEs in base images before they reach production. Binary Authorization enforces that only signed, scanned images can be deployed to GKE or Cloud Run — unsigned images are rejected at the admission controller level.

These three controls mean that the most common misconfiguration and vulnerability classes are caught automatically, before any human reviews the PR. The DevSecOps pipeline I build treats security findings the same way it treats failing tests — they block the merge.

Layer 4 — Visibility Without a SOC.
You don’t need a security operations centre to have meaningful visibility into your GCP environment. You need the right alerts on the right signals.

I enable Cloud Audit Logs across all projects — Admin Activity, Data Access, and System Events — and export them to a centralised BigQuery dataset with retention aligned to compliance requirements. Security Command Center provides continuous misconfiguration detection across the org. I configure alerts for the signals that matter: service account key creation (should never happen if org policy is correct), IAM policy changes on production projects, public access granted to GCS buckets, and anomalous API call volumes.

For teams on Datadog, I route GCP audit logs and SCC findings into the same observability stack used for application monitoring. One dashboard, one alert channel, no separate security tooling to maintain. Full architecture in the GCP Disaster Recovery and HA page.

What This Looks Like at Audit Time

When a SOC 2 auditor or enterprise security reviewer asks for evidence of your security controls, a platform built this way answers most questions automatically. Org policies provide documented, enforced controls. IAM configuration in Terraform is version-controlled change history. Audit logs in BigQuery are queryable evidence of access events. Binary Authorization policy is documented image governance.

I’ve worked with B2B SaaS teams mid-audit — including teams using Drata for continuous compliance monitoring — where the platform we built together meant the audit evidence collection was largely automated. The hard work had been done at the architecture layer, not the compliance layer.

FAQ

Can a small engineering team realistically maintain a DevSecOps posture without a security hire?

Yes — if the security controls are automated and enforced at the infrastructure layer. Org policies, IaC policy scanning, and Binary Authorization don’t require human review on every deployment. They run automatically in the pipeline. The maintenance burden is low once the foundation is correctly built.

What is the first thing to fix if our GCP platform has no security structure?

Start with IAM. Remove primitive roles from production projects, replace with group-based least-privilege roles, and eliminate service account keys by migrating to Workload Identity Federation. These two changes address the most common findings in enterprise security reviews and SOC 2 audits, and both are achievable without disrupting running workloads.

How does DevSecOps on GCP differ from other cloud providers?

GCP’s org policy system is more prescriptive and enforceable than equivalent controls on AWS or Azure. The ability to enforce controls at the organisation level — above any project or team — means a small platform team can maintain consistent security posture across dozens of projects without per-project auditing. Workload Identity Federation is also more mature and better integrated on GCP than on competing platforms.

Is SOC 2 achievable for a small SaaS team running on GCP?

Yes. The technical controls required for SOC 2 — access management, encryption, audit logging, change management, incident response — map directly to GCP services that are straightforward to configure and automate. The gap is usually not the services, it’s the platform structure that makes those services consistently applied. That’s the architecture problem I solve.

DevSecOps Without a Security Team — How I Embed Security Into GCP Engineering