For eligible findings, qrie can apply the fix in your AWS account with a single click. This page explains how the flow works, what gets stored, and how to undo a remediation if anything goes wrong.
- Apply Fix appears on an open finding when its policy supports autoremediation.
- Clicking it runs an assessment: qrie re-reads the resource configuration directly from AWS, re-evaluates the policy, and lists the specific scenarios that apply (e.g., "S3 Block Public Access is not fully enabled"). If the resource is already compliant, the finding closes immediately.
- You review the scenarios, accept the liability waiver, and click Proceed.
- qrie snapshots the relevant pre-change state, then applies each scenario. If any scenario fails, qrie halts and reports which ones succeeded — the ones that did succeed remain applied (and can be rolled back).
- The dialog enters verifying mode and polls every 60 seconds. When the resource is compliant, the finding is closed automatically.
While the verification dialog is open — and after a partial failure — a Rollback button is available. It replays the snapshots in reverse, restoring the resource to its pre-remediation state.
Rollback can fail if the resource has been further modified between the remediation and the rollback (for example, by a person or another automation). The dialog reports per-scenario rollback outcomes.
Scenario classes in the policy module — no infrastructure work.| Policy | Risk | Status |
|---|---|---|
| S3BucketPublic | S3 Bucket Publicly Accessible | Shipped |
| KmsKeyRotationDisabled | KMS Key Rotation Disabled | Planned |
| S3BucketVersioningDisabled | S3 Bucket Versioning Disabled | Planned |
| S3BucketNonKmsEncrypted | S3 Bucket Not KMS-Encrypted | Planned |
| CloudtrailLogValidationDisabled | CloudTrail Log Validation Off | Planned |
| CloudtrailLoggingDisabled | CloudTrail Logging Stopped | Planned |
| Ec2Imdsv1Enabled | EC2 IMDSv1 Allowed | Planned |
| LambdaFunctionPublic | Lambda Function Public | Planned |
| IamAccessKeyUnused | IAM Access Key Unused | Planned |
| RdsPublicAccess | RDS Publicly Accessible | Planned |
Customer IAM permissions are required
Autoremediation issues AWS API calls against your customer accounts using the qrie cross-account role. The role's policy is extended with the minimum write actions each scenario needs — for example, s3:PutBucketPublicAccessBlock for the S3 public-access fix.
When qrie ships new remediable scenarios that need additional actions, the customer onboarding CloudFormation template is updated. Existing customers must re-run the bootstrap stack to pick up the new permissions, otherwise the affected remediations fail with AccessDenied.
Each remediation run creates a row in the qrie_remediations DynamoDB table, keyed by the finding it acted on. The row records which scenarios were applied, their pre-change snapshots, success/failure of each, and who initiated the run.
Snapshots stay server-side; the API surface returns scenario outcomes but not the raw snapshot data.
- Bulk remediation across many findings at once.
- Auto-apply (no-click) for low-risk policies on a schedule.
- Approval workflows (Slack / email / PagerDuty).
- LLM-based safety reasoning before remediation.
These are tracked in feature-proposals/ and prioritized by customer demand.