Skip to main content

Block Mode

Block mode enforces strict network egress control by blocking all connections that don't match your allow list. This provides maximum security for your CI/CD pipeline.

What is Block Mode?​

In block mode, Bullfrog:

  • Blocks all outbound connections by default
  • Only allows connections to specified IPs and domains
  • Reports blocked connections in the workflow summary

When to Use Block Mode​

Use block mode when you:

  • Have identified all necessary connections via audit mode
  • Want to prevent data exfiltration from your workflows
  • Need to enforce strict security policies
  • Are protecting sensitive workflows (production deployments, releases)

Block All Connections​

The strictest configuration blocks everything except essential GitHub Actions infrastructure:

- uses: bullfrogsec/bullfrog@c8e5fff94e0050c0cef9b9596c55cf3d9c53ba2c # v0.9.2
  with:
    egress-policy: block
warning

This will block most workflows unless they don't make any external connections. Use this for highly restricted environments or testing.

Allow Specific Domains​

Most workflows need to allow certain domains for dependencies and services:

- uses: bullfrogsec/bullfrog@c8e5fff94e0050c0cef9b9596c55cf3d9c53ba2c # v0.9.2
  with:
    egress-policy: block
    allowed-domains: |
      github.com
      *.github.com
      registry.npmjs.org
      *.npmjs.org

Allow Specific IPs​

For services accessed by IP address:

- uses: bullfrogsec/bullfrog@c8e5fff94e0050c0cef9b9596c55cf3d9c53ba2c # v0.9.2
  with:
    egress-policy: block
    allowed-ips: |
      1.2.3.4
      5.6.7.8
      192.168.1.0/24

Combined Configuration​

Most production workflows use a combination of allowed domains and IPs:

- uses: bullfrogsec/bullfrog@c8e5fff94e0050c0cef9b9596c55cf3d9c53ba2c # v0.9.2
  with:
    egress-policy: block
    allowed-domains: |
      github.com
      *.github.com
      registry.npmjs.org
      *.docker.com
      docker.io
      *.docker.io
    allowed-ips: |
      1.2.3.4
    dns-policy: allowed-domains-only
    enable-sudo: false

Handling Blocked Connections​

When a connection is blocked:

  1. Workflow Step Fails: The step attempting the connection might fail if the connection is required for the step to complete successfully
  2. Error Message: You should see a connection error in the step logs
  3. Summary Report: Blocked connections appear in the workflow summary

Reviewing Blocked Connections​

Check the workflow summary to see what was blocked:

  1. Navigate to your workflow run in GitHub Actions
  2. Select the Summary section
  3. Look for the Bullfrog Results in each job summary
  4. Review all logged connections with:
    • Timestamp
    • Destination IP address and port
    • Domain name (if available)
    • Protocol (TCP/UDP/DNS)
    • Decision
    • Reason for the decision
    • Process metadata (executable path, command arguments)

Use this information to determine if the connection should be allowed or if it indicates a security issue.

Security Best Practices​

  1. Principle of Least Privilege: Only allow connections you've verified as necessary
  2. Avoid Wildcards When Possible: registry.npmjs.org is better than *.npmjs.org
  3. Disable Sudo: Set enable-sudo: false to prevent bypass attempts
  4. Regular Audits: Periodically switch back to audit mode to verify no new connections are needed
  5. Document Allow Lists: Comment your configuration to explain why each entry is needed
- uses: bullfrogsec/bullfrog@c8e5fff94e0050c0cef9b9596c55cf3d9c53ba2c # v0.9.2
  with:
    egress-policy: block
    allowed-domains: |
      # Required for npm package downloads
      registry.npmjs.org
      *.npmjs.org
      # Required for Docker image pulls
      *.docker.com
      docker.io
      *.docker.io
    enable-sudo: false # Maximum security

Next Steps​