Test your AWS security posture locally: combining Kumo with Security Hub control simulations

Why local Security Hub testing matters before you deploy

Most AWS security teams do the hard part after deployment: they wait for Security Hub findings, then open tickets, then patch infrastructure that has already drifted. That works, but it is slow, noisy, and expensive when the same misconfiguration can be caught earlier in code review or CI. If you want a more reliable path, the combination of kumo and Security Hub control simulations gives you a practical way to test your cloud security assumptions locally, before a resource ever reaches AWS. It is especially useful for teams practicing security-oriented engineering discipline and trying to move from one-off audits to repeatable guardrails.

The key idea is simple: emulate the AWS resources you care about, intentionally misconfigure them, and confirm that your remediation code actually fixes the issue. That makes this a form of security debt prevention rather than security debt cleanup. In practice, you can use local testing to validate detection logic, infrastructure-as-code changes, and pipeline gates that stop insecure changes from merging. If you are already building CI discipline around platform change testing, this approach fits the same philosophy: treat security controls as software, then test them like software.

Security Hub’s AWS Foundational Security Best Practices standard is a strong target because it maps to common misconfigurations across IAM, logging, networking, storage, and compute. AWS describes it as continuously evaluating accounts and workloads against prescriptive best practices, which makes it ideal for simulating “should fail” states locally and confirming your fixes before deployment. In that sense, local emulation becomes your pre-flight checklist, not your source of truth. For teams that also manage compliance evidence, the workflow pairs nicely with regulatory readiness checklists and other control-mapping practices.

What kumo is and where it fits in a security workflow

A lightweight AWS emulator for development and CI

kumo is a lightweight AWS service emulator written in Go. It is designed to run as a local development server or in CI/CD tests, and it does so without authentication, which is exactly why it is fast to spin up in disposable environments. It supports a broad set of AWS services, including IAM, S3, CloudFormation, CloudTrail, Config, Security Lake, KMS, Secrets Manager, Lambda, SQS, SNS, EventBridge, DynamoDB, ECS, EKS, and more. For cloud security testing, that breadth matters because many Security Hub findings are not about a single API call, but about the interaction between infrastructure, logging, identity, and configuration.

One of kumo’s strengths is that it is a single binary with Docker support, so you can embed it in local workflows without a heavyweight runtime. The optional data persistence via KUMO_DATA_DIR is especially helpful when you want to reproduce a finding across multiple test phases, such as “create vulnerable state,” “apply remediation,” and “re-run compliance check.” If you have worked with broader observability or testing programs, this is similar in spirit to moving from manual verification to continuous observability. The difference is that your “observability” here is the reproducible behavior of AWS-like APIs and control outcomes.

Because kumo is AWS SDK v2 compatible, it is a natural fit for Go-based tooling, but it can still serve as a backend target for other languages if your tests point to local endpoints. That makes it valuable for platform teams, security engineers, and application developers who need a shared test fixture instead of separate security scripts. In modern DevSecOps setups, that shared fixture reduces mismatch between what developers believe is compliant and what security tooling later reports in the cloud. For teams already thinking in terms of cloud specialization, kumo is the kind of practical bridge between app code and platform controls.

Why emulation is different from static scanning

Static analysis and IaC scanning are useful, but they tell you what might be wrong in code, not what actually happens when a resource exists. Security Hub control simulations sit closer to runtime truth: they help you model a misconfigured bucket, a missing log destination, a weak IAM policy, or an over-permissive network edge. By combining emulation with control ideas, you can test the behavior of your remediation code against realistic service responses. That reduces the chance that a Terraform module, CloudFormation template, or CDK construct passes scan checks but still deploys into an insecure state because of defaults, ordering, or cross-resource dependencies.

This is the same reason teams use practical validation in other domains: if a product team only inspects a launch checklist, they may miss operational issues that appear after release. A better pattern is to test the live system in a controlled environment, then codify the lesson. You can see that logic in guides like platform integrity and case studies on resilient operations, where the winning teams build feedback loops instead of relying on assumptions. In cloud security, kumo gives you the feedback loop.

Mapping Security Hub controls into local tests

Choose controls that are easy to emulate and easy to break

Not every Security Hub control makes sense as a local simulation on day one. Start with controls that have clear resource states and deterministic remediation paths. Good early candidates include S3 public access controls, CloudTrail logging, KMS encryption settings, IAM policy restrictions, security group exposure, and Secrets Manager rotation or access patterns. These are the kinds of issues that lend themselves to “create bad state, detect bad state, fix bad state, confirm good state” workflows.

For example, Security Hub’s AWS Foundational Security Best Practices standard includes controls such as S3 bucket public access restrictions, CloudTrail configuration, and IAM policy checks. Those map well to simple, repeatable local tests because the failure modes are concrete. You can create a bucket with permissive access, assert that your validation logic flags it, then apply your IaC change and confirm the flag disappears. That gives you a strong baseline before moving on to more complex services like ECS, EKS, API Gateway, or Config. If you want to think more broadly about risk prioritization, the approach is similar to supply-chain threat analysis: start with the highest-probability, highest-impact issues first.

Model controls as test cases, not just findings

The most useful local workflow is not “does Security Hub say this is bad?” but “does my code prevent the bad state?” That means each control becomes a test case with three parts: a resource definition, a failure assertion, and a remediation assertion. For example, a test can create an S3 bucket with public read access in a local emulation environment, check that a rule engine or compliance script reports a finding, and then validate that your Terraform change removes the problem. The result is a security regression test, not merely a static check.

This mindset helps teams avoid shallow compliance theater. Instead of producing a report that says “compliant at scan time,” you are proving that your infrastructure definitions can withstand intentional misuse. The same principle appears in data and content systems, where teams must protect integrity across pipelines and outputs, as discussed in data publishing workflows and migration best practices. In security engineering, the equivalent is proving that the system remains compliant even after iterative change.

Use a control matrix to prioritize your first 10 simulations

A practical way to start is with a small matrix: service, misconfiguration, expected signal, and remediation. This keeps the first phase focused and helps teams avoid the trap of trying to emulate every Security Hub control at once. Below is a sample comparison of high-value test targets that are easy to automate and useful in CI.

If you want to build around a narrower security domain first, the same prioritization logic shows up in fleet and IoT security and sensor-based early warning systems: identify the failure modes that matter most, then harden those paths first. Security testing should be selective, not theatrical.

Designing local simulations with kumo

Run kumo as a disposable service in development

In the simplest setup, you run kumo locally or in Docker, point your AWS SDK clients or IaC test harness at the emulator endpoint, and create test resources with intentionally insecure settings. Because kumo does not require authentication, it is well-suited to ephemeral CI jobs and developer laptops. If you enable persistence, you can preserve state between steps, which is helpful when a remediation needs to alter an existing resource rather than build a new one. That combination makes kumo a good foundation for both unit-level policy tests and higher-level integration checks.

A strong pattern is to define a “security fixture” directory in your repo. That directory contains sample CloudFormation or Terraform snippets, a test harness, and expected failure snapshots. Developers can run the same suite locally that CI runs in the pipeline, which dramatically cuts the feedback time between a bad change and a fix. This is the same operating principle used in workflows like live-coverage iteration and collaborative release processes: the faster the loop, the less likely errors survive until launch.

Emulate the dependency chain, not only the resource

A common mistake is to test just one resource in isolation, such as a bucket or a role, and assume the entire control is covered. Many Security Hub findings depend on relationships: a role attached to a service, a log stream targeting a destination, a security group linked to an instance, or encryption settings inherited through a service configuration. Your local simulations should reproduce those dependencies because that is where many IaC regressions hide. A template that looks secure in isolation may still drift when another module changes a default or a resource is recreated in a different order.

Think of it like testing a product ecosystem rather than a single device. If one component is secure but its integration points are not, the real-world risk remains. That is why guides about integrated systems, such as software-and-hardware collaboration or integrated operations, are relevant to security engineering too: outcomes depend on the interactions. In AWS, the interaction surface is often larger than the resource itself.

Capture expected failures as code

The strongest local security tests assert both positive and negative outcomes. A negative assertion confirms that a vulnerable state is detected, while a positive assertion confirms that the remediation removes the condition. You can encode these expectations with your preferred test framework, or as policy checks in a pipeline step. If your team uses Open Policy Agent, custom scripts, or a cloud compliance engine, the important thing is to version the expected result right alongside the infrastructure code. That turns a verbal security requirement into an executable contract.

Pro tip: the best local cloud security tests are not the ones that prove your environment is safe today; they are the ones that prove your remediation still works after the next refactor, dependency upgrade, or module reuse.

Validating IaC remediation with repeatable tests

Test the fix, not just the finding

Once you can reproduce a control failure locally, the real value comes from testing the fix. For IaC, that means a developer changes the Terraform module, CloudFormation template, or CDK construct, then reruns the same simulation to confirm the finding disappears. This is far more trustworthy than relying on a diff review or hoping a generic scanner catches the issue. It also makes remediation measurable: you know exactly which test was red before and green after the change.

This matters because many security regressions happen through defaults. A module update might change a log destination, a bucket policy, a KMS alias, or a service principal without making the risk obvious in code review. A local test catches that immediately, which is why teams aiming for robust cloud security testing often pair policy checks with emulation. If you have ever seen operational surprises in other areas, such as product or market strategy shifts, the lesson is familiar; the stronger your validation loop, the less exposed you are to surprise outcomes. That logic is also why people track changes in platform updates and platform engineering practices.

Use failure snapshots for drift detection

Drift is not only an AWS production problem. It can appear in local fixtures too if your test assumptions change but the code does not. One practical solution is to save failure snapshots, expected control IDs, and resource attributes in version-controlled fixtures. When the underlying template changes, your CI job should compare the live emulated state against the expected posture. If the result diverges, the build fails, and the team is forced to decide whether the new state is an intentional change or an accidental regression.

That approach is especially useful for teams doing compliance-oriented delivery, because it creates an audit trail for why a control changed. It also helps bridge the gap between security and engineering, since both teams can see the exact resource state that triggered the finding. In many organizations, that shared artifact becomes more valuable than the test itself because it supports both investigation and evidence collection.

Practical remediation examples

Consider a simplified S3 case. Your test creates a bucket, disables public access protections, and confirms that the control simulation flags a violation. The remediation is then to enable block public access, tighten the bucket policy, and verify that the finding disappears. A similar pattern works for CloudTrail: create an account or trail state with logging disabled, confirm the violation, then turn on logging and validate that the control passes. For KMS, you can check whether storage or secret resources are created without encryption and confirm the build fails until encryption is enforced.

Once the pattern is stable, you can scale it to more complicated services. For example, you can create ECS task definitions with missing execution role protections or EKS resources with insecure defaults, then use local tests to confirm your IaC module applies the right settings. The important part is to keep each test sharply scoped and reproducible. If a test is too broad, it becomes brittle; if it is too narrow, it misses the real problem. Well-designed teams treat this balance the same way they handle other operational decisions, as seen in analyses like successful startup operating models and structured audit checklists.

Building CI security tests that prevent drift before deployment

Wire kumo into your pipeline

To make this useful at scale, run kumo in CI as part of a dedicated security test stage. The pipeline should spin up the emulator, deploy the test fixture, run the control checks, apply remediation, and rerun the checks. If the second pass still shows a violation, the job fails. Because kumo is lightweight and does not require authentication, it is a strong candidate for fast-running pull request validation. That can dramatically reduce the delay between code introduction and security feedback.

For best results, separate “fast checks” from “deeper checks.” Fast checks validate the most common controls on every pull request, while deeper tests run nightly or on release branches. This mirrors how mature engineering teams balance local verification and broader environment coverage. It is also similar to continuous benchmarking or real-time anomaly detection: you want near-instant alerts for the most likely failures and slower, more comprehensive checks for less frequent conditions.

Use CI gates to block insecure merges

A CI security gate should answer a simple question: does this change introduce or preserve a known insecure state? If yes, the merge should fail. The test output should identify the control ID, the resource, the expected fix, and the exact assertion that failed. That information makes it possible for the developer to resolve the issue without ping-ponging between teams. It also supports better review quality because the pipeline enforces the rule consistently rather than depending on reviewer memory.

Teams often underestimate how much drift originates in “safe-looking” changes. A small module refactor, a variable rename, or a provider version bump can alter defaults enough to break a security control. You can reduce this risk by making the CI test suite a required part of your release process, not an optional enhancement. The idea is very similar to strong operational habits in areas like on-demand insights pipelines and platform integrity workflows: consistent gates are what preserve quality when teams move quickly.

Make security tests actionable for developers

Security tests fail more often when they are hard to understand. If your pipeline merely says “control failed,” developers will waste time interpreting the result or asking the security team for clarification. Instead, render the failure in plain language and include the affected resource address, the misconfiguration, and the suggested remediation. If possible, link the failure to the IaC line or module that produced it. That turns a security finding into a normal engineering task.

This is where careful UX matters, even in internal developer tools. Teams respond better to clear, specific, and repetitive feedback than to abstract policy language. You can see the same principle in content and collaboration systems that emphasize smooth handoffs, such as collaborative workflows and fast editorial iteration. Security gates should feel like a helpful compiler, not a mystery machine.

How to operationalize local cloud security testing in a team

Create a control-to-test catalog

Once the first few tests are working, build a catalog that maps Security Hub control IDs to your local test cases. Include the service involved, the failure condition, the IaC resource, the remediation method, and the CI stage where the test runs. This gives the security team a way to see coverage at a glance and helps platform engineers identify control gaps. It also makes it easier to expand coverage without duplicating work.

A catalog also prevents “tribal knowledge” from becoming a maintenance risk. If one engineer knows how to reproduce a finding but the team does not, you have created a fragile process. The catalog should live in the repository, near the tests, so it evolves with the code. This is the same reason good teams keep operational playbooks close to implementation, whether they are optimizing research partnerships or codifying compliance checklists.

Define ownership across security and platform engineering

Local security testing works best when security and platform teams share ownership. Security should define the controls and expected outcomes, while platform engineering should own the IaC modules and pipeline execution. Developers then use the test suite as a normal feedback mechanism during feature work. That ownership model avoids the common failure mode where security writes a rule set that engineering never fully adopts.

To make this stick, agree on what “done” means for a security control. For example, a control may be considered complete only when the test exists, the remediation path is documented, and the CI gate is enabled. This definition transforms security from an after-the-fact review into part of the delivery standard. It is a useful pattern for teams adopting cloud specialization because it gives engineers a clear path from infrastructure changes to validated outcomes.

Measure success with drift reduction, not just finding counts

Many security programs track the number of findings, but that can be misleading. A better metric for this workflow is drift reduction: how often the pipeline catches insecure changes before deployment, and how many production findings are prevented by local tests. You can also track mean time to remediation for a failed control and the percentage of critical controls covered by test cases. Those metrics tell you whether your program is actually improving or just generating more data.

This is especially important in fast-moving teams where growth can hide technical debt. When release velocity is high, hidden problems tend to accumulate behind the scenes. The same caution appears in security debt scanning discussions: speed without guardrails is how posture decays. By focusing on drift prevention, you keep the team’s attention on the stability of the security baseline rather than on the raw count of alerts.

Reference workflow: from insecure state to trusted release

Step 1: Start with a control you can break deliberately

Pick one control, such as public S3 access or missing CloudTrail logs, and build a local fixture that creates the failure state. Make sure the test is deterministic and that the failure is clearly visible in output or assertions. If your fixture is hard to reproduce, it is not ready for CI. Keep it small enough that one developer can understand it in a single sitting.

Step 2: Apply IaC remediation and rerun the simulation

Modify the infrastructure code to correct the misconfiguration, then run the same test again. The test should now pass, and the result should be obvious to anyone reading the logs. If the remediation works only in one environment or only with a specific order of operations, that is a signal that the fix is incomplete. Your goal is a durable fix, not a one-off green build.

Step 3: Promote the test into CI and protect the branch

Once the test is reliable, wire it into pull request validation and enforce it as a branch protection requirement. Document which controls it covers and what developers should do if it fails. Then expand the catalog one control at a time until you have coverage for the most important controls in your architecture. Over time, this becomes one of the most valuable layers in your cloud security testing strategy because it prevents insecure drift before deployment rather than after an incident.

Pro tip: the highest-return CI security tests are the ones that break real-world defaults, not contrived edge cases. If a control is common in Security Hub and common in your architecture, test it early.

Frequently asked questions

Conclusion: make security posture testable before it becomes production risk

The real value of combining kumo with Security Hub control simulations is not just speed, it is confidence. You move from hoping that infrastructure code is secure to proving that your remediation actually works against a realistic AWS-like environment. That shift is powerful for developers, platform engineers, and security teams because it transforms cloud security into something you can test, automate, and enforce continuously.

If you build the workflow well, you get three outcomes at once: better IaC validation, stronger CI security tests, and fewer surprises after deployment. You also create a much cleaner line of sight between policy, code, and runtime posture, which is what mature cloud security testing should look like. For teams that want to keep improving, it is worth exploring adjacent topics like security debt reduction, continuous observability, and compliance-by-design as part of the same operating model.

Related Reading

• Why “Record Growth” Can Hide Security Debt - A useful companion for understanding how fast delivery can mask posture regressions.
• From Manual Research to Continuous Observability - Shows how to turn repeatable checks into ongoing operational insight.
• Regulatory Readiness for CDS - Practical compliance checklists that pair well with control testing programs.
• From IT Generalist to Cloud Specialist - A roadmap that helps platform engineers build deeper AWS delivery skills.
• Malicious SDKs and Fraudulent Partners - A reminder that security posture includes supply-chain risk as well as cloud configuration.