ScanTitan inventories the accounts you connect, then looks for the misconfigurations, over-permissive identities, exposed storage, workload vulnerabilities and Kubernetes risk that chain into a breach. Agentless and read-only, with the API response or policy behind each finding.
Orca: 32% of cloud assets sit unmonitored, averaging 115 known vulnerabilities
ingress-nginx retired in March 2026 with no further security patches
Fortinet 2026: 88% of organisations run hybrid or multi-cloud
A cloud vulnerability scanner inventories the resources in the accounts you connect and asks two questions about each: is this software vulnerable, and is this configuration dangerous. The second is where a cloud misconfiguration scanner earns its place.
The split of duties comes from the shared responsibility model AWS, Microsoft and Google all publish. The provider is responsible for security of the cloud: data centres, hardware, the hypervisor and managed service internals. The customer is responsible for security in the cloud: configuration, identity and access, network rules, data protection and their own code. How much falls to you depends on the service model, with more on your side for IaaS than for managed SaaS.
A public storage bucket has no CVE. An IAM role with a wildcard policy has no patch. A retired ingress controller has a CVE and no future fix. That is why configuration and vulnerability data belong in one assessment, and why the connections matter: a single medium finding is noise, while a public workload with a role that reads production data is an incident waiting for a date.
Shared responsibility, as published by each provider: AWS · Microsoft Azure · Google Cloud
These get marketed as one thing and they are not. One needs nothing from you and sees what an attacker sees; the other needs a read-only role and sees the control plane. Most teams want both, but a report that blends them without saying which produced a finding is one you cannot act on.
Access needed: none. You enter a domain. What it sees: public IPs, load balancers and edge services attached to your domains, exposed admin and database ports, anonymously readable storage endpoints, dangling DNS records, TLS posture, plus dynamic testing of the applications and APIs it finds. What it cannot see: anything not reachable from the internet: IAM, encryption, logging gaps, private resources, registries, cluster internals. It cannot prove an asset is yours either, so attribution is a best-effort match on domains and certificates.
Access needed: a read-only role you create: a cross-account IAM role in AWS, a reader application in Entra ID for Azure, or a viewer service account in GCP. What it sees: resource inventory for the accounts you connect, effective IAM permissions and trust chains, encryption and key policies, logging coverage, network rules, registry image vulnerabilities, Kubernetes configuration, and the paths that link them. What it cannot see: anything outside the connected accounts, activity inside a running process, application logic flaws, or regions you did not put in scope.
Connect a read-only role, get an inventory of the scoped accounts, then keep it under scheduled assessment.
A cross-account IAM role, an Entra ID reader application or a GCP viewer service account, scoped to the accounts you choose. No software runs in your VPC and no write permissions are requested.
Compute, storage, databases, serverless, networking, registries, clusters and their identities, enumerated per account and region, including regions that are enabled but unused.
Resources are evaluated against CIS Benchmarks, provider guidance and our own rules: public exposure, encryption, logging, reachability, key rotation and retention.
Package vulnerabilities from volume snapshots, container images from your registries, and Kubernetes control-plane, RBAC and workload settings. How each works is on the next tab.
Effective permissions are resolved across roles, policies, trust relationships and service accounts, then combined with network reachability to show which chains reach data.
Findings ranked by exploitability and blast radius, each with the console step, CLI command or Terraform change that closes it, plus a re-check.
A fintech shipping a REST API imported its OpenAPI spec and, on the first authenticated scan, found a BOLA flaw on the /accounts/{id} endpoint that returned any user’s balance by changing the ID. Fixed and re-verified in a day, before any bug bounty report.
Workloads: Instead of an agent, ScanTitan takes a read-only volume snapshot through the provider’s API and analyses the file system out of band to build a package inventory, then matches it against vulnerability data. Nothing is installed on the instance. Encrypted volumes require access to the relevant KMS or Key Vault key, which you grant explicitly.
Containers: Images are read from ECR, ACR, Artifact Registry or a self-hosted registry with pull permission, then their layers analysed for OS and library vulnerabilities, secrets, root users and base image age.
Kubernetes: Clusters are read through the provider API for control-plane configuration, and through a read-only service account for RBAC bindings, workload manifests and admission configuration.
The honest limits, snapshot analysis is point-in-time, so it will not catch a process that started and stopped between scans. It does not see memory, live sessions or runtime behaviour, which is the job of an agent or EDR, and it can only assess what the granted role can read.
A raw posture feed produces thousands of findings on day one, which is how teams learn to ignore it. Ranking is by exploitability and blast radius, each finding carries the fix and the guardrail that stops it recurring, and a re-check confirms it.
Drift is the real enemy, a cloud account is never finished. Scheduled assessment catches the bucket that went public at 4pm on a Friday, not the quarterly review that finds it in March.
The damaging cloud incidents are rarely exotic: storage left open, an identity with more power than anyone realised, a management interface exposed to the internet, a secret in a repository. Each is boring on its own, which is why they survive in production.
| Attack path | What it looks like in practice |
|---|---|
| Public object storage | Data exposure S3 Block Public Access is on by default for new buckets since April 2023, but older buckets, a policy with Principal "*", or an object-level ACL can still expose data. Azure blob containers and GCS buckets granted to allUsers create similar exposure. |
| Over-permissive identity | Privilege escalation Wildcard actions, roles assumable by external accounts or unprotected CI runners, access keys that never rotate, and service accounts with project-wide roles. |
| Exposed management surface | Remote takeover Kubernetes API servers, kubelets, etcd, registries, databases, and RDP or SSH exposed to 0.0.0.0/0, especially in regions or environments with limited monitoring. |
| Secrets in code and config | Credential theft Keys stored in Terraform state, environment variables, container images, instance user data, or public repositories can expose cloud accounts and workloads. |
| Unpatched, unmonitored workloads | Known CVEs Instances, container images, and functions running vulnerable packages can remain exposed when assets fall outside regular inventory, monitoring, or patch-management coverage. |
| Missing logging and encryption | Invisible incident CloudTrail, Azure Activity Logs, or Google Cloud Audit Logs may be disabled or incomplete, while weak encryption controls or snapshots shared more broadly than intended can increase the impact of an incident. |
Sources: Orca Security (asset monitoring), Fortinet 2026 (multi-cloud adoption), AWS (S3 defaults). Findings map to CIS Benchmark controls and CVE identifiers rather than a private severity scale.
Each provider names the same mistake differently, and 88% of organisations run more than one. Findings are normalised so a public bucket reads the same everywhere, while the fix speaks each platform’s language.
S3 exposure and Block Public Access state, IAM roles, policies and key age, EC2 and EBS posture including instance metadata settings, RDS and snapshot sharing, Lambda permissions, ECR image vulnerabilities, EKS and RBAC configuration, security groups and CloudTrail coverage.
Storage and blob anonymous access, Entra ID roles and service principals, managed identity scope, Key Vault policies, NSG rules open to the internet, SQL and Cosmos DB exposure, ACR image vulnerabilities, AKS hardening, diagnostic settings.
Cloud Storage granted to allUsers or allAuthenticatedUsers, IAM bindings and primitive roles, service account keys and impersonation chains, firewall rules, Compute Engine and Cloud SQL exposure, Artifact Registry vulnerabilities, GKE and workload identity configuration.
Posture, identity and workloads in one assessment. Kubernetes, IaC and application testing have their own sections below.
Scheduled posture assessment against CIS Benchmarks and provider guidance: exposure, encryption, logging, network rules and drift.
S3 buckets, Azure blob containers and GCS buckets tested for anonymous read, listing and write, with Block Public Access state, ACLs, encryption and logging.
Resolves what an identity can do across policies, roles, trust relationships and service accounts: wildcards, external trust, stale keys, unused privilege.
Combines exposure, identity and data sensitivity into chains: internet-facing workload, to a role, to a bucket with customer data. Toxic combinations, not isolated alerts.
Images pulled from ECR, ACR, Artifact Registry and self-hosted registries, with layers analysed for OS and library vulnerabilities, base image age, root users and secrets.
Findings mapped to CIS Benchmarks and rolled up against PCI DSS, SOC 2, ISO 27001 and NIST, with exportable evidence.
In March 2025 the IngressNightmare chain in ingress-nginx, headlined by CVE-2025-1974 at CVSS 9.8, allowed unauthenticated remote code execution and full cluster takeover in a component whose default install reads Secrets cluster-wide.
In November 2025 the project’s retirement was announced, and that deadline passed in March 2026: no further releases, no bug fixes, no security patches. Further high-severity issues, including CVE-2026-24512 and CVE-2026-3288, landed in the months before maintenance ended. Nothing breaks when software retires, which is the problem: the cluster keeps working, nothing forces the migration, and exposure compounds quietly.
Sources: Kubernetes project announcements · CVE-2025-1974 (NVD)
Most misconfigurations were written somewhere first. Scanning Terraform, CloudFormation, Bicep and Helm before apply is how you stop fixing the same finding every quarter, and how you find the module producing it everywhere.
# FAIL · CLOUD-S3-001 · public access not blocked
resource "aws_s3_bucket_public_access_block" "data" {
bucket = aws_s3_bucket.data.id
block_public_acls = false
block_public_policy = false
ignore_public_acls = false
restrict_public_buckets = false
}
# PASS · same resource, all four controls set to true
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = trueThe rule that fails a pull request is the rule that evaluates production, so there is no gap between pipeline and assessment.
Plan and module scanning
Azure deployments
Kubernetes as code
Templates and stacks
GitHub, GitLab, Bitbucket
Console changes vs code
CSPM asks whether the environment is configured safely and reads the control plane. Cloud DAST, often performed with a website vulnerability scanner, asks whether the running application itself is safe. A well-configured account can still serve an application with broken access control, and a solid application can still sit next to a public bucket holding its backups.
Configuration, identity and exposure across connected accounts. Agentless and control-plane deep.
Live testing of the apps and APIs your cloud serves, using the web application scanner on the parent hub.
Written for the engineer applying the change and the executive signing off the risk. Exportable as PDF, JSON and CSV, or streamed to your SIEM.
Discovered resources per account, subscription and project, with owners and regions.
The chains that reach data, ordered by exploitability and blast radius.
The API response, policy document or manifest behind the finding, with its timestamp and method.
Connecting a scanner to a production account deserves specifics: what the connection is, what we store, and how you take it back.
You create and hold the role: a cross-account IAM role with an external ID in AWS, a reader application in Entra ID, or a viewer service account in GCP. Permissions are read-only, scoped to the accounts you select, and revocable from your own console.
Role identifiers, tokens and registry credentials are encrypted in transit and at rest in a managed secrets store, used only for your workspace, and removed when the connection is deleted.
Access is role-based. Support staff cannot read stored secrets, and troubleshooting access requires your request and is recorded in an audit trail you can review.
Findings, snapshot metadata and reports are retained for the period set in your workspace. You can delete an assessment, an account or your whole history at any time, which also removes the evidence and exports.
External scanning originates from a published list of static IP ranges you can allowlist. API request rates are limited by default and configurable, staying within provider throttling limits.
Scan data can be processed and stored in the region you select. The current region list and subprocessor register are available on request.
Onboard an AWS Organization, an Azure management group or a GCP folder in one step, and route findings to the resource owner.
curl -X POST https://api.scantitan.com/v1/cloud-scans \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"provider": "aws",
"scope": "organization",
"include": ["config","iam","workloads","k8s"],
"notify": ["slack","jira"]
}'
# Response
{
"scan_id": "cl_9f31a7",
"accounts_in_scope": 27,
"status": "running"
}Findings arrive tagged with the account, environment and owner, so nothing waits for someone to log into another dashboard.
Organizations, management groups, folders
Tickets with owner routing
Any tool via JSON
Exposure alerts
Last reviewed 5 August 2026. Reviewed every 90 days.
June 2026
Clusters are flagged when they run components past end of maintenance, starting with ingress-nginx after its March 2026 retirement.
May 2026
Paths now chain across account and provider boundaries, so a role that assumes into another account is one path rather than three findings.
Open-source auditors are excellent and free, and native tools are already in your account. The table records what each project’s documentation describes, not our opinion of it.
| Feature | ScanTitan | Prowler | ScoutSuite | Cloud-native tools |
|---|---|---|---|---|
| Multi-cloud misconfiguration checks | ✓ | ✓ | ✓ | Per provider |
| CIS Benchmark and compliance mapping | ✓ | ✓ | Partial | ✓ |
| Identity and effective-permission analysis | ✓ | Partial | Partial | Partial |
| Attack path analysis | ✓ | Not documented | Not documented | Partial |
| Container image scanning | ✓ | Not documented | Not documented | ✓ |
| Kubernetes configuration assessment | ✓ | Partial | Not documented | Partial |
| IaC scanning in the pipeline | ✓ | Not documented | Not documented | Partial |
| External exposure scan and cloud DAST | ✓ | Not documented | Not documented | Not documented |
| Runs without engineering time to operate | ✓ | Self-hosted | Self-hosted | Tuning required |
| Entry point | Free assessment | Open source | Open source | Per-account pricing |
How to read this table: ✓ described in official documentation. Partial documented limits, one provider only, or a specific tier. Self-hosted you run and maintain it. Per provider exists separately in each cloud, not in one view. Not documented no description found in the sources below at review time, not a claim the tool cannot do it. “Cloud-native tools” summarises Security Hub and Inspector, Defender for Cloud and Security Command Center, which differ from one another.
Sources reviewed 5 August 2026: Prowler documentation · ScoutSuite repository · AWS Security Hub docs · Microsoft Defender for Cloud docs · Google Security Command Center docs.
Next scheduled review: November 2026. Spotted something out of date? Tell us and we will correct it.
It inventories the resources in the accounts you connect and checks them for two kinds of problem: software with known vulnerabilities, and unsafe configuration. Under the shared responsibility model, the provider secures the cloud itself while configuration, identity, data and your own code remain yours, which is the layer this scanner assesses.
Read-only and agentless. You create a cross-account IAM role with an external ID in AWS, a reader application in Entra ID, or a viewer service account in GCP. Nothing is installed in your VPC and no write or delete permissions are requested. Scope it to specific accounts and revoke it from your own console at any time.
For instances it takes a read-only volume snapshot through the provider API and analyses the file system out of band, so nothing is installed on the host; encrypted volumes need access to the relevant key, which you grant explicitly. Images are pulled from your registries and their layers analysed, and Kubernetes is read through the provider API and a read-only service account. Snapshot analysis is point-in-time and does not see memory or runtime behaviour, which needs an agent or EDR.
Yes, across all three providers. S3 Block Public Access has been on by default for new buckets since April 2023, but older buckets, a policy granting Principal "*", or object-level ACLs can still expose data. Buckets and containers are tested for anonymous read, listing and write, and the finding names the setting that makes it public.
The connected assessment reads the control plane through provider APIs with read-only permissions, respects rate limits, and does not create, modify or delete resources. API calls are metered by your provider and are usually a small cost. External testing is rate-limited and non-destructive by default.
Findings map to CIS Benchmarks for each provider and roll up against PCI DSS, SOC 2, ISO 27001 and NIST. You get control-by-control status, the evidence behind each pass or fail, and a history of when a control changed state.
Start with the external exposure scan, which needs nothing from you, then connect a read-only role to see what an attacker reaches after a first foothold.
OSCP · CISSP · 12 years in web application security · Author profile →