Cloud Security remediation and exceptions
How Cloud Security turns a finding or an attack path into a verified fix, how assisted remediation applies reversible fixes under your governance, and how exceptions and due dates work.
Cloud Security closes a finding only when the next evaluation proves the fix. This page follows a fix from the work item to the verification, the optional assisted remediation, and the exceptions and due dates around them.
Work items
A work item is built from a finding or from the break option of an attack path. It carries the fix from the catalog, the host patch when a vulnerability takes part, and the verification. The item moves through To do, In progress and In review; Resolved is written only by the next evaluation that proves the fix. A finding can also be sent to Jira or ServiceNow through the ticketing integration of the platform.
The fix in the format your team uses
| Form | AWS | Google Cloud | Azure |
|---|---|---|---|
| Console steps | Yes | Yes | Yes |
| CLI | Yes | Yes | Yes |
| Terraform | Yes | Yes | Yes |
| Preventive form | CloudFormation | The organization policy constraint that prevents the state | The Azure Policy definition that prevents the state |
Due dates
Each finding gets a due date from its risk band: 7 days for Critical, 30 for High, 90 for Medium and 180 for Low by default. Settings changes the days per band, and Posture Findings shows the owner, the status and the due date of each finding.
Assisted remediation
On AWS accounts and Google Cloud projects, with a second, separate identity and a governance policy you set, WASViking applies a short list of reversible fixes for you. The second identity is created from its own artifacts, with its own External ID and an allow-list of only the actions you tick.
| Provider | Actions |
|---|---|
| AWS | Block Public Access on a bucket, a world-open administration or database port, IMDSv2, a public database instance or snapshot, a stale access key, log file validation, key rotation, point-in-time recovery, scan on push |
| Google Cloud | Public access prevention and the public members of a bucket, a world-open firewall rule, the public address of a Cloud SQL instance, key rotation, a user-managed service account key |
| Azure | Not in this release; findings carry the guided plan |
Each action is requested on a work item with what changes and how it rolls back, and decided by an approver, or by the policy for a low impact action. It is executed through the second identity, verified by the next evaluation and kept as a record of who asked, who decided, what was read and what was written. A rollback writes the previous state back. The assessment identity stays read only throughout.
Exceptions
Accepting a risk, recording an exception, a false positive or a compensating control is always time bound, needs an approver, and reopens the finding when it expires. The exception governance lives in Policies & Controls. An accepted risk that expired and was not re-evaluated yet raises the Cloud Risk of the account until it is.