The problem
Why it matters.
A conventional HSM protects the key but signs whatever an authenticated build server sends. If the build server is compromised, malware can be signed with your real key.
With Roost
How Roost handles it.
01
Build serverSends a signing request for a release artifact.
02
Roost checks approvalIs there a passkey approval for this exact artifact hash?
NO APPROVAL
Refused, with the reasonLogged and alerted. The attacker gets nothing.
APPROVED
Signed by 2 of 3 chipsRecorded with who approved which build.
What you get
In the console.
- Release approval by passkey, bound to the artifact hash
- Signing limits: a sudden burst is stopped
- Every signature tied to an approved build in the audit chain
- Works with Java and PKCS#11 signing tools
AxowlacmeRoostM
Approvals
3pending
14approved this week
1refused
| Request | Detail | Seals | |
|---|---|---|---|
| Release 1.4.2 · code signing | Approve to sign build 842 | 1 of 2 | Approve with passkey |
| Issue certificate · api.acme.example | CA key · 2 of 3 security officers | 2 of 3 | Approve with passkey |
| Share key piece with backup box | ROOST-26-0003 joins the domain | 0 of 3 | Approve with passkey |
| Retire key version v1 | data-key · 0 records still on v1 | Done | Approved |
See Roost refuse an unapproved signature.
A 30-minute live demo with our engineers.