Wring Security

Wring Security is a strictly opt-in capability: it only exists on an AWS account after you install its own separate CloudFormation stack there — the Wring Security stack, with its own narrowly scoped read-only role. Without that stack, Wring cannot scan anything: the base connection reads cost data only, and an account without the stack simply doesn't participate.

Once you've installed the stack on an account, Wring can scan it for security and best-practice problems — public buckets, unencrypted volumes, missing CloudTrail coverage, over-permissive IAM — and score the result against the compliance frameworks your customers and auditors ask about.

The scan reads how your account is configured, plus the CloudTrail record of which principal called which AWS API. Nothing is changed, and the contents of your buckets, secrets, parameters, and logs stay unreadable to Wring by policy (see what the scan may read).

What you get

• Per-resource findings, not a wall of generic advice: the check that failed, the exact resource, why it matters, and how to fix it — including the command to run.
• A posture score for the account, so you can see movement over time rather than a single snapshot.
• Compliance framework scores across the frameworks below, from the same scan data.
• Scans on demand (a button in the dashboard) plus an automatic daily scan, so a regression shows up without anyone remembering to look.

Compliance frameworks

One scan, scored against nine frameworks:

How coverage is reported. A framework requirement is only scored when it maps to a check Wring actually implements — anything else is counted as not covered and shown in the header instead of being quietly graded as a pass. A framework score therefore says "of what can be assessed automatically, here's where you stand", never "you are compliant". The share that can be assessed grows as more checks ship, without any action from you.

Working through findings

• Fix and verify. After you remediate something, I fixed this — verify re-runs that single check live, in about half a minute, and updates the finding instead of making you wait for the next full scan.
• What's new since last time. Each scan is compared with the previous one: new findings are flagged for a day, and what you resolved is listed separately.
• Suppress what doesn't apply. A finding can be marked accepted risk, false positive, or snoozed for 30 days, always with a note. Suppressed findings drop out of your posture and framework scores, and the reasons stay on record — so an auditor can see what you decided and why.
• Export for auditors. A multi-framework PDF report, plus a CSV with your posture history and, if you want it, the suppression trail.

What the scan may read

Security checks need to see more of your account's configuration than pure cost reading does, so they ship as a separate opt-in CloudFormation stack with their own role — you enable it per account, review the permissions before launching it, and delete the stack to revoke.

The role can read configuration and audit metadata only — never the contents of your data:

And it carries an explicit deny for content: object data in S3, secrets, SSM parameters, and log events are unreachable — the same explicit-deny approach described in the access model. A scan can tell you a bucket is public; it cannot read what's in it.

Good to know

• Findings and scores are per AWS account, so an account you haven't enabled the stack for simply doesn't participate.
• Remediation stays yours. Wring shows the fix; your team applies it — the role has no write permission of any kind.
• Stuck on a finding? Ask Werner can explain it against your own scan data, or write to [email protected].