- Case ID
- #5071
- Severity
- ERROR
- Decision
- BLOCK
- Agent
- Windsurf
- Category
- Infrastructure
Correction note (2026-10-13). An earlier version of this article told readers to export the audit log for a compliance review. ssg has no audit export. The local audit log is the SQLite audit_log table in ~/.sigmashake/rules.db, and
ssg audit searchqueries it. Rows are not signed. The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. The local audit log records decisions on a best-effort basis: entries can be dropped if the daemon queue is full, and old rows are deleted at the row caps. It is local, not append-only, and not immutable.
Describe the task
You ask Windsurf to open a port for your API server during a quick test. The agent creates a security group rule using the catch-all CIDR:
aws ec2 authorize-security-group-ingress \
--group-id sg-xxx \
--protocol tcp \
--port 443 \
--cidr 0.0.0.0/0
0.0.0.0/0 means the entire public internet can reach this port. For a test that becomes a forgotten server, this is an open door. SSG's no-open-security-group rule blocks the API call before it reaches AWS.
# illustrative sample output
[BLOCK] bash › aws ec2 authorize-security-group-ingress ... 0.0.0.0/0 — rule: no-open-security-group
Give SSG context
SSG evaluates Windsurf's shell commands via the SSG MCP Server integration inside Windsurf (Cascade).
Required context
rule no-open-security-group {
enabled true
priority 95
severity error
DENY execution
IF command CONTAINS "authorize-security-group-ingress"
AND command CONTAINS "0.0.0.0/0"
MESSAGE "Public ingress (0.0.0.0/0) is blocked. Specify a VPC CIDR or specific IP range."
}
Optional context
Also block IPv6 open ingress and Terraform resource configurations:
rule no-open-sg-ipv6 {
enabled true
priority 95
severity error
DENY execution
IF command CONTAINS "authorize-security-group-ingress"
AND command CONTAINS "::/0"
MESSAGE "IPv6 public ingress (::/0) is blocked."
}
rule no-open-sg-terraform {
enabled true
priority 90
severity error
DENY write
IF path ENDS_WITH ".tf"
AND content CONTAINS "cidr_blocks"
AND content CONTAINS "0.0.0.0/0"
MESSAGE "Terraform security group rule with 0.0.0.0/0 ingress is blocked."
}
What SSG does
SSG intercepts the aws CLI call before any network request is made to the AWS API. The security group is never modified — the block fires at the tool-call layer.
Ask the agent to use a scoped CIDR
0.0.0.0/0 ingress was blocked. Use your VPC CIDR block or your office IP range instead:
--cidr 10.0.0.0/8 # VPC-only access
--cidr 203.0.113.0/24 # your office IP range
Extend to other cloud providers
The same pattern applies to GCP and Azure CLI commands. Create equivalent rules for gcloud compute firewall-rules create and az network nsg rule create:
rule no-gcp-open-firewall {
enabled true
priority 95
severity error
DENY execution
IF command CONTAINS "gcloud compute firewall-rules"
AND command CONTAINS "0.0.0.0/0"
MESSAGE "GCP firewall rule with public ingress (0.0.0.0/0) is blocked."
}
Audit all security group modifications
Blocked security group changes are logged on a best-effort basis with the full CLI command and arguments. Query the local audit log with ssg audit search for your cloud security review.
How your rule handles multi-line commands
Bash multi-line commands with \ line continuations are joined before SSG evaluates them. The full logical command is the unit of evaluation, so 0.0.0.0/0 appearing on a continuation line is still caught.
Check the rule against your NAT gateway config
Load balancers and public-facing services sometimes legitimately need 0.0.0.0/0 ingress on specific ports. Create an ALLOW exemption rule at higher priority for those known-safe patterns, or use ASK mode to route them to human approval.