Context

The original customer was a large European financial services firm operating across eight AWS accounts, three regions, and two compliance regimes. They needed a unified view of their security posture: findings aggregated, normalized, prioritized, and routed to the right team without manual intervention. AWS Security Hub existed. Their multi-account setup, with a complex organizational structure that had grown through acquisition, meant that the out-of-the-box deployment did not fit.

They also had no product budget for a third-party SIEM. The engagement had to produce working infrastructure using the AWS tooling they were already licensed for.

The real problem

Multi-account security posture management sounds like a tooling problem. It is usually an organizational problem wearing a tooling costume.

In this case, the findings were already being generated. Every AWS account had GuardDuty and Security Hub enabled. The problem was that findings from different accounts went to different people, using different severity conventions, with no deduplication and no routing logic. A critical finding in one account might sit unacknowledged for a week while a lower-severity finding in another account triggered an incident response procedure because the team monitoring it had a lower threshold.

The gap was not data. It was signal routing and severity normalization across organizational units that had previously operated independently and now shared an AWS organization.

Approach

We built a central aggregation layer in a dedicated security account that did three things. First, it normalized severity across all accounts using a consistent scoring model rather than the default severity levels that different teams had calibrated differently over time. Second, it routed findings to the right team based on the account, region, and finding type, using a configuration file that the security team could update without a code deployment. Third, it suppressed known-safe findings that met specific criteria, so the team could trust that anything surfacing required attention.

The suppression logic was the part we got wrong twice. The first version suppressed too aggressively, based on account tags that were inconsistently applied. Findings were being suppressed that should have surfaced. The second version was too conservative: suppression required an exact match on all relevant fields, which meant the same underlying issue across different accounts generated separate findings every time.

The version that worked used a weighted match: findings that matched on account, region, finding type, and resource type were grouped and deduplicated, with the highest severity retained. The security team could mark specific finding patterns as permanently suppressed with a documented rationale. Everything else surfaced, once, to the right person.

We packaged the entire solution as Infrastructure as Code: Terraform modules, an opinionated structure for the security account, and a configuration layer that the customer could own. The intention was that the customer would maintain it after our engagement ended.

What happened with open-source

The original customer’s security lead presented the solution at an AWS internal sharing session. Three other customers, who had the same multi-account problem and the same budget constraints, asked for access to the implementation.

Rather than running three parallel implementations from scratch, we worked with the original customer to extract the generic parts of the solution into a public repository. The customer agreed: they preferred to be known as contributors to the solution rather than sole owners of something that would inevitably be re-implemented by others anyway.

The public release added documentation, a deployment guide, and a modular structure that made it easier to adopt in environments that did not exactly match the original customer’s setup. Within six months, it had been deployed in more than ten Fortune 500 organizations across financial services, healthcare, and manufacturing.

What worked

  • The configuration-over-code routing model meant that the security team could adapt routing rules without engaging a developer. When the customer’s organizational structure changed after an acquisition, they updated the configuration file themselves. The codebase did not change.
  • The weighted matching deduplication reduced findings volume by about 65% in the first month, without suppressing anything that would have otherwise required action. The security team reported that alert fatigue decreased significantly within two weeks.
  • The open-source release created a feedback loop that improved the solution faster than an internal project would have. Issues filed by external users identified edge cases in the Terraform modules that the original implementation had not encountered.

What did not

  • The documentation in the initial release was written by engineers, for engineers. The first three external adopters all came back with questions that a better deployment guide would have answered. We spent a week rewriting the deployment documentation after the release, which should have been done before it.
  • We did not build in a way to report on the value the solution was delivering. The security team knew the solution was working because alert fatigue decreased and their on-call rotation became more manageable, but they could not produce a quantified metric for leadership. This matters when it comes time to justify the engineering hours that go into maintaining any internal security tooling.

What I would do differently

I would make the open-source case to the original customer at the start of the engagement, not after delivery. The customer was initially uncertain: they had paid for the solution and were not sure they wanted to give it away. Working through that conversation retrospectively, after we had already built something, added friction.

In hindsight, the customer’s hesitation was about ownership, not confidentiality. What resolved it was reframing: open-sourcing the implementation did not give competitors access to the customer’s configuration, architecture, or security posture. It gave other organizations access to the generic tooling pattern. Those are different things, and making the distinction clearly from the beginning would have shortened the open-source conversation by several weeks.

Outcome

The repository remained active for over two years. The original customer’s security team merged twelve external pull requests in the first year, improvements and bug fixes that they did not have to build themselves.

The engagement established a pattern that I have used in similar situations since: when a customer’s problem is sufficiently generic, and when the solution is in the tooling rather than in the configuration, an open-source approach serves the customer better than a proprietary one. Proprietary tooling requires the customer to maintain it in isolation. Open-source tooling creates a community that maintains it together.

The financial services firm that started this is now on its third major version of the solution. It still runs in production. The cost of maintaining it is shared across every organization that contributes to the repository.