CASE STUDY · CLOUD SECURITY (CSPM / CWPP)
Closing 200+ cloud misconfigurations for a fast-scaling SaaS startup.
- 214214 misconfigurations closed, including all 18 high-priority findings
- 3→0 atCritical findings down from 3 to 0 at launch
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised SaaS startup. Name withheld under confidentiality.
A posture scan across every account, risk-based prioritisation, remediation sprints and guardrail policies to prevent regressions.
- 1The company had grown its cloud footprint fast.
- 2Engineers created resources as they needed them, across several accounts, and nobody had set a security baseline.
- 3There was no list of what existed, no agreed rules for storage or access, and no way to tell which risks mattered.
- 4The team had run a scanner once and received a long list it could not act on.
- 5A customer security review was coming, and the leadership wanted to know where they stood before the customer told them.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early on, we tightened a network rule that looked unused
It was used, by a nightly batch job that ran from a partner's address range. The job failed the next morning. We rolled the rule back within the hour and told the team plainly what had happened.
- PROBLEM 02We rolled the rule back within the hour and told the team plainly what had happened
- PROBLEM 03After that we changed our method
Before closing any network or permission finding, we checked access logs for recent use and asked the owner. Risky changes went to a lower environment first. No customer was affected, but it cost us a day and some trust, and the checks stayed for the rest of the engagement.
- PROBLEM 04No customer was affected, but it cost us a day and some trust, and the checks stayed for the rest of the engagement
03 · THE PROCESS
How we ran it.
We worked in three phases.
- 01Discovery
read-only access, a full inventory and a first scan. We reviewed findings with the engineers who built the systems, so intentional settings were marked and not "fixed".
- 02Remediation sprints
short sprints, highest risk first. We paired with the owning team on each fix. A weekly review covered what closed, what was blocked and what needed a decision from the founders.
- 03Guardrails and handover
policies in the pipeline and in the cloud accounts, then a runbook and a walkthrough for the engineers who would own it.
The team was small: security engineers working side by side with the startup's own developers, with a standing check-in each week.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
New accounts start from a baseline template, not from a blank console.
- NOW 02
Guardrail policies run on every deploy, so common mistakes are blocked before they ship.
- NOW 03
Every finding has a named owner and a fix-by date.
- NOW 04
The team reviews permissions on a schedule and removes unused keys.
- 214
214 misconfigurations closed, including all 18 high-priority findings
- 3→0 at
Critical findings down from 3 to 0 at launch
05 · WHAT WE BUILT
How it works.
- We ranked findings by exposure and data sensitivity.
- Is it reachable from the internet?
- What does it hold?
- What could an attacker do next?
- Storage, network rules and identity came first, because they give the widest blast radius.
- Fixes were made as infrastructure-as-code changes where the startup already used it, so the repair also stopped drift.
- What went wrong, part two
- Some fixes needed a code change, not a setting. A handful of storage buckets were public because the application served files straight from them. Closing them would have broken the product. We worked with the developers to put a signed-link approach in front of those files, then closed the buckets. These items took longer than the sprint plan allowed. We said so early and moved them to a separate track, so the rest of the work did not stall.
- Handover
- In the last stage we ran a session where the startup's engineers fixed a new finding themselves, with us watching. We left a short runbook covering how to read a finding, how to decide its priority and how to add a guardrail.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company had grown its cloud footprint fast. Engineers created resources as they needed them, across several accounts, and nobody had set a security baseline. There was no list of what existed, no agreed rules for storage or access, and no way to tell which risks mattered. The team had run a scanner once and received a long list it could not act on. A customer security review was coming, and the leadership wanted to know where they stood before the customer told them.
- What did Brandsmashers build?
- A posture scan across every account, risk-based prioritisation, remediation sprints and guardrail policies to prevent regressions.
- How was the work run?
- We worked in three phases.
- What were the results?
- 214 misconfigurations closed, including all 18 high-priority findings; critical findings down from 3 to 0 at launch.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
