The Fifth Third security model, end to end

Four building blocks make up the Fifth Third security model: the release key, the checksum manifest, the workspace entitlement and the marketplace API rate limits. This lesson walks through each in turn.

1. The Fifth Third release key

The release key lives in an HSM in a colocation rack in Frankfurt. Only two members of the editorial team hold the two-of-two ceremony smart cards. Every batch is signed in a scripted ceremony that produces a signed manifest of every module’s SHA-256 checksum alongside the signed APK.

2. The checksum manifest

The manifest is a text file with one line per module: module id, version, SHA-256 checksum, size in bytes. The manifest is signed with the Fifth Third release key and served on /security-whitepaper. The workspace app fetches the manifest before every install and verifies the downloaded APK against the manifest line.

3. The workspace entitlement

Every workspace has an entitlement record on the marketplace API. The record lists the modules provisioned to the workspace and the seat count. A module install cannot start without a valid entitlement — the workspace app refuses to launch the PackageInstaller.

4. Marketplace API rate limits

The rate limits described on the acceptable-use policy are enforced at the edge, in front of the API. A workspace that exceeds a limit gets a 429 response with a Retry-After header. Sustained abuse triggers a human review before any commercial consequence.

What the model does not do

The Fifth Third security model does not attest to the runtime behaviour of a module beyond what the editorial review captured. If a module ships an outbound network call that is not documented, the review process is meant to catch it — but a defense-in-depth reader should assume that only what the model verifies is verified.

The full Fifth Third security whitepaper lives at /security-whitepaper.