The published release binaries are unsigned on both macOS and Windows. This is the single biggest obstacle to deploying numbat across a managed corporate fleet, and it causes concrete problems with the endpoint security tooling numbat is meant to sit alongside.
Looking at the v0.1.2 release artifacts:
macOS — the darwin-arm64 binary is ad-hoc/linker-signed with no Team Identifier, and darwin-amd64 is unsigned outright. Neither is notarized.
Windows — numbat_windows_amd64.exe carries no Authenticode signature (no certificate table in the PE).
PS> Get-AuthenticodeSignature .\numbat.exe | Select Status, SignerCertificate
Status : NotSigned
SignerCertificate :
Why this matters for fleet deployment
macOS binary authorization. Tools in this space (Santa and equivalents) allow execution based on, in preference order, Team ID → Signing ID → CDHash → SHA-256. With no signature, the only option is a SHA-256 rule pinned to one exact build. That means:
- a new allowlist rule must be created and propagated for every release;
- between a package rolling out and the rule syncing, the binary is flagged or blocked on every host;
- fleets running in lockdown mode can't deploy numbat at all without per-release manual work.
A Developer ID signature collapses all of that into a single permanent Team ID rule.
For Windows AV heuristics, Unsigned Go binaries that spawn child processes and read process/command data are a strong match for PUA/cryptominer heuristics. Code signing is the standard mitigation — it doesn't guarantee no detection, but it's what makes a vendor allowlist submission viable and dramatically reduces heuristic hits. Unsigned binaries also trip SmartScreen.
What we're asking for
- macOS — sign with a Developer ID Application certificate and notarize/staple release binaries. Publishing a stable Team ID in the release notes would let operators write one durable rule.
- Windows — Authenticode-sign the .exe with a code signing certificate (OV or EV; EV additionally helps with SmartScreen reputation).
- Both — keep the signing identity stable across releases, since the whole benefit is that downstream allowlists stop being per-build.
The published release binaries are unsigned on both macOS and Windows. This is the single biggest obstacle to deploying numbat across a managed corporate fleet, and it causes concrete problems with the endpoint security tooling numbat is meant to sit alongside.
Looking at the v0.1.2 release artifacts:
macOS — the darwin-arm64 binary is ad-hoc/linker-signed with no Team Identifier, and darwin-amd64 is unsigned outright. Neither is notarized.
Windows — numbat_windows_amd64.exe carries no Authenticode signature (no certificate table in the PE).
PS> Get-AuthenticodeSignature .\numbat.exe | Select Status, SignerCertificate
Status : NotSigned
SignerCertificate :
Why this matters for fleet deployment
macOS binary authorization. Tools in this space (Santa and equivalents) allow execution based on, in preference order, Team ID → Signing ID → CDHash → SHA-256. With no signature, the only option is a SHA-256 rule pinned to one exact build. That means:
A Developer ID signature collapses all of that into a single permanent Team ID rule.
For Windows AV heuristics, Unsigned Go binaries that spawn child processes and read process/command data are a strong match for PUA/cryptominer heuristics. Code signing is the standard mitigation — it doesn't guarantee no detection, but it's what makes a vendor allowlist submission viable and dramatically reduces heuristic hits. Unsigned binaries also trip SmartScreen.
What we're asking for