Release Assurance
We build security tooling — so we hold our own code to the standard we audit everyone else against. Nothing reaches a customer on the strength of “it worked on my machine” or a green checkmark someone eyeballed. Every line of code, and every downloadable, installable artifact, is put through a layered, evidence-based certification pipeline first.
The artefact you download must be built, validated, certified, hash-bound, published and evidenced. The whole process exists to prove one thing that is easy to assume and hard to demonstrate: that the artefact you receive is the same artefact that passed certification.
Principles
A release is approved by measured results, not judgement. Every gate emits a machine-readable artifact — a coverage number, a static-analysis result, an install log, a signed checksum, a software bill of materials. If we can’t show the evidence, we don’t ship it.
Evidence may be customer-visible or internally retained, but it must exist. Internal evidence may stay internal; it must still be kept. Evidence that was never generated is not internal evidence — it is missing evidence.
Most vendors test their source. We take the actual .deb, .rpm, or .msi a
customer downloads, install it on a clean machine, boot it, log in, and drive every page — and we keep the
receipts. Code that passes tests but won’t install cleanly is not “done.”
Authority
A certification model needs a single authority for what “certified” covers, or it quietly becomes whatever the pipeline happened to check. Each product carries a release contract declaring its supported artefacts, the platforms they must be validated on, which evidence is customer-facing and which is internal, the capabilities that must be exercised, and the checks that must be green.
The Pipeline
Eleven stages, each emitting evidence, between a developer’s keystroke and your download.
Local hooks run formatting and lint (Black, isort, flake8), PowerShell analysis (PSScriptAnalyzer), shell linting (shellcheck), a secret scanner that blocks keys and credentials, and a “no new inline frontend” ratchet.
GPG-signed commits, an enforcement-version check, and a manifest guaranteeing managed files are committed. Deep security and dependency gates run before code ever reaches the server.
Tests + coverage — the full suite runs, and a self-calibrating coverage gate blocks any regression below the committed floor. Python — Bandit (security patterns), ruff. PowerShell, the code that runs elevated on customer machines — PSScriptAnalyzer + InjectionHunter catch injection, plaintext credentials, and unsafe execution; Pester runs unit tests; a syntax gate parses every single script. Dependencies + deprecated code — every release runs pip-audit (Python) and npm audit (JavaScript) to flag known-vulnerable packages, and scans our own source for deprecated APIs (e.g. calls scheduled for removal in a future language runtime) — blocking them, so a deprecation is fixed in the release that introduces it rather than discovered when an upgrade breaks it. A weighted OWASP scorecard is computed every run and published as evidence.
Static analysis. Every product’s source is scanned for security anti-patterns — injection, unsafe execution, hard-coded credentials, dangerous deserialization — with Bandit (Python) and PSScriptAnalyzer + InjectionHunter (PowerShell, the code that runs elevated on customer machines).
Static-analysis evidence is generated and retained on every release. It is classified as internal assurance evidence by default — the raw scanner output is a working artefact, and a release only attaches it where that product’s release contract says so. Its absence from a release is not a gap; its absence from our records would be.
Supply-chain vulnerability scan. We take the CycloneDX SBOM of exactly what ships — built from the offline wheelhouse, so it lists real pinned versions, not a guess at the source tree — and scan it with Grype against the OSV and GitHub advisory databases. Precise package-and-version matching surfaces genuinely known-vulnerable components without the false positives that fuzzy scanners produce. Together these answer both questions: is the code safe, and is anything we bundle known-vulnerable.
A release may only proceed if the release commit exists on the product’s trunk branch, is the commit actually being built, and every workflow named in that product’s release contract has a run for that exact commit which concluded success.
No run is a failure, not a pass. A named workflow that never ran against the commit fails the gate, and so does a named workflow that does not exist — absence is never treated as success. Evidence from a different commit is not accepted. This exists because a release pipeline’s own jobs going green proves only that the pipeline ran.
Every gate above is aggregated into a single release decision plus a complete evidence bundle — static analysis, security, tests, quality score, and a human-readable report. The decision comes from the gates’ actual results, not an arbitrary score.
Dependency advisories are split by whether a fix exists. An advisory with a fix available blocks the release — leaving it would be a decision not to apply a fix that exists. An advisory with no fix available is recorded, reported and carried in the evidence, but does not block, because a gate nobody can satisfy gets bypassed rather than obeyed. The two are counted separately so the difference stays visible.
Artifacts ship as native OS packages: Linux .deb/.rpm (each with an offline
wheelhouse for air-gapped installs), signed Windows MSI, and signed, notarized macOS
packages. Docker is a build-and-test sandbox only — never the deployment format.
Each build also emits a CycloneDX Software Bill of Materials (SBOM) describing exactly what ships. For packages that carry an offline wheelhouse, the SBOM is generated from the shipped wheelhouse — so it lists the real, pinned dependency versions in the artifact you download, not an approximation of the source tree.
Every artefact in the release contract must be certified — or removed from it. A package format that
appears in the contract but cannot be certified is not published unvalidated; it is withdrawn from the contract by a recorded
decision. Certifying a .deb to a high standard is not evidence about the .rpm beside it in the same
release.
Every artefact listed in the release contract is certified independently, on a clean host of its own platform. Platform-specific defects are invisible from the other platform: a package can install perfectly on one distribution and, on another, install a product with no account to log in as. Certifying on the platform the artefact actually ships to is not thoroughness — it is the only way those defects are visible at all.
For every artifact and every package format we:
A package that won’t install, a page that errors, a broken link — each is a release blocker, caught here, before a customer ever sees it. A package that installs but cannot perform the function it claims does not pass certification.
Validation validates artefacts. Publication publishes artefacts. Publication must prove they are the same artefacts:
validated SHA256 == published SHA256The hashes recorded when the artefact was certified are recomputed from what is actually being attached, and publication fails closed if the hash manifest is missing, the validation report is missing, the validation decision is not a pass, any attached artefact’s hash differs from the validated one, a validated artefact is absent from the release, or an artefact is attached that the manifest does not list. There is no advisory mode.
Without this binding, a rebuild between proving and publishing goes undetected and the release carries evidence describing a different binary. That is not a hypothetical: it is the specific failure this control exists to make impossible.
Every artifact is signed — GPG for Linux, code-signing certificates for Windows, Apple codesign + notarization for macOS.
Tags are annotated, signed, created by the release pipeline, and bound to the certified commit. Build once, prove that build, then tag and publish the same bytes. A tag records that a proven build exists; it never triggers an unproven one. A failure before the tag costs no customer-visible version number.
Required customer evidence is generated as part of the release itself, not assembled afterwards. A release must not succeed if required customer evidence was never generated — the gate treats a missing member as a release failure rather than a documentation gap to be filled in later.
Evidence
Not all evidence is for customers. Some exists so that we can certify, audit and investigate. Judging one by the other’s rules produces false conclusions in both directions — internal diagnostics reported as a customer-facing gap, or a genuinely absent customer document excused as “internal.”
Intended to reach you, attached to the release or inside an attached archive:
Supports certification, audit trail and root-cause analysis. May stay internal:
“Internal” means not shipped. It does not mean not kept. Evidence that was never generated is not internal evidence — it is missing evidence.
Governance
A certification model is only as good as the controls that stop it drifting. These rules are defined once and consumed everywhere, rather than restated per product — so a product cannot quietly hold a weaker version of the same rule.
What each stage owns, and where a failure in one does not silently invalidate another.
Build once, prove that build, then tag and publish the same bytes. A tag records a proven build; it never triggers one.
Validated SHA256 must equal published SHA256, with certification scope defined per artefact. Fail-closed, no advisory mode.
Which evidence is customer-facing and which is internal, and how a release is judged against both.
Where We Are
The hash-bound model described on this page is the standard every product in the estate is being brought under. It is not a description of every product today, and we would rather say so than let you infer otherwise from a page written in the present tense.
Ladian is the proven reference implementation — certified end to end under this model, with both its
.deb and .rpm installed and exercised on clean hosts of their own platform, hash binding verified, a
signed annotated tag cut by the pipeline at the certified commit, and downloaded customer artefacts whose checksums matched the
certified ones. Propagation to the rest of the estate began on 9 August 2026 and is sequenced product by product.
Earlier stages of this pipeline — the local and pre-push controls, continuous integration, static and supply-chain analysis, native install validation and cryptographic signing — have been in force across products for longer. The stages being rolled out are the newer ones: the release-contract authority, the commit integrity gate, hash-bound publication and the release-bound evidence gate.
Ask us where any specific product stands. We will tell you which stages it currently satisfies rather than point you at this page.
Across the Product Suite
The audit consoles, asset and exposure centres, and CMDB run the full stack: tests + coverage, Bandit static analysis, an SBOM-based dependency vulnerability scan, the OWASP scorecard, and the authenticated install-and-crawl proof on native packages.
Heavily PowerShell, so they get the security-focused treatment: PSScriptAnalyzer + InjectionHunter, Pester tests, and a full syntax gate on every script.
Whatever the language, each is certified to the same end state: a signed, native artifact, installed on a clean host and driven through its real UI — with the evidence to prove it.
What It Means For You
Every release certified under this process is statically analysed, vulnerability-scanned, dependency-audited, deprecation-checked, coverage-gated, security-scored, SBOM-inventoried, cryptographically signed, installed and exercised end-to-end on a clean host of its own platform, hash-bound to its certification, and tracked by a release contract — and publishes the signed SBOM, vulnerability report, build hashes and signed evidence manifest that evidence it. What any given release carries is set by that product’s release contract, and its release page lists exactly what is attached, so you can check before you download rather than take our word for it.
The difference hash binding makes is narrow and decisive. Plenty of pipelines can tell you an artefact passed every gate. Fewer can prove that the artefact you just downloaded is that same artefact, rather than a rebuild that happened afterwards and was never validated at all.
Every release publishes signed artefacts, an SBOM and a vulnerability report. Browse any product’s release page to see exactly what it carries, or ask us about the certification bundle for any product.