Hey everyone — wanted to share our team’s recent push to clean up our cloud security posture using Orca. We were drowning in critical and high-severity findings, and management needed a clear win. Over about two months, we managed to cut those critical findings by 60%. Here’s how we did it, step by step.
First, we stopped trying to boil the ocean. Instead of tackling everything, we used Orca’s prioritization to focus on the risks with the highest business impact. The “Orca Risk Score” and the context around each finding (like whether an asset was internet-facing or contained sensitive data) were huge. We sorted by “Ease of Exploitation” and “Business Impact” and just hammered the top 10.
Our biggest wins came from a few repeat patterns:
* **Public S3 buckets with sensitive data:** Orca flagged several buckets with logging data and even some backup dumps that were wide open. We wrote a quick script (run via a scheduled job) to check and enforce bucket policies. Here’s the core policy block we applied as a baseline:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::bucket-name/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
* **Unpatched, internet-facing containers:** Our EKS clusters had a few old workloads exposed via a public LoadBalancer. We used Orca’s visualization to trace the attack path, then:
1. Updated the base images in our Helm charts.
2. Moved those services behind an internal ingress controller.
3. Set up a simple CI gate to reject deployments with `service.type: LoadBalancer` unless tagged with an exception.
* **Over-permissive IAM roles:** Orca showed several roles with `"*"` actions on S3 and EC2 attached to dev instances. We created a Terraform module to replace them with scoped-down policies and ran it as part of our deployment pipeline.
The key was making it a daily habit. We set up a Slack channel where Orca posted new critical/high findings, and held a 15-minute daily sync to assign owners. We also integrated the Orca API with our Jira to auto-create tickets for certain findings, which helped with tracking.
It wasn’t perfect — we had some noise with findings in test environments, but Orca’s “Environment” tagging helped us filter those out after the first week. The biggest lesson? Don’t just look at the count of findings. Use the context Orca gives you to fix what matters most, automate the repeat offenders, and get everyone involved.
Hope this helps anyone in a similar crunch. Happy to share more details on the automation bits if useful.
-jk
Boiling the ocean is the biggest mistake teams make. Prioritizing by ease of exploitation and business impact is the only way to get momentum.
Your script for enforcing bucket policies is good, but if you're just running it on a schedule, you're still leaving a window open. You should be running that check in your CI/CD pipeline before any infrastructure deployment, and hook it into a chatops alert for any drift. Scheduled jobs mean you find out about the misconfiguration hours or days after it happens.
Beep boop. Show me the data.
That's a solid baseline policy. We found that just using a Deny on `s3:*` for all public principals was a bit too blunt for some of our shared assets. We had a couple of legitimate use cases where certain buckets needed to allow public `GetObject` for static website assets.
We ended up layering it with a more explicit policy. The core block was the same, but we added an explicit `Allow` for our CloudFront OAI right before the blanket `Deny`. This made the intent clear and prevented the deny from accidentally breaking the CDN.
Also, tagging those sensitive buckets with something like `DataClassification=Restricted` in Terraform made it way easier to write targeted scripts later.
Keep it simple.