A public Cloud Function running as the default Compute Engine service account, with that account still carrying the Editor role, gives anyone who reaches the function a path to read, modify, or delete almost everything in the project. Each of those three settings is a routine default in a young Google Cloud project. Together, they form one of the most common routes to full project compromise.
Most of the thousands of entries in a Security Command Center dashboard never rise to that level. Learning to tell the two apart is the core problem in Google Cloud security once a company has been shipping for a while.
Security debt does not threaten a business evenly.
Severity labels and finding counts cannot separate those two cases, because they score issues in isolation and the danger lives in how they combine.
This becomes urgent at a specific moment, and for most mid-market companies that moment arrives with a deal, not a breach. A prospective enterprise customer reaches the security review stage of procurement and sends a security questionnaire, and the clock that starts here is unforgiving. You get about seven days to complete the first round. How that round lands decides the deal.
A strong first round can close the deal fast, with no further questions. A vague-but-solid first round buys a second round, another roughly seven days to clarify and provide evidence, and the deal still goes through. A weak first round stalls it, and now you are three weeks deep and slipping. A bad first round can end it outright, with no second round and no deal. The asymmetry is the whole point: the same week of work produces a closed deal or a dead one depending only on whether your environment can answer the questions when they are first asked.
This is where most Google Cloud security advice stops being useful, because it assumes a clean project. The companies that need the advice shipped fast, took on debt while finding product-market fit, and now run an access model built for five people across an environment that serves hundreds. When the questionnaire arrives, that gap between the form and the infrastructure is what they have a week to close.
Marius-Florin Cristian, CISSP and cyber lead at Revolgy, who has taken B2B SaaS companies from pre-seed to exit, frames the triage around how the data actually flows:
“When you have to deal with vulnerabilities and potential exploits, you need to consider them as part of the path the data flows through. You cannot treat vulnerabilities individually, or you get overwhelmed with tens of thousands of alerts that most of the time are not relevant. What makes a series of vulnerabilities actually exploitable is that they compound into an attack chain, bypassing several layers of in-depth defence until they become an active exploit that exfiltrates data, modifies it without authorization, or denies access to the service.”
This guide covers how to separate dangerous security debt from cosmetic noise, the order to fix it while the business keeps shipping, and how to set a stopping point so the work matches the risk.
The pattern is predictable, and it reflects rational decisions rather than carelessness. A team finding product-market fit
Shipping is the only thing keeping the company alive at that stage, so anything that slows shipping loses.
The early setup is a reasonable starting point. It turns into debt when it survives unchanged while the company grows around it. By Series B the same project hosts forty people and a dozen services on an access model that was designed for five, and the symptoms are consistent across almost every environment:
For most mid-market companies, the event that forces the issue is commercial. A prospective enterprise customer reaches the security review stage of procurement and asks for compliance documentation as part of vendor due diligence, usually with a deadline of a week or two. When the artifacts do not exist, the deal stops moving.
That deadline changes what security spending is for. Most teams think about security as risk reduction, lowering the odds of a breach or a fine. The more useful frame for a growth-stage company is access. Certification is what qualifies you to bid for contracts that would otherwise be closed to you. Marius makes the commercial case directly:
“People are more receptive when you say you should invest five, ten percent of your yearly budget into security, and it’s not a time sink because it gives you access to these contracts, and they value much more in business income.”
The return compounds, which is what makes the frame more than a one-deal calculation. The spend is front-loaded, but it does not open a single contract. It qualifies you for every deal in your pipeline and for the whole market segment that shares that risk profile. The investment holds roughly flat in absolute terms as you grow, so as the budget rises, it falls as a percentage, and the lean posture stays lean.
It helps to separate two kinds of security spend. Operational investment is the cost of running the system day to day: reacting to alerts, tracking incidents, keeping controls live. Strategic investment is aligning that operational spend to a specific goal, meeting the risk profile of the larger clients you are trying to reach. The percentages are always relative to your financials and your ambition, but the split is what keeps spending tied to a commercial outcome rather than to fear.
You do not always need the certificate to win the deal. For the first few contracts you can pass on evidence alone, producing proof during security due diligence that you operate the controls the certification would attest to. The certificate changes the economics later. In a crowded market of near-identical products, it is a trust differentiator that tips a close decision your way. And once you have more than a deal a month in the pipeline, handing over a certificate is far faster than completing a 150-row questionnaire each time. The framework you need still depends on the deal you are chasing:
Cost is a quieter second trigger. Many startups run for a year or two on Google Cloud credits from their investor network, and when the credits expire, the real bill arrives. Marius has seen the same pattern several times: “We have two months, and then we actually have to start paying.” A cost review and a security review tend to land in the same quarter, which is a difficult moment to also be untangling a large, un-audited estate.
The short version: the debt has a due date you do not control. Your sales pipeline sets it for you.
When a security review lands, the natural response is to start working down the list of flagged findings. That response burns the most valuable week you have. A large Google Cloud environment produces thousands of findings, most of them isolated misconfigurations with no realistic path to anything that matters. Clearing them first consumes engineering time and leaves the genuinely dangerous gaps in place.
The starting point that works is the attack chain: a sequence of weaknesses that together form a realistic route from an entry point to a high-value resource. Marius is direct about where attention belongs:
“If you have two or three that are actually attackable, an attack chain, then you should really prioritize it. Inform the executives about the urgent things to fix now, and why they should care, then bundle the big non-urgent rest for later. There’s no point in making a report of two thousand pages. The shorter and more on point the report is, the more chance it has of landing, because one or two pages gets read and acted on where sixty pages gets filed away.”
Google Cloud has native tooling built for this triage. Security Command Center’s Risk Engine runs attack path simulations across a graph of your resources, IAM bindings, and network connections. Then assigns each finding an attack exposure score based on whether a simulated attacker starting from the public internet can actually reach a resource you have marked as high-value. Two of its finding types map directly onto Marius’s point:
The same discipline governs ongoing alerting, not only one-time audits. Revolgy’s standard guidance is to stop alerting on basic infrastructure signals such as CPU, which generate noise that teams quickly learn to ignore, and to alert instead on application health: latency, error rates, and whether the service is actually serving.
The identity layer repays attention before anything else, because it is where attack chains converge and where an auditor looks first. It is also where the textbook answer, managing every permission in code and granting least privilege everywhere, runs hardest into a team that still has to ship. The work is divided into three parts, in order.
The highest-value single fix is taking the shared, over-privileged default service account out of anything that runs your code and giving each workload a dedicated service account scoped to what it actually needs.
This is the clearest case of debt that grows more painful the longer it sits. As Revolgy cloud architect David Kotalík points out, retrofitting it can mean replacing service accounts across every application you run. A firewall rule can be changed almost any time by adding the new rule before removing the old one, but a service account migration reaches into every running workload, so postponing it only raises the eventual cost.
The textbook answer to IAM sprawl is fully Terraform-managed, authoritative IAM, with one source of truth and no manual changes. Incidents are what break that ideal in practice, because routing an emergency permission change through a Terraform pull request while production is down at 2 AM is not realistic. Marius’s social contract keeps the source of truth intact without pretending incidents do not happen:
“It’s authoritative by default, but the on-call engineer has the privilege to bypass it. If it is bypassed, then there should not be drift.”
That arrangement has three parts. Terraform owns the IAM policy, so the code is the default source of truth. The designated on-call engineer holds an explicit, documented privilege to override it during an incident. Once the incident closes, the bypass is reconciled in one of two ways: either the emergency change is codified into Terraform because it should persist, or it is reverted so the live state matches what the code already describes. Either way the drift is closed, deliberately, and recorded.
That reconciliation is where the compliance value is created, not just the access control. Each incident leaves a paper trail: the ticket that opened it, the documented bypass, the resolution, and the post-mortem. Those artifacts are what an auditor or an enterprise customer’s due diligence actually wants to see, because they prove you operate a process for handling the unexpected rather than simply claiming one. Marius treats the underlying accountability as non-negotiable:
“You cannot talk about security without having somebody accountable for the actions that they do.”
An authoritative state with a logged, deliberate exception, and a trail behind it, stays auditable in a way that ad hoc console changes never are.
Managing group membership by hand becomes a liability as the team grows. The sustainable model treats lifecycle events in your directory, Google Workspace onboarding, role changes, and offboarding, as the triggers for permission changes. A developer who moves into a platform role picks up the new access automatically, and a marketing hire never receives production access in the first place.
Some security debt sits quietly as risk, and some of it grows and makes itself harder to remove the longer you leave it. Monolithic Terraform state is the clearest example of the second kind. A single root module managing hundreds of resources creates three problems that compound together:
The fix is to modularize by domain, giving each area that changes independently its own state. Marius splits his estates into distinct modules:
With that split, a two-line change touches only the module it belongs to, runtime drops, the blast radius is contained, and the change is straightforward to reason about.
The three filters tell you what to fix first. ASVS tiering tells you when to stop, which matters because building security past your actual risk profile wastes the same budget you are trying to protect. The OWASP Application Security Verification Standard, whose version 5.0 arrived in May 2025, defines three assurance levels, and the v5 release deliberately rebalanced them so that Level 1 is a realistic entry point:
The goal is to match the tier to your application’s real risk profile and use that as the input to how much infrastructure security you build around it. A marketing-analytics SaaS and a payment platform sit at different levels, and knowing which one you are gives you a defensible place to stop.
Marius pairs the tier with the CIA triad as the underlying test, treating confidentiality, integrity, and availability as a tripod: data that is perfectly confidential and correct but reachable only one hour a day is useless, and data that is always available but exposed is a liability. Remove any leg and the system fails, which is why the application that processes the data gets secured before the networking and infrastructure wrapped around it.
Applied in order, the filters give you a working sequence:
The value of all this is in the order. Fixing the wrong thing first is how a team spends a deal deadline and still comes out exposed.
If you have read this far and still cannot tell which gaps in your environment sit on a real attack path and which are noise, that uncertainty is the starting point for an Architecture Clinic with Revolgy.
Revolgy has worked through this with companies on both sides:
That is the judgment worth borrowing before you commit engineering time to a findings list.
Revolgy runs free 45-minute 1:1 working sessions with senior Google Cloud architects. Bring your current IAM setup, your Security Command Center findings, or the compliance deadline you are working toward. Within 24 hours of the session, you receive a structured summary of the gaps that actually matter and the order to address them.
Prioritize attack chains ahead of individual findings. A connected sequence of weaknesses that forms a realistic path to a high-value resource carries far more risk than an isolated misconfiguration with no way to reach anything. Google Cloud’s Security Command Center Risk Engine scores findings by attack exposure and flags toxic combinations and chokepoints, which turns the triage into something concrete.
Terraform should be the authoritative source for IAM by default, with one documented exception for the on-call engineer during incidents. Any drift introduced while responding to an incident is reconciled back into Terraform afterward, alongside a root cause analysis, so the code stays the source of truth. This keeps incident response fast without giving up auditability.
The practical trigger is your first enterprise or regulated-industry prospect asking for compliance documentation during due diligence. Putting the foundations in earlier, specifically group-based IAM, dedicated service accounts, authoritative Terraform state, and network segmentation, avoids the emergency rework of fixing everything at once under a deal deadline.