LetsBloom: Compliant-by-Default Landing Zones
A marketplace of 18 secure-by-design landing zones and blueprints for a global bank's fintech arm, all defined as Terraform and kept continuously compliant by policy-as-code.
LetsBloom was a security product for a global bank's fintech customers, built for Standard Chartered Ventures. My job as a DevSecOps engineer was to make secure and production-ready the default, not an afterthought. I built its marketplace of landing zones and secure blueprints, every one defined as code with the security baked in from the design stage, plus the guardrails that keep them compliant even after a customer starts changing them.
Security, shifted all the way left
The most secure line of code is the one a good pattern meant you never had to write. So I pushed security all the way left, into the design and architecture stage, rather than reviewing it in at the end. As a DevSecOps engineer, that framing was the whole point: build the secure choice into the platform, then make every stage of delivery prove it.
In practice that is an automated gate at each stage, from the threat model through runtime. Here is the pipeline I set as the standard:
A gate at every stage, from design to runtime, not a scan bolted on at the end. Click a stage.
- Security requirements and a threat model come before any code. Choosing a blueprint is itself a security decision, because the pattern already encodes the controls.
- Shift-left starts here. If the design is wrong, no downstream scan saves you.
A marketplace, not a services engagement
The offering was a marketplace. Instead of hand-building each customer's environment, LetsBloom shipped a catalog of pre-approved landing zones and secure blueprints with the tools and best practices already baked in. A customer picks a pattern and gets a secure, production-ready environment, not a blank account and a long checklist.
Every item is defined as code: Terraform for the infrastructure, and code for the non-Terraform pieces too, so a blueprint is versioned, reviewable, and identical every time it is deployed.
Pre-approved landing zones and workload patterns, every one defined as Terraform and secure by design. Click a blueprint.
- A Transit Gateway hub connecting workload spoke VPCs.
- Centralized egress and an inspection VPC running Network Firewall.
- Segmented spokes; ingress, egress, and east-west traffic inspected separately.
- VPC flow logs and DNS logs shipped to the central archive.
What a compliant landing zone actually contains
A landing zone is the account structure and network a workload lands in, built so that doing the secure thing is the only easy thing. The multi-network ones are the most involved: a hub-and-spoke topology on Transit Gateways, a hard edge, segmented workload spokes, and a separate account whose only job is to watch everything.
Hub-and-spoke, with a hard edge, segmented workloads, and a separate account that watches everything.
Everything as code, guardrails included
Because everything is Terraform, the guardrails can live in the same place: as code, in the pipeline. A Rego policy-as-code validator runs against every terraform plan, and a plan that violates the rules simply cannot merge. Stopping drift before it starts beats chasing it later.
# A policy-as-code gate run against every terraform plan.
# A plan that trips any rule cannot merge, so drift never starts.
package letsbloom.guardrails
deny[msg] {
sg := input.resource_changes[_]
sg.type == "aws_security_group_rule"
sg.change.after.cidr_blocks[_] == "0.0.0.0/0"
sg.change.after.from_port == 22
msg := sprintf("%s exposes SSH to the world", [sg.address])
}
deny[msg] {
b := input.resource_changes[_]
b.type == "aws_s3_bucket"
not b.change.after.server_side_encryption_configuration
msg := sprintf("%s has no server-side encryption", [b.address])
}Staying compliant after the customer takes over
A blueprint is only compliant on day one. The harder problem is day ninety, after the customer has started changing things. Two mechanisms keep the posture from eroding:
- Cloud Custodian enforced 100+ policies, continuously checking the live estate and reconciling customer-modified resources back to the bank's security baseline.
- AWS WAF and Shield fronted the workloads, and the Rego validator kept gating every Terraform change before it could merge, so the guardrails applied to the customer's changes too.
The outcome
Getting the DevSecOps foundations right early is what made the rest possible. Because security was designed in and automated rather than reviewed in by hand, we could onboard fast without lowering the bar: three fintech customers live within four months of the project's inception. On a platform whose entire value proposition is trust, that pace only works when the secure path is also the default path.