Most teams don't lack findings. A first scan of a cloud account and its repositories easily returns several hundred: open ports, broad roles, unencrypted volumes, outdated packages, secrets in old commits. The hard part is deciding what to fix first, fixing it without breaking production, and knowing it stays fixed. This playbook sets out a way to do that, for teams without a large security department.
1. Why the findings list stalls
Findings are usually sorted by severity, and severity describes how bad a problem could be in general, not in your account. A public bucket with test images and a public database with customer records can carry the same rating. Faced with a long list where everything looks urgent, teams either work through it in order and spend weeks on low-risk items, or stop looking. Both leave the real exposure open.
The fix isn't a better severity score. It is adding the context that decides whether a finding can actually be used: is the resource reachable, what can it reach, and is it production?
2. Know what you have
- Connect every account, read-only. Gaps in coverage are where forgotten resources live. On AWS, a cross-account role with SecurityAudit and ViewOnlyAccess and an external ID; on Google Cloud, Viewer and Security Reviewer. See read-only AWS scanning.
- Label environments. Production, staging, development, sandbox. Account and folder names usually tell you; where one account mixes environments, a tag does. Production comes first in every ranking that follows.
- Connect the code too. Repositories and container registries tell you which packages and images run where, so a vulnerable dependency can be tied to the server it runs on.
3. Mark where the sensitive data is
You can't rank exposure without knowing what is worth protecting. Agree a small tag scheme, for example data-class=pii, payments and secrets, and apply it to buckets, databases and secret stores. Tags are cheap, auditable, and let a scanner know a store is sensitive without reading what is inside it. Start with the ten stores you would least like to see in the news; that covers most of the value.
4. Map exposure and attack paths
Build a picture of how things connect: what accepts traffic from the internet, which identity each workload runs as, and what each identity can read or change. With that, separate findings link up into routes. A typical one: an internet-facing instance, with a remotely exploitable CVE, still allowing IMDSv1, running as a role that can read a bucket tagged data-class=pii.
Each route has a weakest link: the step that is cheapest to change. Breaking it closes the route, and often others that share the step. See attack path analysis and why IMDSv2 closes so many paths.
5. Rank by reach, set deadlines by risk
Group findings into Issues (one problem, however many resources it affects) and rank them with a few questions:
| Priority | What it looks like | Fix within |
|---|---|---|
| Critical | On an attack path from the internet to sensitive data in production, or a known-exploited CVE on an exposed workload | 7 days |
| High | Internet-exposed in production without a path to sensitive data, or on a path in a non-production environment | 30 days |
| Medium | Internal-only weaknesses that would widen an attack: broad roles, missing encryption, logging gaps | 90 days |
| Low | Hygiene with no realistic route to harm, or sandboxes with nothing valuable | Next clean-up |
Suggested deadlines; set your own and write them down. For vulnerabilities, use exploitation signals (the CISA KEV catalog and EPSS scores) alongside exposure, as in how to prioritize CVEs. Findings that genuinely don't apply, such as a bucket that is public on purpose, should be accepted with a reason and a review date rather than left on the list.
6. Fix safely, in your own pipeline
- Fix in code where the resource is in code. If Terraform or CloudFormation manages the resource, change it there; a console fix will be undone by the next apply.
- Make dependency fixes pull requests. Version and base-image bumps go through your normal review and CI. Breaking upgrades need a person to decide, and should say so.
- Say what could break. Closing a port or narrowing a role can stop something working. Each fix should list what depends on the resource, and be rolled out to staging first where one exists.
- Keep a way back. Record the previous setting before changing it, so a bad change can be reverted in minutes.
7. Verify, and keep it fixed
A closed ticket isn't a closed risk. Rescan after every fix and close the Issue only when the scan confirms the change; reopen it automatically if the change is reverted. Then stop the problem coming back: account-wide defaults (S3 Block Public Access, IMDSv2 by default), organization policies that deny the risky setting, and checks in CI for infrastructure code. See public S3 buckets for a worked example.
8. Report progress leadership understands
A count of findings goes up whenever you connect another account, so it doesn't show progress. These do:
- Open attack paths to sensitive data, by environment, week over week.
- Critical and high Issues past their deadline.
- Median time from detection to verified fix, per priority.
- Share of accounts and repositories connected and scanned in the last day.
- Fixes verified this month, and Issues reopened after a fix.
The same numbers answer customers' security questionnaires and investors' due diligence, so it pays to keep them current.
9. Governance: access, approvals and audit
- Scanners get read-only access only. Write access for automated fixes, if you use it at all, is a separate role you can turn off.
- Every automated change needs a named approver, and is logged with the before and after.
- Third-party access is reviewed quarterly: who can assume which roles, from which accounts, with which external IDs.
- Audit logging (CloudTrail, Cloud Audit Logs) is on in every account and can't be turned off by workload roles.
- Secrets found in code are rotated, not just deleted from the latest commit.
10. The quarterly checklist
- Every cloud account, repository and registry is connected and scanned daily.
- Every account has its environment labelled.
- The most sensitive data stores are tagged.
- No open attack path to sensitive data in production.
- No critical Issue past its deadline; high Issues past deadline have an owner and a date.
- S3 Block Public Access is on at the account level everywhere, and IMDSv2 is required by default.
- Accepted findings have a reason and a review date.
- Fixes are verified by a rescan, and reopened Issues are investigated.
- Third-party roles and external IDs have been reviewed.
Alye Security covers the scanning, attack paths, ranking, fix plans, verification and reporting in this playbook, with read-only access from the first scan.