Security answers

The twenty questions every program's security review asks about Attestia, answered once from the shipped product and kept current. This file is the one source: it is served at /security/answers and shipped in the pilot kit. Facts only; where something is not built yet, the story and task number say so.

Describes release 0.4.0, self hosted with the board's accounts in postgres, and says where the release after it adds something. Last reviewed 2026-09-27.

1. What data does the tool create, and where is it stored

Plain JSON files under tracker/ in the team's own git repository: the people list with sign in emails, the configuration, one story file per feature with its tasks, one log per person per day (sessions with the agent's runtime, model, and permission mode, entries, commits, hours as timed intervals), review records per change set (a merged pull request, a tagged release, or a commit shipped straight to main, whose commits inherit its review), with pull request approvals from the host kept as their own tier, the signer registry of public keys allowed to sign the record, the daily chain entries with their anchor receipts, what the git host enforced on the default branch and what CI recorded for each commit (read at each close with the Ledger on), and, when a policy is in force, the policy file, recorded exceptions, and break glass entries. Nothing about the record lives anywhere else. The hosted board's Postgres holds sign in accounts, share links, onboarding rows, and an audit log of who viewed what.

2. What leaves the boundary

Self hosted, with the anchor inside the boundary: nothing. Hosted, or self hosted with the public anchors: one hash per close, thirty two bytes, to the Sigstore transparency log and an OpenTimestamps calendar. No file content, no names, no prompt text, no code leaves in either mode.

3. Who can read the record

Anyone with read access to the repository, because the record is files in it. The board shows the same files to people listed in people.json after they sign in; it adds nothing a reader of the repository could not already see. Share links are read only, unguessable, revocable, and off in the pilot configuration. The hosted board and the connector refuse a marked record: both answer not found, as for a record that does not exist, so a marked customer runs self hosted or air gapped.

4. What credentials the tool holds

A signing identity per person: the machine's own SSH key by default (in 0.4.0 made without a passphrase if none exists; from the release after it, held in the ssh agent and never in a key file), or gitsign's short lived certificate, or a GPG key the program manages. A service account token for the self hosted board, with read access to the repositories; write access to issues only where tasks and Ask are wanted. The hosted board uses a GitHub App instead. Sessions carry no credential of their own: a session is attributed to the person who directed it.

5. How the record is protected from alteration

Every tracker commit is signed once the Ledger is on. Every close writes a chain entry hashing the files it wrote and the entry before it. Each entry is anchored outside the repository with a receipt stored beside it. attestia verify replays all three offline and prints a verdict; a rewritten history, an edited closed file, or a missing receipt each fails a named line. Signatures are checked against the signer registry the record carries, tracker/signers.json, so a clean clone verifies them with no setup, and a signature by a key the registry does not list is reported as not verifiable rather than as good.

6. Which cryptography

FIPS approved algorithms, each named. SHA-256 (FIPS 180-4) for every content hash in the record and for the chain. ECDSA P-256 (FIPS 186-5) for the signatures on anchor receipts, from Rekor and from the self hosted log, and for signing keys under the fips setting. Ed25519 (FIPS 186-5) for the default SSH signing keys. Attestia ships no cryptographic module of its own and claims none: on a host in FIPS mode, the runtime's validated module does the work. From the release after 0.4.0, fips: true in the configuration requires that mode for check, doctor, verify, export, and the nightly close, refuses gitsign (its signatures are made by the Sigstore client, outside the host's module), and requires ECDSA P-256 keys.

Every content hash in the record is SHA-256. Git's object ids, SHA-1 in most repositories, are carried as references only: verify checks the SHA-256 of every file a close recorded, never the git id. Repositories in git's SHA-256 object format are supported from the release after 0.4.0.

7. Whether prompts, code, or CUI are sent to any AI service

No. The tool records the sessions; it is not the AI service and never calls one. Prompt text is not stored in the repository unless the team turns storePrompts on, and the pilot configuration leaves it off.

8. Does it call out to the internet

Only to the anchor, which can be inside the boundary, and to the npm registry if the team installs the command line tool from it rather than from the offline tarball. The self hosted board calls the program's own git host and nothing else.

9. What happens if it is removed

The record remains in git as plain files that any reader can open; verify still runs from the tarball against them. Nothing else depends on the tool.

10. How updates are delivered and verified

Signed releases: the tarball with SHA256SUMS, a signature over it, the key to verify with, and a bill of materials; the container images by digest, never by tag alone. Check the sum and the signature before installing.

11. What logging the tool itself does

The board keeps an audit row per read through the connector and per page view by a signed in person: who, which board, when. It never logs session content, prompts, or code.

12. Does it block engineers

Three narrow cases, each logged, each with a break glass that lets one action through and never disables the rule: a session under a model the policy denies does not start; a tool the policy denies is refused; a commit with no session identity behind it fails the check once the Ledger is on. A change to a protected path without a review fails the check unless an approver records a time limited exception. Everything else is advisory: shown, never blocked. The pilot's default policy protects no paths, so on day one only the identity rule can stop anything.

13. Software bill of materials

Generated per release in CycloneDX form and included in the release and the archive. The command line tool has no dependencies.

14. Vulnerability disclosure

Email security@truestate.space. We read every report and reply within two business days, and we tell the reporter what we found and when it shipped.

15. Is it FedRAMP authorized

Self hosted inside the boundary, it runs under the program's own authorization; nothing of ours is in the path. The hosted board is not part of a federal pilot and is not FedRAMP authorized.

16. Personnel

Who at Attestia can access a pilot's data: nobody, in self hosted mode. There is no telemetry, no support tunnel, and no account of ours in the program's systems.

17. Data retention on our side

None, in self hosted mode. In hosted mode the board holds the account rows described in answer 1 until the team asks for their removal.

18. Licence and rights

The record format is documented in the product package and the program owns every file in its repository; the format has no licence of its own. The command line tool is MIT licensed. The board's source is the program's to run under the pilot agreement.

19. Support

Email the address above. attestia doctor is the first step: it prints one line per check (hooks, scheduler, person, the App or service account, the last close, the signer, the anchor) and says what to do. Attach its output.

20. Roadmap items a program may be waiting on

• Signing keys held in AWS KMS or Azure Key Vault Managed HSM: story 013 tasks 33 and 34.
• The OpenTelemetry export for runtime observability tools: story 013 task 20.
• Runtime adapters beyond Claude Code (Codex, Cursor, Gemini CLI, Windsurf): story 013 task 24.
• Import into a commercial compliance platform. The OSCAL export is built and passes every check we can run ourselves: the reference validator, a profile resolve against the live catalog, an independent schema validator, a typed model library, and an open source viewer. Import into RegScale or Paramify is gated behind their sales process, so it is proven at the first partner or pilot rather than by us.

Built since the last review, and no longer on this list: the receipt per commit and blame from a file to its session (story 013 tasks 17 and 18), the OSCAL export itself (task 14), reading what the git host enforces on the default branch and what CI recorded for each commit into the record (tasks 37 and 38), correction entries for a sealed day that differs only by line endings, the nightly close running on the host's schedule (task 35), review by change set rather than by commit, and the signer registry that lets a clean clone verify every signature. In the release after 0.4.0: the marking with its designation on the record, every export, and every printed page, the fips setting, and each person's signing key held in the ssh agent rather than a key file (story 013 task 23). install --sign makes a new key straight into the agent or moves an existing key file into it, and doctor fails a key kept on disk. On Windows the agent service keeps its keys across restarts; on macOS and Linux the session agent holds them until logout, after which install --sign makes and registers a new key, and the old key stays in the signer registry so what it signed still verifies.

CUI and CTI

If the repository holds source with a military or space application it is controlled technical information and must be protected at moderate confidentiality and integrity. In that case, from the release after 0.4.0, the record is marked: config.json carries the banner with its designation line, both printed on every page of every export and printed document, and the marking changes only through a commit signed by a key in the signer registry. The hosted board and the connector refuse a marked record, so the program runs Attestia self hosted or air gapped. Share links are off, prompts are not stored, and the anchor is inside the boundary; check and doctor fail a marked record that has any of them. Where the program needs FIPS mode, the fips setting holds the record to it, as answer 6 says.