heygrc
SOC 2 CC6.6 in code

Keeping the outside outside.

CC6.6 is the SOC 2 criterion about protecting against threats from sources outside your system boundaries: the perimeter. It asks that you put access controls between the outside world and your systems, so what should only be reachable from inside is not sitting open to the internet. Most of that perimeter is now infrastructure-as-code, a security group, a firewall rule, a network policy, which means it is decided in a pull request and can be widened in one.

How it shows up in a diff

The shapes the same control failure takes.

CC6.6 weakens when a change opens the boundary, usually to make something reachable quickly. The recurring shapes:

  • A firewall or security group opens to the world

    An ingress rule's source is widened to 0.0.0.0/0 (or ::/0), so a port that was reachable only from inside is now reachable from the whole internet.

  • A managed resource is made publicly reachable

    A database, cache, or bucket flips from private to public (a publicly-accessible flag, a public subnet), so it can be reached directly from outside rather than only through the app.

  • An admin or management port is exposed

    SSH, RDP, a database port, or an admin console is opened to the internet instead of being reached through a bastion or VPN.

  • An allowlist widens

    A restrictive source range is broadened, a single address becomes a whole range, or an allowlist gains a wildcard, so more of the outside can get in.

  • A boundary control is bypassed

    A new path skips the load balancer, gateway, or WAF that fronts the system, so external traffic reaches an internal service directly.

Worked example

A security group that opens a database to the internet.

A managed Postgres, sitting on a publicly-routable endpoint, needs to be reachable from an engineer's laptop for a one-off migration, so the ingress rule's source is widened to get it working. The quick change is left in, and now the security group accepts connections from any address, not just the application's subnet, on a database that has a path from the internet.

infra/security_groups.tf+1 -1
resource "aws_security_group_rule" "db_ingress" {  from_port   = 5432-  cidr_blocks = [var.app_subnet_cidr]+  cidr_blocks = ["0.0.0.0/0"]}
heygrcSOC 2 CC6.6

This removes the source restriction on the database port, so the security group now permits ingress from any address; on a database that has a path from the internet, that is the whole internet. CC6.6 is about protecting against threats from outside your system boundary, and a database reachable from anywhere is exactly the exposure it is aimed at. Restrict the source to the application's subnet or security group, or reach it through a bastion for one-off access, rather than 0.0.0.0/0.

What an auditor does with this

The perimeter is checked against what is actually reachable.

An auditor does not take 'we have a firewall' at face value; they look at the actual boundary: which ports are open, to what sources, and whether anything meant to be internal is reachable from outside. A security group opened to 0.0.0.0/0, a database flipped to publicly accessible, or an admin port exposed to the internet is the kind of exception that becomes a finding, and it usually arrived in a single infrastructure change. Catching it at the diff keeps the exposure out of the environment the assessment samples.

What this is, and is not

A review, not a network scan.

heygrc flags changes that touch CC6.6 and cites the criterion so the fix happens in the pull request. It does not scan your perimeter or run your cloud posture tooling. It catches the moment a change opens the boundary, at the diff.