Cloud Security Posture skill for Codex

A posture review is useful when it finds the handful of changes that actually reduce exposure — a public bucket, an admin role granted to everyone, an open SSH port — and gets them fixed, not when it prints a 500-line CIS report nobody reads. Audit read-only first; rank by real exposure; change only with confirmation.

Gate 0 — authorization and read-only credentials

• Confirm you are authorized to audit the account(s) and which account IDs/projects/ subscriptions are in scope.
• Use read-only credentials for the audit (AWS SecurityAudit/ReadOnlyAccess, GCP Security Reviewer/Viewer, Azure Reader). Never audit with admin credentials you could fat- finger a change with.
• These tools call cloud APIs — Codex’s sandbox usually needs network and the credentials configured; note when a step needs that.

Tooling

Tool	Scope	Use
Prowler	AWS, GCP, Azure, K8s	Hundreds of checks mapped to CIS/NIST; best default
ScoutSuite	AWS, GCP, Azure, more	Multi-cloud HTML report, good for exploration
AWS native	AWS	Security Hub, Config, IAM Access Analyzer, Trusted Advisor
GCP native	GCP	Security Command Center, Recommender
Azure native	Azure	Microsoft Defender for Cloud, Secure Score

# Prowler against AWS, CIS checks, to a report dir
prowler aws --compliance cis_3.0_aws -M html csv -o ./prowler-report
# Target specific high-value checks instead of everything
prowler aws --check-id s3_bucket_public_access ec2_securitygroup_allow_ingress_from_internet_to_any_port
# ScoutSuite
scout aws --report-dir ./scout-report

Prioritize — not all findings are exposures

A CIS report flags everything; triage by actual blast radius:

Priority	Finding class	Why
Critical	Public S3/GCS/Blob with data; DB/admin port open to 0.0.0.0/0; IAM admin to */all users; exposed access keys	Direct path to data/compromise
High	Over-broad IAM (*:*, iam:PassRole wide), no MFA on privileged users, unencrypted sensitive stores, public snapshots/AMIs	Escalation / exposure
Medium	Missing logging (CloudTrail/Config/flow logs), key rotation, default VPC use, no GuardDuty	Weakens detection/hygiene
Low	Tagging, naming, informational CIS items	Governance, not exposure

Fix top-down. One public bucket with customer data outranks fifty “enable tag policy” items.

The checks that matter most

• Public storage: any bucket/container readable or listable by the public. Verify both bucket policy/ACL and account-level public-access-block / org constraints.
• Network exposure: security groups / firewall rules allowing 0.0.0.0/0 to SSH (22), RDP (3389), databases (3306/5432/1433/27017), or “all ports”. Scope to known CIDRs.
• IAM over-permission: wildcards in actions/resources, policies attached to broad principals, unused roles with high privilege, long-lived access keys. Use IAM Access Analyzer / policy simulators to confirm effective access before trusting a static read.
• Encryption: unencrypted volumes/buckets/DBs/snapshots; keys not rotated.
• Logging/monitoring: CloudTrail (all regions) / audit logs on, immutable, and alerting.
• Identity: MFA on root/privileged, no root access keys, SSO over long-lived users.

Remediation — confirm before changing

Propose each fix with its blast radius, then apply only with explicit confirmation — tightening a security group or IAM policy can break production.

# Example: block public access on an S3 bucket (confirm it isn't intentionally public first)
aws s3api put-public-access-block --bucket <name> \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

• For IAM, prefer least privilege derived from actual usage (Access Analyzer “last accessed” / CloudTrail), not a guessed narrower policy that breaks a workload.
• Make changes via IaC (Terraform/CloudFormation) where the account is managed that way, so the fix is tracked and does not drift back. Hand off IaC specifics to terraform-modules / aws-iam-policies.
• Destructive or access-affecting changes (deleting resources, detaching policies, closing ports) require explicit user confirmation and ideally a change window.

Verification

• Re-run the scanner after fixes: the finding clears and no new Critical/High appeared.
• Independently confirm the headline fixes: bucket is no longer public (test an unauthenticated request), the port is closed, the policy no longer grants *.
• Confirm you did not break access: the legitimate workload still reaches what it needs.

Output contract

## Cloud posture review — <account/project> (<date>)
Scope: <accounts/projects>. Tool: <prowler/scout + native>. Creds: read-only.

### Critical / High findings
| Finding | Resource | Exposure | Fix | Blast radius | Status |
|---------|----------|----------|-----|--------------|--------|
| Public bucket | s3://acme-exports | customer data listable | enable public-access-block | none (not meant public) | fixed |

### Medium/Low: <summary + counts>
### Changes applied (confirmed): <list>. Deferred (needs window): <list>.

Hard rules

• Audit with read-only credentials; never run a posture scan with admin keys.
• Rank by real exposure, not CIS pass/fail count; fix data-exposing and access-granting issues first.
• Get explicit confirmation before any change that closes access or deletes resources — a blind IAM/security-group tighten can take down production.
• Confirm “public” is unintended before locking a bucket; some are public by design.
• Re-scan and independently verify each headline fix; do not trust the tool’s green alone.