Not another list of cloud misconfigurations. The three that expose your data, fixed and proven.
Connect an AWS account through a read-only role you create and control. WASViking reads the configuration of every resource, builds the graph of who reaches what, evaluates each control against the frameworks you report to, and turns the combinations that actually expose data into attack paths with the one fix that breaks them. No agent, no stored credential, no object ever read.
The overview a security leader opens in the morning. Fictional data.
A cloud scanner ends at a list of five hundred misconfigurations. Nobody can tell which three expose customer data.
Every cloud account fails controls. A public bucket without data in it is a hygiene item; a public bucket with customer exports, reachable through an instance with a known exploit and a role with wide permissions, is an incident waiting for a date. Tools that score each finding on its own cannot tell the two apart, so the team spends its week on the list and the real exposure stays open.
Cloud Security reads the account as a graph. It knows what each resource holds, who can reach it from where, and what else the platform already knows about the same workload. The score of a resource comes from that context, the attack path names the chain, and the fix is the step that breaks it.
One chain from the internet to customer data, and the one step that breaks it.
This is what an attack path looks like on the screen: every node is a stored fact about your account, every edge a reachability or permission the platform proved. The break option is ranked by lowest impact, and when the change lands, the next evaluation proves the path is gone.
Chain proven: an internet listener, a workload the host agent reports as exploitable, a role with every data action on the bucket, and the bucket that holds personal data. Break option, lowest impact: scope the role's data permission to the objects the application reads. Defined in code, so the fix lands in the repository and stays.
- Critical control failed70
- Reachable from the internet+12
- On an active attack path+6
- Personal data classified+6
- Business context, productionx1.15
Every point is a named factor from a stored fact. Nothing is assumed.
Inventory, controls, context, attack paths, changes and remediation, from one read-only role.
The connector reads configuration, never data. Every evaluation, score and recommendation is computed centrally from the facts it stored, so a finding always shows what was read, why it failed and how to fix it in console, CLI, Terraform or CloudFormation form.
An inventory that is also a graph
Compute, network, identity, data stores, logging and AI services across every enabled region, with their tags, owners and environments, and the relationships between them: what runs in which subnet, which role a workload assumes, which policy grants what on which bucket. A region you never enabled is never called.
Controls mapped to the frameworks you report to
Built-in controls carry their CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS 4.0.1 and NIST SP 800-53 references, grouped in policy packs you switch on. The compliance statement counts passed and failed per framework and leaves the word "compliant" to your assessor.
A score that explains itself
The Cloud Risk score of a resource, an account and the organization is a sum of named factors: control severity, internet exposure the platform proved, data classification, identity privilege, vulnerabilities from the host agent, business context. Every screen shows the factors, so nobody argues with a number they can read.
Contextual risks and attack paths
Rules combine facts that are harmless alone: a sensitive store reachable from the internet, a privilege escalation path to an administrator, a public workload with an exploitable package and a wide role. Each path lists its steps with their evidence, its blast radius and the break options ranked by impact.
Changes judged in seconds
With real-time events, a change in your account is evaluated as it happens and judged as risk introduced, removed or none, with the actor and the tool that made it and the findings it opened or closed. A change made outside your infrastructure-as-code on a resource defined in code reads as drift, with the file and line to fix at the source.
Remediation that resolves only when proven
A work item carries the plan, the owner, the ticket and the verification. Resolved is written by the next evaluation that proves the fix, never by hand. Optionally, a separate role with an allow-list of reversible actions lets WASViking apply a fix for you, under an approval you govern, with a rollback.
From a connected account to a proven fix, on a loop.
The cycle runs on a schedule for every account and in seconds for every change when real-time events are on. Hold a step to read it.
-
Connect
Register the account, deploy the read-only role from the template, validate. The permission coverage is measured, never assumed.
-
Inventory
Every resource, its configuration and its relationships, per region, with the history of each version kept.
-
Evaluate
Every control of the enabled packs over every applicable resource, with the evidence of what was read.
-
Prioritize
Exposure, data, identity and host vulnerabilities combine into the score, the contextual risks and the attack paths.
-
Fix and prove
The work item follows the fix; the next evaluation resolves it, breaks the path and writes the verified risk drop.
A permission you did not grant is never silence: the control reads Not evaluated and the coverage confidence of the account drops, so the number on the screen is always honest about what it saw.
The account is scored with everything the platform already knows about it.
Standalone cloud posture tools score an account from what the account reports. WASViking also runs your external attack surface discovery, your server agents and your code security on the same workloads, so a cloud finding is weighed with facts no cloud API returns.
Exposure is proven from the outside
A public address in the configuration is a potential exposure. The platform's own outside-in check confirms the listener answers, and only then does the resource read exposed, with the proof named on the score.
The host inside the instance counts
When the server agent of Infrastructure Defense runs on the instance, its vulnerabilities and its exploitation evidence join the cloud facts: an exploitable package on a workload that reaches data is a different risk from a clean one, and the path says so.
The fix lands in the code
When a connected repository defines the resource, the finding names the file and the line and the break option is marked long-term: fix it at the source and the drift never comes back.
Cloud risk you can put in front of a board, in numbers that were measured.
Finding counts do not survive a hard question. Measured risk does. Cloud Security reports the estate the way leadership reads it: the Cloud Risk score and its trend, the posture by domain, the attack paths broken, the exposure of sensitive data, and the verified drop after each fix.
Verified numbers, not activity metrics
A work item resolves when the next evaluation proves the fix and records what closed it. The executive PDF, the posture CSV and the evidence pack tell the same story for stakeholders, on a schedule or on demand.
Minutes from role to first score
Register the account, create the stack from the template, paste the role identifier, validate. The first full sync writes the inventory and the score within minutes; nothing to install, nothing to open.
Evidence an auditor recognizes
Every control carries its framework references and the evidence of what was read. Exceptions are requested, approved and dated with a compensating control. Posture Shares let a customer, an auditor or an investor see the cloud posture signed, without a seat on your portal.
When you want the fix applied for you, every write goes through four gates.
The assessment role never writes. A second, optional role carries only the reversible actions you tick, and nothing runs without a request, an approval under your policy and a record you can roll back.
Evidence mapped to the controls your auditor already asks about.
Cloud configuration, access control, logging and change management are named controls in every major framework. Cloud Security produces the per-resource, per-change record those controls expect, with the framework reference on each control.
| Framework | Control | What Cloud Security contributes |
|---|---|---|
| CIS AWS Foundations 5.0 | Identity, storage, logging, monitoring and networking sections | Built-in controls referenced to the benchmark sections, a pass and fail statement per account, and the failing resources named on each control |
| AWS Foundational Security Best Practices | Service-level controls for compute, data, identity, logging and network | The same controls carry the service reference, so the statement reads in the vocabulary your cloud team already uses |
| PCI DSS v4.0.1 | Req 1 network controls · Req 3 stored account data · Req 7 and 8 access · Req 10 logging and monitoring | Controls referenced to the requirements, a dated record of each exception with its approver, and the SLA preset for critical findings |
| NIST SP 800-53 Rev. 5 | AC access control · AU audit and accountability · CM configuration management · SC system and communications protection | Every control carries its control family reference; the change timeline is the configuration management record with the actor and the tool |
| ISO 27001:2022 | Annex A.5.23 cloud services · A.8.9 configuration management · A.8.16 monitoring | A live inventory with ownership context, configuration state with drift visible on every change, and the evidence pack an auditor can take away |
| LGPD · GDPR | Article 46 · Article 32 technical and organisational measures | Demonstrable, dated evidence that the stores holding personal data are inventoried, classified, not reachable from the internet, and measurably improving |
Read-only, in your account, revoked by you.
- The assessment role carries the AWS managed read-only audit policy plus a short supplement of describe actions; it can never write and never reads object contents, secret values, function code or database rows.
- The role trusts the WASViking account with a unique External ID generated for your account, as the AWS guidance on the confused deputy problem describes; sessions are temporary and the External ID rotates with a grace window.
- A missing permission is never silence: the control reads Not evaluated, the coverage confidence drops and the validation page lists the exact actions to add.
- Removing an account stops the reads at once; you delete the role on your side and nothing on ours can keep it.
See how Cloud Security compares.
A side-by-side comparison with what each platform delivers, where the fix goes further, and how to evaluate on your own account.