Assurance
How every release is built & verified
The codebase is private, so we won’t ask you to take "it’s well tested" on faith. This is the exact gauntlet every release runs — and, in the same spirit as the rest of this site, we tell you what gates a change versus what is still advisory while we harden it, rather than imply a guarantee that isn’t enforced yet. Licensed trusts also receive the source — this page is the summary, not the substitute.
Gates every change
A merge to the mainline must pass all of the following or it does not ship:
- Full test suite. Pest unit + feature tests, architectural boundary checks (deptrac), and code-style (Pint). A merge that breaks any of these does not ship.
- Dependency advisories. Every Composer and npm dependency checked against the advisory databases on every pipeline (and again daily on a schedule, so a newly-disclosed CVE surfaces within 24h, not at the next release).
- Wider CVE scan. OSV-Scanner across both lockfiles — a broader vulnerability database than the language-native audits alone.
- Secrets. gitleaks over the full git history — a credential committed and later deleted still fails the build.
- Our own code (SAST). Semgrep with the OWASP and language rule packs, plus bespoke rules that enforce this product’s hardest invariant: a query or model that isn’t scoped to one trust’s data fails review. This is the cross-academy-isolation guarantee, mechanically enforced.
- Deep static analysis. Larastan (strict) and Psalm taint-analysis — tracing user input to dangerous sinks across files — run on every merge against a frozen baseline of existing debt; any new finding fails the build.
On every pipeline — hardening toward gating
These run continuously and are reviewed but don’t block a merge today: DAST is being moved into the standard gate; the browser end-to-end suite runs nightly as a regression signal. We’d rather state that plainly than overclaim:
- Dynamic scan (DAST). A runtime scan of the running application for live misconfiguration and exposure. Advisory today; being moved into the standard gate.
- Browser end-to-end. Full browser journeys on a seeded instance.
Every release ships with
- Signed. Every release tarball’s SHA-256 digest is RSA-PSS signed; the installer verifies the signature before extracting — a tampered or substituted build is rejected.
- SBOM. A CycloneDX (an OWASP standard) software bill-of-materials ships with every release: the exact dependency set, so you — or your auditor — can answer “are we exposed to this CVE?” yourself.
- Provenance. An in-toto / SLSA (an industry supply-chain integrity framework) provenance statement records which commit and pipeline produced the artifact, so a substituted or tampered build is detectable.
- Security patches, regardless of maintenance. Security fixes reach every licensed trust whether or not maintenance is current — identified by a Keystone Security Advisory (KSA) id, on a channel independent of the maintenance contract, backported to the current and prior major for at least three years. Source-included is the perpetual backstop.
Detail on the security channel and the advisory process is in the procurement guidance and the FAQ.
Independent posture
Public-facing properties are independently scored and our control posture (encryption, audit-log integrity, access control, certification roadmap with honest dates) is documented on the security page. Accessibility is covered by the accessibility statement (WCAG 2.2 AA target).
Why we publish this
A risk-averse trust should be able to verify the engineering, not just be told about it. We can’t show you a wall of customer logos we don’t have yet — so we show you the machinery instead, accurately. If a claim here matters to your procurement and you want evidence, ask: request a private evaluation and we’ll walk you through it.