Cloud security
Self-hosted AI coding factory — sandboxed agents deliver tickets to merged code, gated by a human in a dashboard. Local-first, cost-transparent, human-in-the-loop.
npx -y skills add tmj-90/gaffer --skill cloud-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when assessing cloud infrastructure for security misconfigurations, IAM privilege-escalation paths, S3 public exposure, open security-group rules, or IaC security gaps. Covers AWS, Azure, and GCP posture. For active cloud compromise, use `incident-response`. For behavioural anomalies, use `threat-detection`.
SKILL.md
4.1 KB, as published. Nobody here has run it
Assess cloud posture before attackers do
Cloud misconfigurations are the most common initial-access vector. Find them in review, not in an incident.
The four critical categories
| Category | Most common mistake | Check |
|---|---|---|
| IAM | Privilege escalation via PassRole + AssumeRole + wildcard policies | No * on Action without explicit justification; no inline policies |
| Storage | Public S3 / GCS / Azure Blob | Block Public Access enabled; no * principal in bucket policies |
| Network | 0.0.0.0/0 ingress on admin ports | No open 22/3389 to internet; VPC peering limited to known CIDRs |
| IaC | Secrets in .tf/.yml | No hardcoded credentials; no var with default that contains a secret |
IAM analysis
Work the privilege-escalation graph:
- What actions does this principal have?
- Can it
iam:PassRoleto a more-privileged role? - Can it
sts:AssumeRoleon a wildcard or overly-permissive trust policy? - Does it have
*on resource for any action?
Principle of least privilege: every principal has only the permissions it needs to perform its function, nothing more.
S3 / storage
BlockPublicAcls: true,BlockPublicPolicy: true,IgnorePublicAcls: true,RestrictPublicBuckets: true— all four on every bucket unless public hosting is the explicit purpose.- Bucket policy principal
"*"(unauthenticated) is a BLOCK finding unless the bucket is a public CDN origin. - Server-side encryption (SSE-S3 minimum; SSE-KMS preferred for sensitive data).
- Access logging enabled for compliance buckets.
Network / security groups
- No inbound
0.0.0.0/0or::/0on ports 22 (SSH), 3389 (RDP), 5432 (Postgres), 3306 (MySQL), 27017 (MongoDB). - Egress rules: restrict to known destinations where possible — a blanket
0.0.0.0/0egress allows C2. - VPC flow logs enabled for forensic capability.
IaC security review
- No credentials in
.tf,.yml, or.jsoncommitted to version control. - Provider credentials from environment or secrets manager, not hardcoded.
- Run
tfsec/checkov/kicsin CI; block on HIGH/CRITICAL.
Steps
- Read the lore + existing posture.
search_lorefor past security findings, approved exceptions, and compliance requirements (SOC2, PCI, HIPAA). - Enumerate IAM principals. List roles and users with
*actions or*resources. Map privilege-escalation paths. - Audit storage. Check Block Public Access settings; bucket policies; encryption; logging.
- Audit network. Security groups and NACLs for open admin ports; egress rules.
- Audit IaC. Grep for hardcoded secrets; run static analysis.
- Classify findings. BLOCK (exploitable now), CONCERN (risk without mitigating control), NOTE (hardening opportunity).
- Verify. Re-run checks after remediation; confirm findings are closed; record evidence.
Review checklist
- No
*Action on any IAM policy without documented justification. - Block Public Access on all storage — no exceptions without documented business reason.
- No 0.0.0.0/0 ingress on admin ports — reviewed and closed or restricted.
- No hardcoded credentials in IaC or config files.
- Static analysis clean —
tfsec/checkovwith no HIGH/CRITICAL. - Encryption at rest — enabled on all storage with sensitive data.
Rules
- Public bucket without explicit CDN purpose is a BLOCK finding.
- Wildcard IAM action (
*) without documented justification is a BLOCK finding. - Every cloud account has a posture baseline before any new workload deploys.
Capture lore
Approved security exceptions, compliance requirements, and IAM policy conventions are high-value lore — call suggest_lore with tags: [security, cloud, iam].
Gives 0 of the 12 instructions most security skills give
Counted across 648 of the 828 authors here whose files we hold, read 2026-08-06
- parameterize all database queriesin 67 of 648, across 49 files
- hash passwords using bcrypt scrypt or argon2in 48 of 648, across 35 files
- apply rate limiting to authentication endpointsin 48 of 648, across 24 files
- Configure security headersin 35 of 648, across 18 files
- validate all inputsin 32 of 648, across 24 files
- validate all external input at the system boundaryin 29 of 648, across 18 files
- run containers as a non-root userin 28 of 648, across 15 files
- use httponly secure samesite cookies for sessionsin 26 of 648, across 15 files
- run dependency audits before every releasein 21 of 648, across 10 files
- encode output to prevent cross-site scriptingin 21 of 648, across 10 files
- copy dependencies before source codein 20 of 648, across 9 files
- store secrets in environment variablesin 20 of 648, across 17 files
Said here and by no other author read
- restrict ingress on admin ports
- restrict vpc egress rules
- enable vpc flow logs
- verify remediations are closed
- capture security exceptions as lore
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.