Cloud Security Controls

Cloud Security Controls

security-mcp ships a registry-driven cloud security engine with 998 doc-verified rules mapped to the major cloud benchmarks. It detects misconfiguration directly in your infrastructure-as-code, maps each finding to the frameworks an auditor cares about, and for Terraform it can write the fix and verify it.

Coverage at a glance

By provider:

Provider	Rules
AWS	483
Azure	320
GCP	195
Total	998

By IaC format:

Format	Rules
Terraform / HCL	774
CloudFormation	128
Bicep	96

flowchart LR
  IaC[Terraform / CloudFormation / Bicep] --> Detect[Rule registry: 998 rules]
  Detect --> Map[Framework mapping]
  Map --> Find[Findings + requiredActions]
  Find -->|Terraform| AH[autoharden]
  AH --> Verify[Re-detect to verify]
  Verify --> Keep[Keep fix or flag manual]

Loading

Frameworks mapped

Every rule carries the benchmarks it satisfies:

• AWS Foundational Security Best Practices (FSBP)
• CIS Benchmarks for AWS, GCP, and Azure
• Microsoft Cloud Security Benchmark

A single finding therefore tells you not only what is wrong, but which control IDs across which frameworks it touches, which feeds straight into the compliance report.

How detection works

The engine parses your IaC, identifies resource types, and evaluates each applicable rule's detect clause against the resource. Detection is declarative: a rule either forbids a dangerous property, requires a safe one, or requires a companion resource to exist. The parser understands Terraform/HCL, CloudFormation, and Bicep, so the same conceptual rule (for example, "block public S3 access" or its Azure and GCP equivalents) is expressed per format.

Rule structure

Each rule is a self-contained, documented object. Conceptually:

{
  "ruleId": "aws-s3-block-public-access",
  "threat": "Public bucket exposes objects to the internet",
  "frameworks": ["AWS FSBP", "CIS AWS"],
  "severity": "HIGH",
  "title": "S3 bucket must block all public access",
  "detect": {
    "target": "terraform",
    "resourceType": "aws_s3_bucket",
    "require": "...",                  // or "forbid": "..."
    "requireCompanionType": "aws_s3_bucket_public_access_block"
  },
  "remediate": {
    "strategy": "ensure",             // ensure | companion | snippet
    "ensure": "...",
    "companion": "...",
    "snippet": "..."
  },
  "requiredActions": ["Add public access block", "Set bucket ACL private"]
}

The fields:

• ruleId: stable identifier.
• threat: the concrete risk in plain language.
• frameworks[]: the benchmark control IDs the rule maps to.
• severity: finding severity.
• title: short human label.
• detect: target, resourceType, and one of forbid, require, or requireCompanionType.
• remediate: a strategy plus the data to apply it (ensure, companion, or snippet).
• requiredActions[]: the manual steps if auto-remediation is not applied.

Terraform auto-remediation: autoharden

For Terraform, security-mcp does more than detect. The autoharden command applies a rule's remediation, then re-runs detection to prove the fix landed.

# Preview the changes without writing
security-mcp autoharden --dry-run

# Apply, then re-detect to verify
security-mcp autoharden

The loop is:

1. Apply. Inject the ensure property, add the companion resource, or insert the snippet.
2. Re-detect. Run the rule again against the modified file.
3. Keep or flag. If detection now passes, the fix is kept. If it does not (for example, the change needs context the tool cannot safely infer), the rule is flagged for manual handling and the requiredActions and remediation snippet are surfaced so a human can finish it.

Use --dry-run first to review the diff. CloudFormation and Bicep rules detect and report with full requiredActions guidance; the automated apply-and-verify loop is Terraform-specific.

See The Gate Engine for how IaC findings fold into the overall verdict, and the terraform_hardening_blueprint and generate_opa_rego entries in the MCP Tools Reference.