iac-security — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited iac-security (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
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 reviews Infrastructure-as-Code for misconfig: over-broad IAM, public storage, missing encryption, open security groups, logging off. It leans on the cloud-provider best practices plus CIS benchmarks and orchestrates the common scanners.
Activates on:
*.tf, *.tfvars, *.hcl, CloudFormation *.yaml/*.json templates, Ansible playbook.yml, roles/, Pulumi Pulumi.yaml plus __main__.py/index.ts.security-review phase 3 where IaC sits in the diff.k8s-security. Even though it's IaC, K8s is its own world with its own tools.container-hardening. Image content belongs there; image-registry IAM here.terraform apply) → cicd-hardening. Overlap: which creds via OIDC is mentioned here.secrets-scanner. Scan IaC with that skill before continuing here.cve-triage.ir-runbook if it's an incident.Six phases. Phases 2 and 3 are the heart (scanning + cloud-aware review).
What do you have, in which tool, for which cloud, and what's the coverage?
*.tf files, terraform.lock.hcl, state location (S3 + DynamoDB lock, GCS, Azure Blob, Terraform Cloud). Modules: in-house or public? Providers: which versions are pinned?*.yaml/*.json templates, CDK output (transpiled to CFN), StackSets in multi-account setups.playbooks, roles, inventory. Note: Ansible often runs against existing hosts, so IaC + runtime config are mixed.Pulumi.yaml plus language-specific code (Python/TS/Go/C#). State in Pulumi Cloud or self-hosted backend.Outcome: an overview of which IaC tech touches which cloud resources. Without that you're picking tools blind and missing the drift between tools and stacks.
One tool per IaC type is rarely enough; the overlap is useful because rule sets differ. Minimize to what genuinely adds value.
Terraform:
CloudFormation:
Ansible:
Pulumi:
Run tools in CI with a baseline file (see also sast-orchestrator phase 5 for noise-reduction discipline). Findings on new code are blockers; existing ones are plannable.
The difference between IaC scanning and cloud review: tools catch the rules, humans catch the context. Walk these categories for every resource type that's in play.
Action (s3:*), wildcards in Resource (arn:aws:s3:::*), service accounts with Owner/Admin roles, cross-account trust without ExternalId, MFA not required on root or admin users. Make principle of least privilege verifiable by generating policies from CloudTrail/Audit Logs (aws iam generate-service-last-accessed-details).0.0.0.0/0 on non-web ports (22 SSH, 3389 RDP, 3306 MySQL, 5432 Postgres), NACLs too permissive, route tables steering traffic via unintended paths, VPC peering without proper segmentation.RequireTLS: true on buckets, RDS forced SSL), at-rest (KMS-CMK or equivalent), key rotation on.secrets-scanner.CIS benchmarks as the baseline: AWS Foundations Benchmark v3, GCP Foundation Benchmark v2, Azure Foundations Benchmark v2. All three exist as Checkov rule sets (cis_aws, cis_gcp, cis_azure).
Scanning is detect-after-the-fact. Policy-as-code enforces before apply.
terraform plan -out=tfplan && terraform show -json tfplan | conftest test -. Policies in git, reusable across stacks.Write policies for org-specific rules tools don't know: "all databases in their own VPC", "no EC2 with public IP unless tagged public-allowed", "all S3 buckets must have object-lock on in finance accounts".
IaC state and actual cloud state can diverge through manual console changes, other tools, or compromised credentials. Without drift detection your model goes stale.
terraform plan in CI on a schedule, alert on non-zero diff.aws cloudformation detect-stack-drift), wireable to CloudWatch alerts.pulumi refresh --expect-no-changes, fails on diff.Drift is not by definition a security incident, but unintended drift must be triaged. On suspicious drift (a new IAM role not in code): escalate to ir-runbook.
Layer 1: scope (every IaC type in the repo covered? all regions/accounts? drift check active?), assumptions ("CIS-benchmark compliant" backed by tool output, not eyeballed), gaps (secrets and k8s-manifests explicitly handed off?), consistency (policy-as-code rules not in conflict with SCPs).
Layer 2: CIS benchmark version numbers correct, cloud-provider feature names current (AWS changes feature names), no fabricated rule IDs from a scanner, CVE references (when used for a specific IaC misconfig) verified against NVD.
IaC Security review — <scope>
IaC types: <terraform | cfn | ansible | pulumi>
Clouds in scope: <aws | gcp | azure | multi>
Scan output (summary, no raw dumps):
Checkov: <N blockers, M medium, K low>
tfsec/Trivy:<...>
cfn-nag: <...>
Cloud-aware findings:
IAM: <list of overly permissive roles/policies>
Storage: <public buckets, unencrypted volumes>
Networking: <open security groups, NACL gaps>
Logging: <CloudTrail/audit gaps>
Encryption: <in-transit + at-rest gaps>
Policy-as-code status:
Active: <OPA/Conftest | Sentinel | SCPs | Org Policy>
Coverage: <which rules active, which not>
Drift:
Last checked: <date>
Divergence: <none | see appendix>
Findings (severity-sorted, blockers first, follow security-review format)
Verification-loop: ...~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.