Trinity

The project has published no releases. It is pre-alpha and distributed as source, so there is no older version to maintain and no upgrade path to document yet.

GitHub Issues is enabled and in use for tracking individual issues: https://github.com/ScriptKittyOS/Trinity/issues

No vulnerability has been reported or resolved in the last 12 months. SECURITY.md commits in advance to crediting reporters in the release notes unless they ask otherwise.

SECURITY.md documents where to send a report, what to include, the acknowledgement target, the coordinated disclosure expectation and how credit is given: https://github.com/ScriptKittyOS/Trinity/blob/main/SECURITY.md

docs/03-conventions.md identifies the conventions for the primary language (Elixir) and requires compliance: https://github.com/ScriptKittyOS/Trinity/blob/main/docs/03-conventions.md

Enforced automatically on every commit by the gate: mix format --check-formatted for the standard Elixir formatter, and mix credo --strict --all for the style and consistency rules. A change that does not comply fails the build.

The native parts of the build honour the toolchain's own variables rather than replacing them: the packaging workflow sets CARGO_TARGET_*_LINKER and the Rust toolchain is read from rust-toolchain.toml, and the build extends these rather than overriding values passed in. The BEAM half of the build has no CC/CFLAGS equivalent, since Elixir compiles to bytecode rather than native objects.

Debug information is preserved by the build. The project strips it explicitly and only where it must: its core policy hash is computed over stripped bytecode, because the debug chunk varies between builds; the build itself strips nothing.

The build system is Mix, which resolves the whole application as one dependency graph rather than recursing into subdirectories.

Measured rather than asserted; method and result are in https://github.com/ScriptKittyOS/Trinity/blob/main/docs/packaging.md . Two forced MIX_ENV=prod mix compile --force runs over the same tree: 219 of 243 compiled modules are byte-identical, and the 24 that differ do so only in the Dbgi (debug info) and ExCk (compile metadata) chunks. The Code chunk, the executable bytecode, is identical in all 243 modules, so the compiled behaviour is reproducible. The residual variation is a known property of the BEAM toolchain rather than of this project, and the project already accounts for it: its core policy hash is taken over stripped bytecode for exactly this reason.

Two conventional paths. A single self-contained binary per platform, built and smoke-tested on Linux, macOS and Windows; and the standard mix path from source, documented in the README. Uninstalling the binary is deleting it, as it carries its own runtime.

The software is delivered as a single self-contained binary with no POSIX installation step, so there is no DESTDIR or prefix convention to honour.

asdf install reads the pinned toolchain from .tool-versions, then mix setup installs dependencies, creates the database and builds assets; mix test then runs the full suite. Both are commonly-used conventions in this language and both are in the README.

Dependencies are listed computer-processably three ways: mix.exs and mix.lock (the language's own machine-readable manifest and lock file), VERSIONS.md with the pin for each and the reason it was chosen, and a CycloneDX software bill of materials generated by the build on every commit and shipped alongside every packaged binary. The bill states its own coverage inside the document. See https://github.com/ScriptKittyOS/Trinity/blob/main/VERSIONS.md

mix hex.audit and mix deps.audit run as gate steps on every commit, so a dependency with a known advisory fails the build. Dependabot is enabled for further alerts. Known unfixed advisories in dependencies are recorded in the public risk register with their scope and the condition that would close them, rather than left in an alerts tab.

Every reused component is a standard Hex package resolved by the language's own package manager, pinned in VERSIONS.md and verified against the lock file by the build. There are no vendored convenience copies of third-party source in the tree.

Dependencies are tracked to current stable releases and the choice of each is recorded with the date it was measured. A retired package carrying an open cross-site scripting advisory was identified and replaced rather than pinned around.

mix gate runs on every push and every pull request, on the shared repository, and reports success or failure as a required check. It runs formatting, a compile with warnings as errors, the architectural boundary check, a release build check, static analysis, dependency and licence audits, the full test suite and a coverage floor.

Policy in docs/03-conventions.md: a fixed defect gets a regression test naming it, committed failing first so that it is demonstrated to discriminate, with the fix commit referring to it. Applied well above half: recent examples include a release-only compile failure, a biased random-code generator and a workflow token scope, each of which gained a test in the same change as its fix.

Statement coverage is 80.31%, measured by the language's own coverage tool as part of the build. The figure for every increment is recorded in coverage.tsv in the repository root and the build enforces a floor against it, so a drop fails rather than passes quietly.

A written policy, not a habit: the Tests section of docs/03-conventions.md states that major new functionality is accompanied by tests for it in the automated suite, in the same change: https://github.com/ScriptKittyOS/Trinity/blob/main/docs/03-conventions.md

CONTRIBUTING.md states the policy in its instructions for change proposals: major new functionality comes with tests in the same change, and a fixed bug gets a regression test naming the defect: https://github.com/ScriptKittyOS/Trinity/blob/main/CONTRIBUTING.md

The build compiles with --warnings-as-errors, so any compiler warning fails it. Credo runs in strict mode with all checks enabled, and the architectural boundary checker is a compile-time enforcement rather than a lint.

The assurance case carries a table mapping each classical secure design principle to the specific place in the tree where it is realised, so the claim can be checked rather than believed: economy of mechanism (one side-effect membrane), fail-safe defaults (an unrecognised tool tier asks for approval; no approved algorithm means the effect is refused), complete mediation (approvals are re-derived from a canonical hash of the exact call at execution), least privilege, separation of privilege (identity is separate from authority), open design, and defence in depth. https://github.com/ScriptKittyOS/Trinity/blob/main/docs/10-assurance-case.md

No SHA-1, no ECB, and no unauthenticated cipher modes anywhere in the project's own code; a test sweeps the tree for them on every commit. Signatures are Ed25519, or ECDSA P-384 when FIPS mode is enabled; the authenticated-encryption construction is AES-256-GCM. These are measured inside a FIPS-mode container on a dedicated build leg rather than asserted.

The signing algorithm enters through a single seam and is selected at boot, with the choice bound by a key registry row rather than by anything embedded in the signed records: Ed25519 by default and ECDSA P-384 under FIPS. Keys can be rotated without changing code, and records name the key that signed them, so a switch does not invalidate what came before.

Private keys and credentials live in files in the data directory, separate from configuration, databases and logs, and can be replaced without recompiling. The build refuses a commit containing secret material, and tests assert that no token material appears in records or in model context.

All outbound network communication uses TLS through the runtime's own TLS implementation. The floor is TLS 1.2 (the default set is 1.3 and 1.2) and the project does not lower it. This is pinned by a test that asserts the runtime's supported versions rather than the sentence in the README.

TLS 1.3 and 1.2 are the supported versions; 1.1 and 1.0 are available in the runtime but are not in the default set and the project does not enable them. Asserted by a test against the runtime rather than documented.

Certificate verification is on by default for every TLS client in the project. There is no verify_none, and no option disabling verification, anywhere in the tree.

As above: verification is performed by default on every connection, so it necessarily precedes any request carrying credentials. No code path sends credentials over an unverified connection.

The project has published no releases. It is pre-alpha and distributed as source; packaged binaries are built and smoke-tested on three operating systems on every change to a packaging input, but none is published for general use. Every packaged artifact already carries build provenance attested through the build workflow's own identity and recorded in a public transparency log, verifiable by whoever holds the binary. Signing releases with a project-held key is scheduled work in the release pipeline (see https://github.com/ScriptKittyOS/Trinity/blob/main/ROADMAP.md, milestone M6) and will be in place before any release is published.

Everything arriving from outside the machine is labelled untrusted at the boundary, carrying its origin, a source reference, a digest and a taint that summaries inherit, and is never treated as instruction. Tool arguments are validated against a declared schema and malformed arguments are denied rather than repaired. Filesystem paths are validated against configured roots and a path escaping its root is rejected rather than normalised. Protocol tokens are validated for issuer, audience, expiry and not-before against an algorithm allow-list.

Memory-safe languages throughout (Elixir on the BEAM, Rust in the desktop shell, no C or C++ of the project's own). Beyond the language: one compile-time side-effect membrane that runtime-registered code cannot enter, approvals bound to a canonical hash of the exact call, iteration and token and wall-clock caps owned by the code rather than passed in as arguments, and build tokens narrowed to read with writes declared per job.

docs/10-assurance-case.md is a structured argument with all four parts this criterion requires: a threat model naming five adversaries and the capability assumed for each, and what is explicitly outside it; the trust boundaries stated rather than referenced; an argument that secure design principles were applied, mapped principle by principle to where each is realised in the tree; and a table of common implementation weakness classes with the counter for each and the limit stated where a counter is incomplete. It then decomposes the top-level claim into ten claims, each with argument, checkable evidence and its limit. https://github.com/ScriptKittyOS/Trinity/blob/main/docs/10-assurance-case.md

Sobelow, a static analysis tool built for this language's web framework and its common vulnerability classes, runs as a gate step on every commit and fails the build on a finding. Credo in strict mode and the compiler with warnings as errors run beside it, and the architectural boundary checker rejects a call that crosses a layer at compile time.

The project's own code contains no memory-unsafe language: the application is Elixir on the BEAM and the desktop shell is Rust, both memory-safe, and there is no C or C++ written by this project.