Harden devcontainer: port visibility script + CI checks

[Copilot]

This pull request was created as a result of the following prompt in Copilot Chat.

Original prompt - submitted by @02ez

git add .devcontainer/*
git add .github/workflows/devcontainer-ci.yml
git commit -m "Harden devcontainer: port visibility script + CI checks"
git push origin fix/devcontainer-hardening

Summary

This PR addresses a security vulnerability in our devcontainer configuration where port 4000 was automatically exposed publicly to the internet without user consent or security warnings.

Security Issue Fixed

Before (Security Risk):

"postAttachCommand": "gh cs ports visibility 4000:public -c \"$CODESPACE_NAME\""

The previous configuration automatically set port 4000 to public visibility, making the local development server accessible to anyone on the internet who knew the URL. This creates potential security risks including:

• Unintended exposure of development content
• Potential access to debugging interfaces
• No user awareness of public accessibility

After (Hardened):

"postAttachCommand": "./.devcontainer/setup-port-visibility.sh 4000"

Changes Made

1. Secure Port Visibility Script (.devcontainer/setup-port-visibility.sh)

Created a new script that implements secure defaults:

• Private by default: Port 4000 now defaults to private visibility (accessible only to the user)
• Clear security warnings: Users are explicitly warned about the security implications of public ports
• Explicit opt-in: Users must deliberately choose to make ports public or organization-accessible
• Graceful handling: Script works correctly both inside and outside Codespace environments

2. Updated Devcontainer Configuration

Modified .devcontainer/devcontainer.json to use the secure script instead of directly setting public visibility.

3. CI Security Validation (.github/workflows/devcontainer-ci.yml)

Added comprehensive CI checks that:

• Validates devcontainer.json structure and security configuration
• Prevents future introduction of direct public port forwarding
• Ensures secure scripts are executable and properly configured
• Checks for additional Dockerfile security best practices
• Runs automatically on changes to devcontainer files

Security Impact

This change transforms the port forwarding behavior from an insecure default to a secure-by-default approach:

Aspect	Before	After
Default Visibility	Public (⚠️ Security Risk)	Private (✅ Secure)
User Awareness	None	Clear warnings and instructions
Internet Accessibility	Automatic	Explicit opt-in required
Security Validation	None	Automated CI checks

Users who need public or organization-level port access can still achieve this by running the appropriate commands after being clearly informed of the security implications:

# For organization access
gh cs ports visibility 4000:org -c "$CODESPACE_NAME"

# For public access (with security warning)
gh cs ports visibility 4000:public -c "$CODESPACE_NAME"

Testing

• ✅ Script runs correctly in both Codespace and non-Codespace environments
• ✅ No direct public port configurations remain in devcontainer.json
• ✅ CI workflow validates all security measures
• ✅ Port forwarding functionality preserved with secure defaults
• ✅ Existing port attributes and forwarding configuration maintained

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[02ez]

Wire contracts and invariants unchanged, public APIs stable; all gates green: unit integration contract and e2e tests at coverage budgets, hot-path benches within SLO, hermetic reproducible build with signed provenance, SBOM diff clean, deps and secrets scanned, migrations idempotent and reversible, PII paths unchanged, telemetry alerts runbooks rulesets CODEOWNERS and env approvals updated. Canary burn-in clean with prod parity and tight blast radius; rollback and roll-forward armed; ADR and issue linked; SDK and client compatibility verified; changelog cut.

[Copilot]

Pull Request Overview

This PR addresses a critical security vulnerability in the devcontainer configuration by replacing automatic public port exposure with a secure-by-default approach that requires explicit user consent before making ports publicly accessible.

• Replaces direct public port forwarding with a secure script that defaults to private visibility
• Adds comprehensive CI validation to prevent future security regressions
• Implements user education and explicit opt-in for public port access

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
.devcontainer/devcontainer.json	Updates postAttachCommand to use secure port visibility script instead of automatic public exposure
.devcontainer/setup-port-visibility.sh	New security script that sets private visibility by default with clear warnings about public access risks
.github/workflows/devcontainer-ci.yml	New CI workflow that validates devcontainer security configuration and prevents direct public port forwarding

[Copilot]

The script lacks a shebang validation and should include error handling for missing bash. Consider adding a check to ensure the script is executed with bash and handle cases where bash might not be available in the container environment.

Suggested change

	# Ensure the script is running with bash and that bash is available
	if ! command -v bash >/dev/null 2>&1; then
	echo "❌ Error: bash is not installed or not found in PATH." >&2
	exit 1
	fi
	if [ -z "$BASH_VERSION" ]; then
	echo "❌ Error: This script must be run with bash." >&2
	exit 1
	fi

[Copilot]

The grep pattern may not catch all variations of public port visibility configurations. The pattern should be more comprehensive to match different JSON formatting and spacing variations, such as \"ports visibility\".*:.*\"public\" or similar patterns that could bypass this security check.

Suggested change

	if grep -q "ports visibility.*:public" .devcontainer/devcontainer.json; then
	if jq -e '."ports visibility" == "public"' .devcontainer/devcontainer.json >/dev/null; then

[Copilot]

The nested if statements could be simplified and made more robust. Consider combining the conditions or using a more specific pattern that validates the complete postAttachCommand structure rather than just checking for the presence of the script name.

Suggested change

	if grep -q "postAttachCommand" .devcontainer/devcontainer.json; then
	if ! grep -q "setup-port-visibility.sh" .devcontainer/devcontainer.json; then
	echo "⚠️ postAttachCommand found but not using secure port visibility script"
	echo " Consider using ./.devcontainer/setup-port-visibility.sh for secure defaults"
	else
	echo "✅ Using secure port visibility script"
	fi
	fi
	post_attach_cmd=$(jq -r '.postAttachCommand // empty' .devcontainer/devcontainer.json)
	if [ -n "$post_attach_cmd" ]; then
	if echo "$post_attach_cmd" | grep -q "\.\/\.devcontainer\/setup-port-visibility\.sh"; then
	echo "✅ Using secure port visibility script"
	else
	echo "⚠️ postAttachCommand found but not using secure port visibility script"
	echo " Consider using ./.devcontainer/setup-port-visibility.sh for secure defaults"
	fi

[Copilot]

The PORT variable is not validated before use in the command. This could potentially lead to command injection if an attacker can control the PORT parameter. Add input validation to ensure PORT contains only numeric characters.

[Copilot]

The jq command extracts ports as separate lines, but the echo statement treats them as a single string. This could lead to incorrect display of multiple ports. Consider using proper array handling or iterating through ports individually for accurate reporting.

Suggested change

	echo "📋 Found forwarded ports: $FORWARD_PORTS"
	echo "📋 Found forwarded ports:"
	for port in $FORWARD_PORTS; do
	echo " - $port"
	done