DEV Community: Ofir

Finding AWS Security Issues Is Easy. Fixing Them Is Where Things Get Complicated.

Ofir — Mon, 19 Oct 2026 10:32:38 +0000

Most AWS security tools are pretty good at telling you when something is misconfigured.

An open security group, an overly permissive IAM policy, a publicly accessible resource. These are all things we know how to detect.

But there's a part of the process that doesn't get nearly enough attention: what happens when someone actually tries to fix the problem?

Take something as common as a security group allowing SSH access from 0.0.0.0/0.

Your security scanner flags it, and the recommendation is to remove the rule.

Fair enough.

But what if that security group is attached to multiple production instances? What if someone still uses that connection for maintenance? Or what if the rule was created through Terraform, and removing it manually means it'll be back after the next deployment?

Suddenly, a simple security finding requires a much bigger investigation.

And that's assuming you even know which resources are affected.

You can start by checking the network interfaces associated with the security group:

aws ec2 describe-network-interfaces \
  --filters Name=group-id,Values=sg-0123456789abcdef0 \
  --query 'NetworkInterfaces[].{
    Instance:Attachment.InstanceId,
    PublicIP:Association.PublicIp,
    Description:Description
  }' \
  --output table

That gives you some useful context, but it doesn't answer everything.

Just because a resource uses a security group doesn't mean it depends on every rule in that group. And just because you haven't observed traffic doesn't mean that traffic isn't important.

There's also a difference between a security group allowing public access and a resource actually being reachable from the internet.

You need to look at routing, public IPs, load balancers, and the surrounding network configuration before making that determination.

This is where security investigations start taking time.

The interesting question isn't always how to fix a finding. It's how much you actually know before making the change.

That's something we've been thinking about while developing KULTARR.

We're building an AWS security investigation platform, and one of the areas we're focusing on is understanding the potential impact of remediation.

Not just identifying which resources are involved, but helping engineers understand what a proposed change might affect and where the available evidence is incomplete.

We also believe there's value in being able to say, "We don't have enough information to determine that."

It's a lot better than presenting a confident recommendation that turns out to be wrong.

KULTARR is still under development, and we're working through these problems as we build it.

We're curious how other teams approach this.

When you're dealing with security findings in production AWS environments, how much of the investigation happens inside your security tools, and how much still involves manually going through AWS?

https://kultarr.io

Investigating AWS Security Changes Shouldn't Be This Complicated

Ofir — Sun, 11 Oct 2026 09:56:48 +0000

If you've ever investigated an unexpected change in AWS, you probably know how much time can go into understanding a single event.

Take a security group rule allowing inbound SSH traffic from 0.0.0.0/0.

CloudTrail can show you the AuthorizeSecurityGroupIngress event, when it happened, and which IAM identity made the API call.

That's a starting point, but there's still quite a bit to investigate.

Was the change made manually or through automation? Which resources are associated with that security group? Are any of them actually reachable from the internet? What did the configuration look like before the change?

You might find yourself checking CloudTrail, EC2, AWS Config, and your deployment history just to piece together what happened.

And not every risky-looking configuration has the same impact. An overly permissive rule attached to a resource in a private subnet is a different situation from one exposing a production instance with a public IP.

That context matters when deciding what needs immediate attention.

I've been working on Kultarr, a product focused on making these kinds of AWS investigations easier.

The idea is to bring together the change, the identity behind it, the affected resources, and the relevant security context so engineers can understand what's happening without manually jumping between services.

Kultarr is still in development, and I'm currently refining how these investigations should work.

I'm interested in hearing how other engineers approach this.

When you need to investigate an unexpected IAM or security group change, what's your usual workflow? Do you use CloudTrail and AWS Config directly, or have you found a better way to connect the information?

More about what I'm building: https://kultarr.io

Building Kultarr: Making AWS Security Investigations Less Painful

Ofir — Thu, 08 Oct 2026 05:23:23 +0000

I've been building Kultarr. Here's where it's at.

I've spent a lot of time working with AWS, and one thing that always frustrated me was how much digging it takes to understand a security change.

You see something unusual, open CloudTrail, check IAM permissions, jump between services, and try to piece everything together.

That's one of the reasons I started building Kultarr.

The goal is to make AWS security investigations easier. Not just show another alert, but help explain who changed something, what happened, what it affected, and what can be done about it.

It's still in development, and there's a lot left to build and improve.

But I finally got the website to a point where I'm happy to share it.

https://kultarr.io

I'm curious to hear what you think, especially if you work with AWS.

What's something you wish AWS
made easier to investigate?

I’m building Kultarr to make AWS investigations less painful

Ofir — Sun, 27 Sep 2026 15:15:46 +0000

I’ve spent a lot of time working with AWS environments, and one thing that keeps coming up is how annoying it can be to understand what actually happened after something changes.

You notice a security group is suddenly open, an IAM policy was changed, a new access key appeared, or something in the environment just doesn’t look right. AWS has the information, but finding the answer usually means opening CloudTrail, checking IAM, jumping back to the resource, looking at permissions, timestamps, and trying to connect everything yourself.

That’s why I started building Kultarr.

The idea is pretty simple: when something changes in AWS, I want to make it easier to understand the full story behind it. What changed, who made the change, what permissions were used, which resource was affected, and what it looked like before.

I’m not trying to replace AWS tools. I actually want to use the data AWS already gives us and make the investigation around it much easier to follow.

Kultarr is still being built and there’s a lot I want to improve, but the direction is becoming much clearer.

I’d really like to hear from people who work with AWS regularly: when something unexpected happens in an account, what usually wastes the most time during the investigation?

https://kultarr.io

AWS access keys are easy to forget. I built a view to make them obvious.

Ofir — Thu, 24 Sep 2026 13:31:03 +0000

AWS access keys are really easy to create and really easy to forget about. A developer creates one for a script, a CI job uses another, someone leaves the company, a workload changes, and six months later the key is still active.

While building Kultarr, I wanted one place where I could quickly see which keys are active, which ones are older than 90 days, which have never been used, which belong to privileged identities, and whether a root account still has an access key.

So I built this view.

The main thing I wanted to avoid was another security dashboard that just throws numbers at you. A 300 day old read only key and a 300 day old administrator key are not the same problem, so the view also adds context around privilege, usage, age and status.

The idea is pretty simple: open one page and immediately understand what actually deserves attention.

Kultarr is still early and I’m building it around real AWS problems I’ve run into rather than trying to pack it with random features.

Curious how other teams handle this today. Do you rotate access keys automatically, use AWS Config/Security Hub, internal scripts, or still review them manually?

https://kultarr.io

Terraform drift is easy to detect. Understanding it is the hard part.

Ofir — Mon, 21 Sep 2026 17:04:38 +0000

Terraform can tell you that something changed, but that usually isn’t the full story. What I actually want to know is who changed it, whether it was changed manually in AWS, when it happened, which .tf file owns that resource, and whether there was a commit or pull request connected to it. That’s one of the things we’re working on in Kultarr: connecting the live AWS resource back to Terraform and GitHub, so you can see the AWS resource, the Terraform resource, the file, the repo, the commit, the pull request and the CloudTrail activity around the change. If AWS and Terraform no longer match, the useful part isn’t only knowing that drift exists, it’s understanding how it happened.

kultarr.io

AWS tells you something changed. Figuring out what actually happened is another story.

Ofir — Fri, 18 Sep 2026 23:08:30 +0000

I kept running into the same problem with AWS. The alert usually isn’t the hard part. The investigation is.

An IAM policy changes, a security group gets opened, or a role suddenly has permissions it didn’t have before. AWS gives you the event, but then you still need to figure out the story behind it. You check CloudTrail to see who made the change, IAM to understand the permissions, Terraform to see what should have been there, and GitHub to check whether it came from a normal deployment.

That context switching is what started bothering me. One change can be simple, but understanding whether it was expected, risky, or just part of a deployment can take much longer than the alert itself.

That’s one of the problems I started working on with Kultarr. The idea is to bring that context together: who made the change, what changed, what existed before, what was affected, and whether there’s related Terraform or GitHub activity.

I’m still working through a lot of the IAM edge cases, especially around understanding effective access without making assumptions.

For people working with AWS: when you investigate an unexpected change, which part usually takes you the most time?

kultarr.io