ci: add Socket Firewall to Emulate workflows

[peakematt]

Emulate installs public npm packages in host and Docker build jobs. This change routes those registry downloads through the pinned WorkOS Socket Firewall action. Ordinary public pull request jobs retain the action-validated external-fork fallback with read-only permissions and non-persisted checkout credentials; release jobs remain fail-closed.

Docker installs receive temporary Bun configuration through BuildKit secrets, with direct public-registry access blocked inside the build. Authenticated candidate images are scanned before publication, including every image layer and its metadata. Cleanup and same-pin teardown precede the config-free publication step, which fails on a dependency-install cache miss rather than downloading without protection. Existing platforms, tags, inherited secrets, Homebrew handling and npm provenance are preserved.

To verify, inspect the Scan authenticated image steps in both Docker checks: setup must be active, scans clean and cleanup successful. The scanner self-tests cover real synthetic credential/endpoint matches, secrets deleted from earlier layers, unknown image formats and harmless registry-related text. At 0631dd6, authenticated amd64 and arm64 image scans passed, along with the application and compatibility checks. No real release was dispatched as a test.

Before merge, resolve the existing tree-sitter-kotlin GitHub-archive dependency route. That route is not claimed protected by the npm registry proxy, and no coverage exception or dependency change is approved here. Current human owner approval and the normal merge checks also remain required.

[devin-ai-integration]

Devin Review found 2 potential issues.

[devin-ai-integration]

🟡 Existing-tag release retries fail

When workflow_dispatch selects a pre-PR tag, build-binaries.sh comes from that tag but receives the new target-specific arguments. The older script writes into dist/binaries, while this job uploads from dist, so every existing-tag retry fails.

Prompt for agents

Preserve workflow_dispatch support for existing tags, including tags created before this PR. The workflow currently checks out the selected tag, so scripts/build-binaries.sh and the new image-scan scripts also come from that historical tag. Old build-binaries.sh versions ignore the target and asset arguments and write under dist/binaries, while this matrix job expects dist/<asset>. Old tags also lack scripts/create-sfw-image-scan-needles.py and scripts/scan-image-secrets.py. Arrange for release tooling to come from the workflow revision while application sources remain pinned to inputs.tag_name, or explicitly change and enforce the dispatch contract so unsupported historical tags cannot start a broken release.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔍 One dependency bypasses firewall coverage

The lockfile rewrite downloads tree-sitter-kotlin from GitHub rather than the protected registry. Resolve the declared coverage gap before relying on these builds.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[greptile-apps]

Confidence Score: 3/5

The PR is not safe to merge until the manually supplied release tag is removed from direct shell interpolation.

Findings

1.   Release Input Executes Commands ▶

Prompt To Fix All With AI

### Issue 1
.github/workflows/release.yml:81
The manual workflow accepts a free-form `tag_name` and inserts it directly into the generated Bash script. A valid tag containing command substitution such as `$()` will execute commands despite the surrounding double quotes. A user who can dispatch releases and create that tag could access credentials in the release build job or alter artifacts sent to later publication jobs. Pass GitHub expression values through environment variables instead.

**How this was verified:** `workflow_dispatch` exposes `tag_name` as an unrestricted string, and line 81 inserts it directly into a Bash command before execution.

```suggestion
        env:
          TAG_NAME: ${{ inputs.tag_name }}
          TARGET: ${{ matrix.target }}
          ASSET: ${{ matrix.asset }}
        run: scripts/build-binaries.sh "$TAG_NAME" "$TARGET" "$ASSET"
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

• Adds read-only workflow permissions, non-persisted checkout credentials, and external-fork fallback for ordinary CI.
• Adds fail-closed Docker publication, multi-platform image scanning, teardown, and private-material cleanup.
• Extends binary builds to fetch explicit Bun compile executables for each release target.
• Introduces strict Bun-config needle generation and Docker/OCI layer and metadata scanning.
• The release workflow's direct interpolation of the manual tag input creates a command-execution path that must be fixed.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Setup[Setup Socket Firewall] --> Config[Temporary Bun configuration]
  Config --> Install[Protected dependency installs]
  Config --> Secret[BuildKit secret]
  Secret --> AuthBuild[Authenticated multi-platform image build]
  AuthBuild --> Scan[Scan OCI metadata and every layer]
  Scan --> Teardown[Teardown firewall and delete private material]
  Teardown --> CacheBuild[Configuration-free cache build]
  CacheBuild --> Publish[Publish image]

Loading

[greptile-apps]

Release Input Executes Commands

The manual workflow accepts a free-form tag_name and inserts it directly into the generated Bash script. A valid tag containing command substitution such as $() will execute commands despite the surrounding double quotes. A user who can dispatch releases and create that tag could access credentials in the release build job or alter artifacts sent to later publication jobs. Pass GitHub expression values through environment variables instead.

How this was verified: workflow_dispatch exposes tag_name as an unrestricted string, and line 81 inserts it directly into a Bash command before execution.

Suggested change

	run: scripts/build-binaries.sh "${{ inputs.tag_name }}" "${{ matrix.target }}" "${{ matrix.asset }}"
	env:
	TAG_NAME: ${{ inputs.tag_name }}
	TARGET: ${{ matrix.target }}
	ASSET: ${{ matrix.asset }}
	run: scripts/build-binaries.sh "$TAG_NAME" "$TARGET" "$ASSET"

Prompt To Fix With AI

This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 81

Comment:
**Release Input Executes Commands**

The manual workflow accepts a free-form `tag_name` and inserts it directly into the generated Bash script. A valid tag containing command substitution such as `$()` will execute commands despite the surrounding double quotes. A user who can dispatch releases and create that tag could access credentials in the release build job or alter artifacts sent to later publication jobs. Pass GitHub expression values through environment variables instead.

**How this was verified:** `workflow_dispatch` exposes `tag_name` as an unrestricted string, and line 81 inserts it directly into a Bash command before execution.

```suggestion
        env:
          TAG_NAME: ${{ inputs.tag_name }}
          TARGET: ${{ matrix.target }}
          ASSET: ${{ matrix.asset }}
        run: scripts/build-binaries.sh "$TAG_NAME" "$TARGET" "$ASSET"
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.