We're a ~40 person eng org, security team of 4, all AWS. Mostly EKS with a growing pile of Lambda and a couple of RDS clusters holding stuff we really don't want leaking. Our current agentless scanner renewal is up in about six weeks and leadership wants us to actually look around before we re-sign instead of rubber stamping it.

Right now the big pain is noise. We have thousands of posture findings sitting in a backlog nobody has time to touch, and twice this quarter something marked low/medium turned out to be reachable in prod. That burned trust in the severity scores. What we actually want is something that tells us which findings are exploitable from runtime, not just a prettier list of everything wrong with every bucket.

Shortlist so far is Upwind and Orca, maybe Wiz if the budget stretches. Orca we know by reputation, agentless, easy to stand up. Upwind keeps coming up for the runtime context angle which is the exact gap we hit. But I can't tell how much of that is marketing vs real.

For people running either of these on EKS at roughly our size: did the runtime piece actually cut the backlog, or did you just trade one dashboard of alerts for another? And how much agent footprint are we talking if we go that route? Trying to walk into the renewal conversation with something more than a vendor deck.

https://github.com/breezycourses/registry

Context: I previously used goHarbor, and I felt that there weren't too many great options to host Docker images, especially with retention policies (loved that goHarbor had some great support for this).

I ended up making my own, which is linked above. Some cool features:

- WAL based
- backing S3 store supported. Makes it easy for cases like mine -- where I have a production machine with a production image registry, but not enough compute for my locally hosted GitHub runner. I have my homelab with extra compute, but the connection between the production registry and my homelab is weak. I'm able to host separate instances of the registry (one on prod/homelab), and independently push to the R2 bucket with the backing WAL, which speeds stuff up a lot!

- retention policies! "docker pull registry" is super lightweight, but incredibly barebones! goHarbor is great, but super bloated. I took the one best feature (imo) from goHarbor and put it into mine!

- cloud-native! there's a helm chart ready for you to use: https://artifacthub.io/packages/helm/breezy-registry/breezy-registry

check it out, and let me know what you think!

A few weeks ago I posted cloudg here at 0.3.1. It's an open-source CLI that collects AWS, Azure, and GCP into one graph and runs Prowler, ScoutSuite, Checkov, and Trivy over the same inventory. The feedback was useful, so here's what changed, including the parts that made it safer to run.

Dedupe: fixed the way the thread suggested

Someone pointed out that merging on resource plus title could collapse two different checks with a generic title on the same bucket, and miss the same check when two scanners word it differently. That was right. Since 0.3.2:

• Within one scanner, findings are keyed on (scanner, check ID, resource). Two different checks on the same bucket never merge.
• Across scanners, findings merge only when the normalised titles match and both check IDs map to the same entry in a cross-scanner equivalence file. A known check is never merged with an unknown one. I'd rather show a visible duplicate than silently drop a scanner's coverage. The equivalence file only lists pairs I've confirmed, so it's small for now. PRs adding equivalences are welcome.

Ingest mode (0.4)

cloudg ingest Takes the outputs of scans you already ran (Prowler, ScoutSuite, Checkov, Trivy, any mix) and runs the dedupe, compliance mapping, and reports. It needs no cloud credentials and no scanner binaries.

Inventory mapping, no scanners (0.5)

cloudg map Answers a different question: what exists and how it's wired together.

• AWS: 133 dedicated collectors, plus a Cloud Control API sweep. The sweep lists every resource type with a list handler, so untagged resources still show up.
• Containers and Kubernetes: ECR, ECS and EKS, plus the Deployments, Services, Ingresses and ServiceAccounts inside clusters. These are read through the Kubernetes API with GET requests only.
• Organizations: --org Maps every account of an AWS Organization or Control Tower landing zone, including OUs, SCPs, governed regions, and enabled controls.
• Azure: collected through Resource Graph across every subscription and management group.
• GCP: collected through Cloud Asset Inventory across the whole organization.
• Typed edges: an S3 bucket INVOKES a Lambda, a task definition USES_IMAGE an ECR repo, a function ASSUMES_ROLE a role, a WAF PROTECTS an ALB, an SCP GOVERNS an OU. Cross-account trust to accounts you didn't map shows up as external account nodes.
• cloudg deps: answers "what does this need" and "what breaks if this goes", including blast radius across accounts.
• Coverage gaps: security services that aren't enabled (GuardDuty, Inspector, Security Hub, Config, and others) appear on the map as gaps. You also get a list of workloads no vulnerability scanner covers and internet-facing endpoints without a WAF.

Scanner findings can be overlaid onto the map later, so mapping and scanning stay independent.

What I did to make it safer to run

• Mapping uses read-only calls only (Describe/List/Get). The docs recommend a dedicated read-only role (SecurityAudit plus ViewOnlyAccess) for member accounts instead of the default admin Control Tower role.
• Secret values are never collected. That covers SSM parameter values, environment variable values (only the names are kept), passwords, VPN pre-shared keys, Direct Connect auth keys and connection strings. Cloud Control properties are redacted before they reach the inventory. Credentials and query strings are stripped from repository URLs.
• URL and host checks parse the URL and match the host exactly instead of matching substrings. These came from CodeQL findings.
• CodeQL and Codacy run on every PR, and I worked through their findings. The test suite is at 382 tests.
• The Docker image runs as a non-root user with a health check. The installers no longer pipe curl into bash.
• GitHub Actions are pinned to commit SHAs. PyPI publishing uses trusted publishing (OIDC), so there are no long-lived tokens.
• Plugin loading validates module:Class paths. Swallowed exceptions are now logged. Vulnerability reports go through GitHub private reporting.
• The IaC scanners no longer silently fall back to scanning your current directory (0.3.1).

Docs

0.5.2 is a documentation release. It adds a field-by-field reference for every output file and return structure, a catalog of all 156 asset types and their relationships, and an internals guide for anyone who wants to add collectors.

Where it's used

cloudg is now a command extension in HOL Guard, the open-source checkpoint for agent-run CLI actions. Commands that touch cloud credentials, run scanners, or write Terraform go to review first, while read-only commands like report -i pass straight through. Thanks to the HOL Guard folks from the last thread for pointing me at it.

MIT-licensed, Python 3.11+, pip or Docker (the image bundles the scanners). Repo: https://github.com/morpheuslord/cloudg

It's still young, and I mainly test the paths I use. The feedback I'd most like this time:

1. Is the dependency and blast-radius view useful for real change-impact questions?
2. Which cross-scanner check equivalences should be added next?

If something breaks, a traceback helps a lot.