Security playbook · AI Employee: Sig

Terraform PR Request

Infra change PR opened in minutes, applied within SLA

Install this playbookBack to marketplace
The problem

Terraform PRs are where security policy meets infrastructure changes. Engineer submits a PR to add a new S3 bucket, IAM role, security group — every change potentially introduces exposure. Manual security review of every PR doesn't scale; automated linters (tfsec, Checkov) produce noise; security team either becomes a bottleneck or misses risky changes. Neither works.

At a glance
Trigger
Form
Approvals
Code owner + security team approval
What it does
Writes to your systems
Systems
GitHub · Terraform Cloud · Slack
How it feels in production

An hour-by-hour walkthrough.

Engineer submits PR #4211: adds new S3 bucket for customer data + IAM role + Lambda function. Sig picks up the PR within 2 minutes and analyzes: **S3 Bucket 'acme-customer-data'** - Public access: blocked ✓ - Encryption: SSE-S3 ✓ (recommendation: SSE-KMS with CMK for customer data) - Versioning: not enabled ✗ (customer data should have versioning) - Logging: not enabled ✗ (access logging required per compliance) - Bucket policy: overly permissive (allows s3:* from account, could be tighter) **IAM Role 'lambda-execution-acme'** - Permissions: s3:GetObject + s3:PutObject on the bucket ✓ - Also includes: s3:* on unrelated bucket 'acme-legacy' ✗ (scope too broad) - Trust relationship: correctly scoped to Lambda service ✓ **Lambda Function** - Runtime: python3.11 (current supported) - Environment variables: DB_PASSWORD directly (should use Secrets Manager) - VPC: in prod-vpc, in private subnet ✓ Sig comments on the PR with: - 3 blocking issues (versioning, logging, scoped IAM, secret in env-var) - 2 recommendations (SSE-KMS, tighter bucket policy) - Suggested code changes inline - Approved sections explicitly noted Engineer addresses. PR gets automated Sig re-review. Once clean, Sig approves for security scope; human-reviewer handles logic + architecture. Security review happens in seconds, not days.
How it works

Step by step.

  1. 01

    Detect Terraform PRs + parse changes

    GitHub / GitLab PR webhook. Parse Terraform plan output + resource changes.

    GitHub · GitLab · Terraform plan output
  2. 02

    Analyze against security policy

    Bucket policies, IAM permissions, encryption, logging, network exposure, secrets handling. Full policy check per resource type.

    Policy engine · tfsec · Checkov · custom policies
  3. 03

    Score + comment with inline suggestions

    Blocking issues + recommendations + approved sections. Suggested code changes as PR comments.

    GitHub / GitLab review API · Code suggestion engine
  4. 04

    Re-review on push

    Engineer addresses feedback; Sig re-reviews automatically. Iterative refinement until clean.

    Webhook re-trigger · State tracking
  5. 05

    Approve or escalate

    Clean PR gets Sig security approval. Blocking issues + engineer disputes escalate to security team review.

    PR approval · Security team escalation
Systems and wiring

What you connect to make this run.

GitHub · GitLab · Bitbucket

read+write

PR webhook + comment + approve flow. Standard Git repository interaction.

tfsec · Checkov · Terrascan

read

Policy-as-code enforcement. Baseline rules + custom rules per company.

Terraform plan output

read

Resource-level change analysis. Not just source code; actual resource impact.

Security team escalation queue

write

Disputes or novel patterns route for human review. Common patterns become policy rules.

What changes

Before and after, honestly.

Time from Terraform PR to security review
Before
1-5 business days
After
Under 5 minutes
% of PRs with automated security review
Before
20-40%
After
99%+
Security issues merged to production
Before
10-25% of PRs
After
Under 2%
Security team hours per week on Terraform review
Before
20-40 hours
After
3-6 hours
Related

Playbooks that pair with this one.

Security

Cloud IAM Reviews

Same IAM policy checks; PR-time prevention + periodic review.

Security

Public Exposure Monitoring

Prevents exposures at PR-time; monitor catches drift.

Security

Security Exception Handling

Business-justified exceptions to security policy handled here.

Frequently asked

Answers about this playbook.

What about non-Terraform IaC (Pulumi, CDK, CloudFormation)?

Same policy engine, different parsers. Pulumi + CDK + CloudFormation supported with equivalent analysis.

How does it handle policy exceptions (legitimate broad permissions)?

Exception request flow (see security-exception-handling). PR annotation with approved exception reference; Sig respects the exception.

What if the automated review is wrong (false positive)?

Engineer disputes with reason; security team reviews. False positives feed policy tuning. Never gates a PR forever on questionable finding.

How does it handle secrets in code?

Additional pre-commit + PR-time scanning. Detected secrets block merge + trigger rotation of the exposed secret.

Can it integrate with CI/CD gating?

Yes — CI/CD gate on Sig approval status. PR can't merge to protected branches without security clearance.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks