AT A GLANCE
Industry: Software / Technology company
Platform: Google Cloud — GKE, Cloud Build, Artifact Registry, Secret Manager, Workload Identity Federation
Services: DevSecOps & Cloud Security, Platform Engineering, GCP Architecture
Location: Canada
Engagement led by Amit Malhotra, Principal GCP Architect at Buoyant Cloud Inc. — Toronto, Canada
THE SITUATION
Security Questionnaires Were Blocking Enterprise Deals
A Canadian B2B software company selling to enterprise customers in North America had built a strong product and was winning enterprise customers — until enterprise procurement started asking detailed security questions that exposed how informally the engineering platform had been put together. The CI/CD pipelines were functional but had been built for speed rather than security. Service account keys were stored in GitHub Actions secrets and environment variables. IAM permissions had grown without a clear model. And there was no documented answer to questions about how code went from a developer’s laptop to production, who had access to what, and what controls prevented a misconfigured or vulnerable deployment from reaching a customer environment.
The sales team was experiencing a pattern that the engineering team recognized but hadn’t yet been given the mandate to fix: promising enterprise deals stalling at the security review stage, with procurement teams asking for documentation and evidence that didn’t exist. One significant deal had been lost explicitly because the security questionnaire responses were insufficient. Another was on hold pending a security assessment.
The engineering leadership decision to invest in a DevSecOps platform overhaul was driven directly by pipeline revenue. The brief was clear: build a GCP delivery platform where the security controls are real, documented, and demonstrable — not just claimed.
THE CHALLENGE
The Security Gaps That Were Blocking Enterprise Sales
Static service account keys everywhere: GitHub Actions workflows, Cloud Build configurations, and application deployments all using long-lived service account key files — stored in CI secrets, environment variables, and in some cases committed to repositories. Any of these keys leaking would give an attacker broad access to the GCP environment.
No security gates in CI/CD: Pipelines that built container images and deployed them to GKE without any vulnerability scanning, image signing, or policy validation. Any image, including one with known critical vulnerabilities, could be deployed to production without any automated check.
Overprivileged IAM: Service accounts with project-level roles assigned for convenience during early development — permissions far broader than any single workload needed. No least-privilege model, no resource-scoped bindings, and no audit of what each account actually needed versus what it had.
No secrets management: Application secrets — database credentials, third-party API keys, webhook signing secrets — stored in Kubernetes ConfigMaps, environment variables in deployment manifests, and hardcoded in some configuration files. No rotation, no audit trail, and no centralized visibility of what secrets existed and who could access them.
- No documented security architecture: No IAM architecture diagram, no documented deployment process, no evidence of security controls that could be provided in response to a security questionnaire. The security posture existed only in the informal practices of individual engineers.
THE SOLUTION
A Security-First DevSecOps Platform Built to Answer Enterprise Questions Confidently
I designed and implemented a DevSecOps delivery platform on GCP where every security control is structural — enforced by the platform rather than depending on engineers following the right process. The SCALE Framework’s Security by Design pillar drove every decision, with the explicit goal that any security questionnaire question about the delivery platform should be answerable with documented evidence, not verbal assurance.
Workload Identity Federation — zero static keys: All GitHub Actions workflows and Cloud Build pipelines migrated to Workload Identity Federation — authenticating to GCP through short-lived federated tokens rather than service account key files. Every static service account key identified, documented, and revoked as part of the migration. No long-lived credentials remaining in any CI/CD configuration.
Least-privilege IAM redesign: Full IAM audit across all GCP projects — existing bindings reviewed, excess permissions removed, service accounts scoped to individual workloads with resource-level bindings rather than project-level roles. IAM architecture documented with rationale for every binding, providing a clear evidence base for auditors.
Secure CI/CD pipeline with automated security gates: Cloud Build pipelines rebuilt with security validation at every stage — container image vulnerability scanning with Artifact Analysis, image signing with Cloud KMS, Binary Authorization policy on GKE requiring signed images, and OPA/Conftest Terraform plan validation catching infrastructure misconfigurations before apply. No image can reach production without passing every gate.
Secret Manager integration: All application secrets migrated from environment variables and ConfigMaps to Secret Manager — accessed at runtime through Workload Identity, with audit logs for every access, automated rotation for supported secret types, and a complete inventory of all secrets and their authorized consumers.
GKE security hardening: Pod Security Standards enforcement across all namespaces, Workload Identity per pod replacing shared service accounts, network policies between namespaces, and Binary Authorization policy enforcement — so no workload can run with elevated privileges or from an unsigned image regardless of how it was deployed.
- Security architecture documentation: Complete written documentation of the IAM model, deployment pipeline security controls, secrets management approach, audit logging configuration, and GKE security baseline — structured to directly answer the categories of questions that appear in enterprise security questionnaires and SOC 2 assessments.
THE OUTCOMES
What Changed After the Engagement
Zero
static service account keys remaining across all GCP projects and CI/CD pipelines
100%
of production deployments going through automated security scanning and Binary Authorization
2
enterprise deals unblocked within 60 days of completing the security architecture documentation
Beyond the metrics:
The security questionnaire that had caused a deal to stall was completed with documented evidence for every question — the prospect’s security team confirmed it was the most complete response they had received from a vendor of comparable size
Engineering team no longer treating security as a pre-sales scramble — the controls are structural and always on, so the answer to ‘can you provide evidence of your security controls’ is the same on any given day
Secret Manager audit logs give complete visibility of every credential access — who accessed what, when, and from which workload. See the DevSecOps & Cloud Security service for the full service detail.
Binary Authorization and vulnerability scanning have caught real issues — a deployment attempt with a critical CVE in a base image was blocked automatically before it reached staging, which would not have been detected under the previous pipeline
This engagement is representative of the DevSecOps & Cloud Security service. See also the SaaS & Technology Platforms industry page and the FinTech & Regulated Systems page for related industry context.
This engagement is typical for Canadian B2B SaaS and software companies where enterprise sales are stalling at the security review stage. If your team is being asked for security documentation that doesn’t exist yet, or if your GCP delivery pipeline wasn’t built with SOC 2 or enterprise procurement in mind, this is the pattern we follow.