Cloud teams can cover most of the posture, infrastructure as code and runtime checks a commercial platform performs with open source tools, but only if they pick tools that fit together and run them as carefully as any other privileged software. The open source cloud security field is crowded: some projects scan live accounts, some scan Terraform before it is applied, some watch syscalls on Kubernetes nodes and some enforce policy at admission. This guide maps the main projects by job, with licence, governance and what each needs to run, then covers how to deploy them safely, what they detect and when a commercial CNAPP is the better choice. It is written for cloud security engineers, platform teams and security architects in small and large organisations. Facts about each tool come from the projects' own repositories and documentation; check the current release before you rely on a detail.
Key takeaways
- Think in four layers. Account posture (Prowler, ScoutSuite, Cloud Custodian, Steampipe), infrastructure as code (Checkov, KICS, Trivy, Conftest), Kubernetes posture and admission (Kubescape, kube-bench, Kyverno, OPA) and runtime detection (Falco, Tetragon) answer different questions.
- Licences differ more than features. Most projects are Apache 2.0, but ScoutSuite is GPL-2.0 and Steampipe and TruffleHog are AGPL-3.0, which matters if you embed or offer them as a service.
- Scanners are privileged identities. A posture scanner holds read access to every account and a CI scanner sees pipeline secrets; scope both tightly, as the 2026 Trivy release compromise showed.
- Start read-only, enforce later. Run posture and IaC checks in report mode, agree baselines and suppressions with owners, then gate pipelines and admission.
- Open source shifts cost to people. You trade licence fees for integration, rule tuning, deduplication and upgrade work; budget engineering time before choosing.
What the tool does
No single open source project replaces a cloud-native application protection platform. Each covers one layer, and a working stack combines three or four. The table summarises the projects most teams evaluate. Governance status matters for long-term support: CNCF projects have neutral governance, while vendor-led projects depend on one company's priorities.
| Project | Layer | What it does | Licence | Governance |
|---|---|---|---|---|
| Prowler | Account posture | Read-only checks against AWS, Azure, Google Cloud, Kubernetes, Microsoft 365, GitHub, OCI and more, mapped to CIS, NIST, PCI DSS, ISO 27001, NIS2 and other frameworks | Apache 2.0 | Vendor-led (Prowler) |
| ScoutSuite | Account posture | Collects configuration through provider APIs and produces an offline HTML report; AWS, Azure and Google Cloud, others in alpha | GPL-2.0 | NCC Group; check recent activity before adopting |
| Cloud Custodian | Posture and remediation | YAML policies of resource, filters and actions; runs on a schedule or triggered by cloud events; can tag, stop or delete resources | Apache 2.0 | CNCF Incubating |
| Steampipe | Inventory and query | Exposes cloud and SaaS APIs as SQL tables through plugins for live queries | AGPL-3.0 | Vendor-led (Turbot) |
| Checkov | Infrastructure as code | Over 1,000 built-in policies for Terraform, OpenTofu, CloudFormation, Bicep, ARM, Kubernetes, Helm and CI workflow files, with graph-based checks | Apache 2.0 | Vendor-led (Palo Alto Networks, via Bridgecrew) |
| KICS | Infrastructure as code | Queries for Terraform, CloudFormation, Kubernetes, Ansible, Pulumi, Crossplane, CDK, OpenAPI and GitHub workflows | Apache 2.0 | Vendor-led (Checkmarx) |
| Trivy | IaC, images, SBOM | Misconfiguration, vulnerability, secret and licence scanning; absorbed tfsec | Apache 2.0 | Vendor-led (Aqua Security) |
| Conftest / OPA | Policy as code | Rego tests against structured configuration such as Terraform and Kubernetes manifests | See repository | OPA is a CNCF project |
| Kubescape | Kubernetes posture | Scans clusters, manifests, Helm charts and images against NSA-CISA, MITRE ATT&CK and CIS frameworks; operator adds continuous and eBPF runtime scanning | Apache 2.0 | CNCF Incubating |
| kube-bench | Kubernetes benchmark | Checks nodes and control plane against the CIS Kubernetes Benchmark, run as a Job | Apache 2.0 | Vendor-led (Aqua Security) |
| Kyverno | Kubernetes admission | Validate, mutate, generate and clean up resources; verify image signatures; background scans and policy reports | Apache 2.0 | CNCF Incubating |
| Falco | Runtime detection | Rule-based detection on Linux syscalls with container and Kubernetes metadata; plugins add CloudTrail, Kubernetes audit and Okta events | Apache 2.0 | CNCF Graduated |
| Tetragon | Runtime detection and enforcement | eBPF process, file and network observability with TracingPolicy, Kubernetes-aware, from the Cilium project | Apache 2.0 | Cilium project |
| TruffleHog | Secrets | Finds secrets in git, S3, GCS and container images and verifies whether they are live | AGPL-3.0 | Vendor-led (Truffle Security) |
tfsec now states that it "is now part of Trivy" and encourages users to move across; it remains available for the time being but should not be chosen for new deployments. For a single-tool deep dive see the Prowler and Cloud Posture Scanning Guide and the Trivy Guide.
Defender use cases
Account posture and compliance evidence
Prowler is the most common starting point because it covers many providers and maps findings to frameworks auditors recognise. Its repository lists 662 AWS, 191 Azure and 110 Google Cloud checks, with counts updated over time, and outputs including JSON-OCSF and SARIF. Use it for a baseline of misconfigurations such as public storage, logging gaps, unencrypted volumes and over-broad IAM. ScoutSuite gives a point-in-time snapshot with an offline HTML report, useful for assessments and consultancy work rather than continuous monitoring. Map findings to ATT&CK techniques defenders care about: T1530 Data from Cloud Storage, T1078.004 Cloud Accounts and T1552.005 Cloud Instance Metadata API. See the Cloud Misconfiguration Guide.
Automated guardrails and remediation
Cloud Custodian expresses rules as policies: a resource type, filters that select matches and actions such as tag, notify, stop or delete. Policies can run on a schedule against the existing estate or in an event mode that provisions a function triggered by CloudTrail events, so a public bucket or untagged instance is handled minutes after creation. This is the open source answer to "detect and fix", and it needs the strongest change control of any tool here because it writes to production.
Inventory and investigation queries
Steampipe maps provider and SaaS APIs to SQL tables, so an engineer can join EC2 instances to security groups or list every IAM user without access key rotation in one query. It suits ad hoc investigations and custom reporting. See the Cloud IAM Review Checklist.
Infrastructure as code before deployment
Checkov, KICS and trivy config scan Terraform, CloudFormation, Bicep, ARM, Kubernetes and Helm in pull requests, catching the misconfiguration before it exists. Checkov adds graph checks that reason about relationships between resources and scans CI files such as GitHub Actions workflows. Conftest lets you write organisation rules in Rego, for example mandatory tags or approved regions. See the Infrastructure as Code Security Guide and Policy-as-Code for Authorisation Guide.
Kubernetes posture and admission
kube-bench checks node and control plane settings against the CIS Kubernetes Benchmark; on managed services (EKS, GKE, AKS) it has platform-specific job manifests, and many control plane items are the provider's responsibility. Kubescape scans manifests and live clusters against NSA-CISA and MITRE frameworks. Kyverno then turns agreed rules into admission policies, for example blocking privileged pods (relevant to T1611 Escape to Host) or requiring signed images. See the Kubernetes Admission Control Guide.
Runtime detection
Falco watches syscalls and raises alerts from its rules, such as a shell spawned in a container or a write below a binary directory, enriched with pod and namespace. Its plugins add CloudTrail, Kubernetes audit and Okta as event sources, but Falco does not correlate across sources, so correlation belongs in your SIEM. Tetragon offers eBPF observability of process execution, file and network activity with policies written as TracingPolicy resources, and supports runtime enforcement. See the Container Runtime Security Guide.
Deployment and safe use
Identity and permissions for scanners
- Posture scanners: Prowler's documentation asks for the AWS managed policies SecurityAudit and ViewOnlyAccess plus its additions policy; Google Cloud needs Viewer; Azure needs subscription roles and Entra Graph read permissions (Directory.Read.All, Policy.Read.All, UserAuthenticationMethod.Read.All). Use a dedicated role assumed through workload identity federation, not long-lived access keys.
- Remediation engines: give Cloud Custodian a separate role per policy pack with only the write actions it needs, and keep read-only scanning on a different identity.
- Kubernetes tools: run Kubescape and posture scans with a read-only ClusterRole; kube-bench needs host PID namespace and host paths, so run it as a short-lived Job and delete it afterwards.
- CI scanners: run IaC scanners in a job that has no deployment or publishing secrets. Every token in the job's environment is reachable by the scanner binary.
See the Cloud Workload Identity Guide and Cloud PAM and CIEM Guide.
Supply chain hygiene for the tools themselves
In March 2026 attackers rewrote Trivy's release tags to point at a malicious release. In the LiteLLM PyPI package breach, the poisoned scanner ran in a CI job that also held the project's PyPI publishing token, which was stolen and used to publish malicious versions. The same risk applies to every tool in this guide (T1195.002 Compromise Software Supply Chain). Pin GitHub Actions to commit SHAs and container images by digest, verify signatures where the project publishes them, mirror releases internally and update deliberately rather than pulling latest.
Phased rollout
- Inventory and scope: list accounts, subscriptions, projects and clusters; decide which layer you cover first (usually account posture).
- Baseline in report mode: run Prowler or ScoutSuite across all accounts and IaC scanners on main branches; do not fail builds yet.
- Triage and suppress with governance: agree which checks matter, record suppressions in code (
checkov:skip=<id>:<reason>, Kyverno exceptions) with an owner and expiry. - Gate new changes: fail pull requests on high and critical IaC findings for new code only; keep legacy findings in a backlog.
- Admission in audit, then enforce: deploy Kyverno policies in audit mode, review policy reports for two to four weeks, then enforce per namespace.
- Remediate automatically, narrowly: run Cloud Custodian with
--dryrunfirst, then enable notify actions, then a small set of safe actions (tagging, removing public access) in non-production. - Runtime last: deploy Falco or Tetragon to a pilot node pool, tune noisy rules, then forward alerts to the SIEM.
Rollback: keep every policy in git so a bad rule is a revert; switch Kyverno policies back to audit, disable a Custodian policy's mode, or remove the Falco DaemonSet from a node pool. Never roll back by granting scanners broader permissions.
Detection and hardening value
Posture and IaC tools harden; runtime tools detect. The mapping shows where each layer fits against common frameworks.
| Layer | Example threats addressed | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| Account posture | T1530 Data from Cloud Storage, T1078.004 Cloud Accounts, T1580 Cloud Infrastructure Discovery | PR.PS-01, ID.RA-01, ID.AM-02 | CM-6, RA-5, CA-7 |
| Infrastructure as code | Misconfiguration before deployment, T1552.005 Cloud Instance Metadata API (IMDS settings) | PR.PS-01, PR.PS-06 | CM-6, SA-11 |
| Kubernetes admission | T1610 Deploy Container, T1611 Escape to Host | PR.PS-01, PR.AA-05 | CM-7, AC-6 |
| Runtime detection | Unexpected processes, container escape attempts, credential access on nodes | DE.CM-09 | SI-4, AU-6 |
| Secrets scanning | T1098.001 Additional Cloud Credentials abuse, leaked keys | ID.RA-01 | RA-5 |
The Capital One breach shows why both matter: an over-privileged firewall role and metadata credential theft were posture problems, and bulk reads from S3 went unnoticed until an outside report, which is a detection gap.
Metrics
- Coverage: percentage of accounts, subscriptions and clusters scanned in the last 24 hours (target 100%).
- Critical posture findings open: count and median age of critical findings such as public storage and admin users without MFA.
- IaC gate effectiveness: share of high findings caught in pull requests versus found later in live accounts.
- Suppression hygiene: number of suppressions without owner or past expiry (target zero).
- Runtime alert quality: proportion of Falco or Tetragon alerts closed as true positive or useful context, reviewed monthly.
Alternatives
The real choice is between an assembled open source stack, a commercial CNAPP, or the provider's native services (AWS Security Hub and Config, Microsoft Defender for Cloud, Google Security Command Center).
| Option | Strengths | Trade-offs | Fits |
|---|---|---|---|
| Open source stack | No licence fee, transparent rules, portable across clouds, custom checks in code | Integration, deduplication, dashboards, upgrades and on-call are yours; no unified attack path analysis | Engineering-led teams, startups, consultancies, regulated teams that need inspectable rules |
| Provider native services | Deep integration, no extra infrastructure, managed rule updates | One cloud per console, costs scale with resources, limited IaC and Kubernetes depth | Single-cloud organisations |
| Commercial CNAPP | Correlated posture, identity, vulnerability and runtime with attack path context and support | Licence cost, vendor lock-in, agent or broad read access granted to a third party | Large multi-cloud estates with limited platform engineering capacity |
Small organisations: Prowler on a schedule plus Checkov or Trivy in CI covers most early risk for little cost. Large organisations: open source tools often sit alongside a CNAPP, for pipeline gating, custom policy and independent verification. Many commercial products embed these projects, so check what you are paying for. See the CNAPP Guide and Security Tool Consolidation Guide.
Common failure patterns
- Scanner with standing admin: a posture tool given AdministratorAccess or Owner "to avoid permission errors" becomes the most attractive identity in the estate.
- Secrets in the scan job: IaC or image scanners running in the same job as publishing or deployment tokens, the path used in the LiteLLM case.
- Unpinned tools: pulling
latestimages or moving tags for scanners, so a compromised release runs automatically. - Findings with no owner: thousands of posture findings exported to a spreadsheet, none routed to the team that owns the account.
- Enforcing on day one: admission policies or auto-remediation switched to enforce before baselining, breaking deployments and getting the tool removed.
- Abandoned projects: continuing to rely on a tool whose rules no longer track provider changes; review project activity yearly.
Practitioner checklist
- Choose one tool per layer (posture, IaC, Kubernetes, runtime) and document why.
- Check each licence (Apache 2.0, GPL-2.0, AGPL-3.0) against how you will use and distribute the tool.
- Give each scanner its own federated, read-only identity; separate any remediation identity.
- Pin tool versions by digest or commit SHA, mirror releases and remove publishing secrets from scan jobs.
- Run in report mode first, then gate new IaC changes on high and critical findings.
- Store suppressions in code with owner, reason and expiry, and review them quarterly.
- Move Kyverno or other admission policies from audit to enforce per namespace after review.
- Forward runtime and posture findings to the SIEM and route them to owning teams.
- Track coverage, critical finding age and suppression hygiene monthly.
Standards and references
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- Prowler: Prowler open source repository
- Cloud Custodian: Project repository
- Checkov: Project repository
- Falco: Event sources documentation
- Kubescape: Project repository
- Kyverno: Project repository
Related NHI Mgmt Group resources: Cloud Security Guide · CNAPP Guide · Open Source AppSec Tools Landscape Guide · Open Source SIEM and Detection Tools Landscape Guide · Kubernetes Security Guide