About ZuluSec

ZuluSec is an independent engineering practice for teams running real infrastructure, whether or not they have a security team of their own. The work covers assessing what you already have, hardening it, and building what is missing: security audits, zero-trust architecture, compliance hardening, platform engineering, and automation engineering. Naming what is wrong is the easy half of that work. Most of this practice is devoted to the harder half: fixing it and building it.

Twenty-five years of the same job

For more than twenty-five years the job has taken the same shape: go into someone else's environment, usually a regulated one, and make a general capability actually work there. That has meant federal and defense systems under accreditation, FDA-regulated manufacturing, healthcare, state government, and large multi-cloud enterprises. It has meant zero-trust networks and identity providers, cloud audit and logging pipelines, environments hardened to DISA STIG and CIS Benchmark standards, and infrastructure as code across AWS, Azure, GCP, and on-prem.

The part the industry does not sell

The distance between a capability that exists and a capability that works in your environment is where security lives. It is also the part the industry does not sell. Vendors sell platforms, not working deployments, and the result is a dashboard that goes green while the systems stay exactly as they were.

That deployment work went undone because it was expensive. The connecting work between a general product and one particular environment had to be written by hand every time, and that took a team, so organizations bought the product, skipped the deployment, and called it done. What has changed is the cost of that connecting work. Building tooling for a single environment used to be the expensive part of this job. Now it is the cheap part, and what is scarce is the judgment: knowing which check answers the question actually being asked, what a result means in this environment, and what to fix first.

Work you can check

What ties all of this together is that you can check the work. Every finding names the resource, the setting, and the evidence behind it, so you can verify the judgment rather than take it on trust. What runs against your environment is code: the same input produces the same result, a run that could not read something reports that gap instead of coming back clean, and the code is yours to keep. Two reference implementations are public: the AWS posture reference, whose pull requests, review rounds, and automated test runs (CI) show how the work is built, and the agent containment harness, which is the measurement tool itself.

That is what separates this from report-factory output. Findings arrive with why they matter and how to fix them, and hardening work arrives with the evidence that it held. That standard comes from years of receiving audits that were nothing but checklists with no judgment behind them. The tooling that collects the evidence is specified by a practitioner, written with AI assistance, and shipped with its tests and a review, which is how the work stays affordable without cutting corners. By default nothing from your environment goes to an AI model, and a human signs off on every deliverable.

The two reference implementations: AWS posture reference, which shows how the work is built, and agent containment harness, which is the measurement tool itself. Both are MIT licensed and readable without talking to anyone.

See the flagship audit