Scan generated Fleet artifacts for secrets

[iansltx]

Goal

User story
As a consumer of Fleet,
I want to ensure that Fleet binaries don't embed secrets or secret-looking artifacts
so that I can have better assurance of a cleaner software supply chain.

Original requests

Context: We're pulling crewjam/saml into fleetctl's binary because of transitive dependencies from fleetctl code. This caused a flag that's being fixed by crewjam/saml#646. A customer caught this via GitHub Enterprise secret scanning.

More context in Slack

Resources

Changes

Engineering

• Test plan is finalized
• Secret scanning has been added to binary artifact builds, with false positives excluded alongside documentation on the exclusions

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Risk level: Low

Test plan

• Inject a canary token into the build process and ensure secret scanning fails the build
• While waiting for Move key material from xmlenc fuzz.go to fuzz_test.go so it doesn't get compiled in crewjam/saml#646, add a documented exclusion for that particular 11024-bit RSA key, and ensure the build passes without it

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan.
2. QA: Added comment to user story confirming successful completion of test plan.

[lukeheath]

@sharon-fdm Moving this into waiting but assigning to you to take a look and determine when to prioritize. Unfortunately the context is expired in Slack, but I thought Orchestration may recall the details.

[sharon-fdm]

@lukeheath, looks like ready to spec. With all AI agents lurking at our code, this should be prioritized.
I got it.

[sharon-fdm]

Proposed spec

Add a step to the release workflows (goreleaser-fleet.yaml, goreleaser-orbit.yaml) that runs strings + Trivy on the built binaries before publishing, with an allowlist for the crewjam/saml key until the upstream fix lands.

• Reusable composite action (.github/actions/scan-binary-secrets/) so both workflows share the same logic
• Dedicated allowlist config (security/code/trivy-binary-secret.yaml) separate from the source-scanning one
• Canary test job that embeds a fake secret in a test binary to verify the scanner actually catches things

@lucasmrod TMWYT