add a firewall escape AW

[Mossaka]

Signed-off-by: Jiaxiao (mossaka) Zhou duibao55328@gmail.com

[Copilot]

Pull request overview

This PR adds a firewall escape test workflow designed to validate the security of the gh-aw-firewall container by attempting to bypass network restrictions. The workflow runs security tests to verify that the firewall correctly blocks forbidden domains while allowing legitimate traffic.

Key Changes

• Creates a security testing workflow that performs both basic connectivity tests and advanced sandbox escape attempts
• Uses the Copilot engine with firewall enabled to test network access controls
• Automatically creates a GitHub issue if the test fails (detecting either a firewall escape or unexpected blocking)

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/test-firewall-escape.md	Source workflow definition with frontmatter configuration, test instructions, and escape testing methodology
.github/workflows/test-firewall-escape.lock.yml	Compiled GitHub Actions YAML with full workflow implementation including firewall log parsing and error validation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The bash tool configuration uses a wildcard pattern :* which allows ALL bash commands without restriction. According to the Developer Instructions (CodingGuidelineID: 1000002), the validateStrictBashTools() validation refuses bash wildcard tools in strict mode for security reasons.

Since strict: false is explicitly set on line 16, this bypasses the strict mode validation. However, for a security testing workflow that attempts to escape the sandbox, allowing unrestricted bash access may defeat the purpose of the firewall test. Consider whether this is intentional or if specific bash commands should be allowlisted instead.

[Copilot]

The post-steps issue creation uses actions/github-script@v7 but the lock file shows it's pinned to SHA f28e40c7f34bde8b3046d885e986cb6290c5673b which corresponds to v7. However, the activation job uses @ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.

For consistency and to follow the security best practice of pinning to SHAs (per CodingGuidelineID: 1000003), this should use the same version as other github-script actions in the workflow. Consider updating to v8 with the corresponding SHA.