PersonixHealth exists because of one observation: automated systems have become extraordinarily good at deciding, and they remain surprisingly bad at doing. In healthcare, that gap shows up as an AI that can reason brilliantly about care but cannot book an appointment. This statement is about the same gap in a different place — one most software teams live with every day and have stopped seeing.
The practice nobody defends, everybody follows
To ship software that operating systems trust, a developer signs it with a private key bound to their identity — for macOS, an Apple Developer ID certificate. The industry’s standard practice for automating this is blunt: export the certificate and key as a file, encode it, and paste it into the build system’s secrets. Every build then reconstructs the private key inside the build environment to sign with it.
Stated plainly: the developer’s signing identity exists as a readable string inside an environment that routinely executes other people’s code. Build pipelines pull hundreds of dependencies, run third-party actions, and execute on shared or loosely-maintained runners. Anyone who can edit a workflow file, any package with an install script, any compromised build action can read the key out in one line. Security teams that would never leave a database password in plaintext accept this for the credential that speaks as the company itself.
The failure mode is uniquely painful. Signed malware inherits the victim’s reputation: Gatekeeper and notarization wave it through, because cryptographically it is the victim’s software. And the remedy makes it worse — revoking the certificate invalidates every legitimate build ever signed with it. Customers’ installed software breaks retroactively. The blast radius reaches backward in time.
Process can’t fix a custody problem
The instinctive responses — rotate the secret, restrict the workflow, audit the runners — all accept the premise that the key must be present in the build. They harden the perimeter around a credential that shouldn’t be there at all. As long as the key exists as data in the pipeline, the pipeline is the attack surface.
The correct answer is custody: the key should be generated inside hardware and never exist anywhere else. Not exported, not backed up, not readable — physically incapable of traveling. The build system should hold no credential at all. It should present its identity — this repository, this branch, this workflow, this actor — and a governed service should decide, under policy, whether to exercise the key on its behalf. Every decision should leave evidence: what was signed, from which commit, producing which artifact, verified by which notarization. Releases should be provable facts.
Why a healthcare infrastructure company built this
Because it is the same product. PersonixHealth builds governed execution infrastructure — systems that exercise high-stakes capabilities on another party’s behalf, under policy, with provable evidence. In healthcare, the capability is access to care and the consumer is an AI platform. In software delivery, the capability is a signing identity and the consumer is a CI pipeline. Different industries; identical architecture: separate the authority to request an action from the ability to perform it, govern the boundary, and record everything.
That product is SignetKeys: hardware-custody Apple code signing as a service. Keys are born on hardware tokens and attested never to have existed as files. Pipelines authenticate with short-lived workload identity — zero stored secrets. The full Developer ID release flow — sign, notarize, staple, verify — runs under policy, and every release carries a tamper-evident evidence chain. We built it first for commercial audio plugin and macOS developers, the teams shipping under the strictest signing regime in software.
The supply chain doesn’t need another scanner. It needs fewer credentials lying around to steal. Starting with the one that signs your name.