What it covers
| Area | What runs |
|---|---|
| Container images | A named image is pulled and scanned for OS package and language-library vulnerabilities, secrets, and misconfigurations. |
| Infrastructure-as-code | Terraform, Kubernetes manifests, Helm, Docker Compose, and Ansible files are checked for misconfigurations against real configuration files, not only templates. |
| Cloud configuration (static) | A small, hand-picked set of high-signal rules over your Terraform, Kubernetes YAML, Compose, and Dockerfiles, chosen from real incidents where a standard scanner's output buries the same finding under noise. This reads files only; it never opens a connection to a cloud account. |
| Container hardening | The live Docker daemon plus any Compose files found under the scanned path: privilege, capability, and isolation settings a container is actually running with, not just what a file declares. |
| Kubernetes (declared) | Manifests found in the scanned tree are judged for what they would ask a cluster to do: privileged pods, missing NetworkPolicy, admission-control gaps. |
| Kubernetes (live) | Where a live cluster is reachable, the same rule set is applied to what the API server actually admitted, plus checks a manifest cannot answer at all: effective RBAC resolved through every role binding and aggregation, whether an admission webhook is actually registered and what its failure policy is, and which pods are really running. |
| Cloud security posture (CSPM) | Where a cloud identity is configured, read-only checks across storage, compute, and identity configuration, and the account's audit-logging setup. |
| Cloud identity and entitlements (CIEM) | Not just what a policy document says, but what a principal can actually do once every attached policy, group membership, and boundary is resolved, using the cloud provider's own policy-simulation API where it is reachable, and reporting the result as approximate rather than authoritative where it is not. |
| Deployment-address consistency | For a project that records on-chain deployment addresses in more than one place (for instance a frontend's constants file and a separate deployment-records file), checks that a configured address actually has code deployed on the chain it claims, and that the same logical address is not recorded differently across the project's own config sources. |
| Hardening benchmarks | Reads what it can from an ordinary, non-root process against a recognized hardening baseline, and reports how many controls could even be answered from that vantage point alongside the failures, never presenting a short list of failures as if it were the whole benchmark. |
Read-only, by construction
Every cloud and container check here reads. Where a cloud identity is used, it is expected to carry read-only, audit-scoped permissions; nothing in this scan creates, modifies, or deletes a resource in your account, your cluster, or your registry. A check that would need a write is reported as a limitation, never worked around with a broader grant.
A third answer: unknown
A posture check has three possible answers, not two: configured badly, configured well, or could not be read: a permission that was refused, an API call that timed out, a privilege the scanning identity does not hold. The third is reported as
unknown, with the reason, and is never folded into a clean result. A short list of findings from an account or a host that could only partly be read is not the same thing as a short list of problems.
What it stops short of
- An image or a set of IaC files is judged as submitted; nothing here deploys, provisions, or otherwise changes a resource to verify a finding.
- Kubernetes manifest checks judge declared intent only. Objects applied by hand outside version control, a mutating admission webhook that rewrites a pod spec after submission, and drift from a live edit are all invisible to a manifest read: a clean manifest is not a clean cluster. The live-cluster checks close part of that gap, but only where a cluster is actually reachable and only for the objects they query.
- Container hardening reads the Docker runtime and Compose declarations; it does not cover Kubernetes-managed containers or a managed container service, and a clean result never implies a clean fleet.
- Cloud posture and entitlement checks answer only what the configured identity's permissions allow them to read; an unreadable resource or policy layer is reported as unknown, and an absent cloud identity means the whole family is skipped rather than reported clean.
- The entitlement check's strongest evidence comes from the cloud provider's own policy simulator, which the provider itself documents as not always matching live behavior in every respect (cross-account access and some condition types in particular); where that simulator cannot be reached, results fall back to a local approximation and are labeled as such.
- Hardening-benchmark checks run from an ordinary process, not a root one, so a meaningful share of a full benchmark is unanswerable from that vantage point. The report states how many controls it could actually read, not just how many failed.
- A named container-image registry that is not a public host is only reachable to an admin account, or on an installation running without authentication, the same restriction that applies to a local filesystem path elsewhere on the platform.
How to run it
- 1
Choose Container or IaC
Go to /scans and pick the Container tab for an image reference, or the IaC tab for infrastructure files. - 2
Provide the target
A container image reference (a public registry shorthand works for anyone; a named private registry host requires an admin account). An IaC path is a local directory (admin accounts only), or, in the same field, anhttps://repository URL, which any account can submit. - 3
Read the report
Findings are grouped by the checks above, each carrying its own pass, fail, or unknown status. See Reading a report for how severity and confidence are assigned.
Read before relying on any result
Sentinelleai is an automated security monitoring platform. Nothing it produces is an audit, a penetration test, a compliance opinion, or a guarantee that a system is secure. "No findings" means the tools that ran found nothing, never that nothing is there; anything a tool could not check is reported as unknown, not as clean. For decisions that carry real money or real liability, engage qualified professionals and treat Sentinelleai's output as their starting material.