Cybersecurity · Network and cloud security
A cloud estate that stays configured the way you agreed
Account structure, segmentation, workload identity and runtime hardening, with policy enforced at the pull request rather than reported a week later. The measure is not a posture score. It is whether a misconfiguration can reach production at all.
Where this starts
The breach is rarely the exploit
Cloud incidents overwhelmingly begin with configuration rather than a vulnerability: an exposed storage bucket, an over-permissive role, a management port open to the internet, a network left flat because segmentation was going to be done later. None of these are sophisticated failures. They persist because nothing in the delivery process prevents them and nothing detects them quickly once they exist.
What we usually find
- A posture tool reporting several hundred findings that nobody triages
- Infrastructure defined as code, then changed by hand in the console and never reconciled
- A flat network where anything that lands can reach everything
- Production and non-production sharing accounts, roles or network paths
- Kubernetes clusters running with default permissions and no network policy
- Long-lived cloud keys in pipeline variables rather than federated short-lived credentials
Our position
Detecting a misconfiguration a week after it lands is a worse outcome than preventing it at the pull request, and it costs more to operate for the rest of the system’s life.
What the work covers
Foundations first, then enforcement
We work on structure before controls, because posture findings against a badly structured estate are effectively infinite. Once the shape is right, enforcement becomes cheap and the backlog becomes finite.
Account and landing zone structure
Separation by environment and by blast radius, with guardrails applied at the organisation level so a new account inherits the standard rather than being dragged up to it afterwards.
Segmentation and egress control
Segmentation that reflects how services actually communicate, private connectivity to managed services, and controlled egress. Egress control is what turns a foothold into a contained incident rather than a data transfer.
Workload identity
Federated short-lived credentials in place of static keys, least privilege derived from observed usage rather than guessed at, and a staged path to remove the standing access nobody has so far been willing to revoke.
Kubernetes and container runtime
Admission control that rejects unsigned or non-compliant workloads, network policy defaulting to deny, pod security standards applied, and runtime detection where the workload justifies it. How the images themselves are built and hardened sits with application security.
Policy as code
Policy evaluated against the infrastructure plan, so a public bucket or an open management port fails the pull request with the rule and the line that broke it. Drift detection sits on top, because the console will always be used at three in the morning.
Hardening and patch operations
Benchmarked baselines, golden images rebuilt on a schedule rather than patched in place, and automated rollout with a patch latency figure you can actually report to an auditor or a board.
How it stays fixed
Prevent where you can, detect where you cannot
Every control below lives in one of two places: the pipeline, where it prevents, or the estate, where it detects and corrects. Very little of it belongs in a quarterly review.
- Plan
- Policy evaluated against the infrastructure plan, failing the pull request with the specific rule, the resource and the line, so the fix is obvious rather than a research task.
- Apply
- Organisation level guardrails a deployment cannot override, so the pipeline is not the only thing standing between an engineer in a hurry and a public bucket.
- Admit
- Cluster admission control rejecting unsigned images, privileged containers and workloads without resource limits, at the point of admission rather than in a report.
- Detect
- Posture and drift findings routed to the team that owns the account, with a service level for the severities that matter and deliberate silence for the ones that do not.
- Correct
- Automated remediation for the narrow set of findings where the correct action is unambiguous, and a ticket carrying full context for everything else.
What you are left holding
- An account and network structure documented and enforced at the organisation level
- Policy as code failing pull requests on the rules you chose
- Drift detection with a named owner per account
- A patch and baseline process with a latency figure you can report
- A posture backlog that is finite and falling rather than infinite and ignored
Send us your account structure and one infrastructure repository
We will come back with the three structural changes that remove the most findings, before anyone is asked to buy another tool.