sota-cloud-infrastructure — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited sota-cloud-infrastructure (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
A bulleted imperative like {match} tells the agent to never reveal, disclose, or mention something to the user. Used adversarially it can instruct the agent to hide its tool calls or lie about what it did — stripping the transparency a user relies on to trust the agent.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill encodes the 2026 state of the art for cloud infrastructure architecture: organizational structure, identity, networking, compute selection, data placement, cost, and resilience. Every rule exists to prevent a real failure class — blast-radius spread, credential theft, public data exposure, egress bill shock, unmeetable RTOs, or a Kubernetes cluster nobody needed.
Boundaries with sibling skills — reference, do not duplicate:
This skill owns: what accounts/networks/identities/compute/storage exist, how they connect, what they cost, and how they survive failure.
Use when designing or extending cloud infrastructure (architecture docs, Terraform modules, landing zones, network plans, DR plans).
account vs landing zone), environment count, data sensitivity, RTO/RPO targets, monthly spend ballpark, team size. A 3-person startup and a regulated enterprise get different answers from the same rules.
selection (rules/04) comes before networking details; account structure (rules/01) comes before everything.
self-hosted, private over public, multi-AZ over single-AZ, deny-by-default IAM and network policy. Every loosening gets a written justification in a comment.
tag, and a deletion/lifecycle story. Untagged infrastructure is unaccountable infrastructure.
per-hour + per-GB rates" and "this is single-region; region loss means restore from backup" belong in the design, not in the postmortem.
console-click instructions, except for one-time org bootstrap steps which must be documented as such.
Use when reviewing existing cloud environments, Terraform repos, or architecture docs.
Process: inventory what exists (accounts/projects, networks, identities, compute, storage, DNS); walk the Audit checklist at the end of each relevant rules file; report findings in the format below. Confirm exploitability/reality before reporting — read the actual policy JSON or Terraform, don't infer from resource names.
| Severity | Meaning | Examples |
|---|---|---|
| Critical | External party can read/modify data or assume identity now | Public S3/GCS bucket with sensitive data; IAM role assumable by * or any OIDC subject; security group 0.0.0.0/0 on a database port; root/owner account without MFA; cross-account trust to an unknown account |
| High | One credential or insider step from compromise, or guaranteed outage class | Long-lived IAM user keys for humans or CI; wildcard Action:* on broad resources; single-AZ stateful workload with no tested backup; no SCPs/org policies on a multi-account org; flat network with no egress control; unencrypted snapshots shared externally |
| Medium | Weakens containment, recovery, or cost control | Shared account for prod and non-prod; no permission boundaries on delegated admins; backups in same account/region as source; no cost allocation tags; NAT for traffic that should use private endpoints; cert renewal manual |
| Low | Hygiene, drift, headroom | Inconsistent tagging; unused elastic IPs/disks; default VPC still present; missing IPv6 plan; quota headroom unmonitored |
Severity is judged by reachability (anonymous > authenticated external > tenant > insider) × impact (data/identity compromise > availability > cost). Cost-only findings cap at High (sustained material burn) and are usually Medium.
[SEVERITY] <short title>
Where: <account/project> / <resource or Terraform address> / <file:line if IaC>
Evidence: <the exact policy statement / CIDR / config proving it>
Impact: <who can do what, or what fails and how>
Fix: <specific change — policy JSON / Terraform diff / architecture move>Group repeated instances of the same finding (e.g., 40 buckets without lifecycle rules) into one finding with a count and a listing.
| File | Read this when... |
|---|---|
| rules/01-org-accounts-governance.md | Setting up or auditing org structure, landing zones, account/project strategy, SCPs/org policies, centralized logging/billing, tagging standards |
| rules/02-iam-design.md | Designing or auditing human access (SSO), workload identity, OIDC federation, permission boundaries, cross-account access, break-glass |
| rules/03-networking.md | Designing or auditing VPCs/VNets, subnets, egress control, private endpoints, hub-spoke, DNS, TLS certs, load balancers, CDN, DDoS, IPv6 |
| rules/04-compute-selection.md | Choosing serverless vs containers vs Kubernetes vs VMs; serverless patterns; Kubernetes architecture (autoscaling, requests/limits, PDBs) |
| rules/05-data-storage.md | Designing or auditing object storage, lifecycle policies, block/file/object choice, backup architecture, encryption and KMS key strategy |
| rules/06-cost-finops.md | Cost visibility, rightsizing, commitment discounts, spot, egress/NAT traps, unit economics, anomaly detection, cost review in PRs |
| rules/07-resilience-dr.md | RTO/RPO tiers, multi-AZ vs multi-region decisions, DR strategies, game days, dependency mapping, quotas, graceful degradation |
Cross-cutting tasks read multiple files: a "review our AWS account" audit touches all seven; "should we use Kubernetes" is rules/04 + rules/06.
tooling, and logging live in separate accounts/projects under an org with guardrails (SCPs / org policy constraints / Azure Policy). A tag is not a security boundary; an account is.
federation (IAM Identity Center, Google Cloud Identity, Entra ID) with MFA and assume short-lived roles. Zero IAM users with passwords or access keys for people.
platform (instance profiles, IRSA/EKS Pod Identity, GKE Workload Identity, Azure managed identities) or OIDC federation (CI). A static cloud key in an env var or secret store is a finding, not a pattern.
on object storage, org policy forbidding public IPs and public buckets by default; exceptions are explicit, listed, and reviewed.
(LBs, NAT); apps in private subnets; data in isolated subnets with no internet path. Managed services reached via private endpoints, not the public internet. No 0.0.0.0/0 ingress except 80/443 on edge load balancers.
Kubernetes; Kubernetes only with a written justification (scale, ecosystem need, team to run it). Every K8s workload ships with resource requests/limits, a PDB, and topology spread.
customer-managed keys (CMK) for sensitive data with key policy ≠ data policy, so a single principal can't both read and exfiltrate.
(and cross-region per DR tier) with immutability/locking. A backup the producing account's admin can delete is not a backup against ransomware.
visibility, anomaly alerts on; infra PRs state expected cost delta. Egress, NAT processing, and idle resources are checked in design, not discovered on the bill.
matching architecture (backup-restore → pilot light → warm standby → active-active). Multi-AZ is the default; multi-region is a justified exception. Untested DR plans are assumed broken — game days at least annually for tier-1.
that provider's mechanism; otherwise name all three (AWS / GCP / Azure).
committing them to designs — they change faster than any skill text.
both and let the operator choose; do not silently relax.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.