Security and development practices¶
This page is for security, risk and procurement reviews. It describes how HD is written, checked, built and delivered, and what you can verify yourself. The data HD shares with FermiHDI, which is nothing unless you opt in, is covered in Data handling and opt-in. The open-source components and their licences are in Third-party software and licences.
Where the code is written and kept¶
HD's source code is written and housed one step removed from its developers, in a secure enclave. Developers work against the enclave rather than holding the code on their own machines, so a lost or compromised laptop does not carry the product's source with it. Every change reaches the product through a reviewed pull request.
What checks every change¶
Four independent systems examine the code and its dependencies before and after a change merges:
| System | What it checks |
|---|---|
| Macroscope | Reviews each pull request for correctness defects: logic errors, concurrency and resource-lifetime faults, broken edge cases. Findings are answered in the pull request and resolved before it merges. |
| Aikido | Scans the source, dependencies, container images, infrastructure definitions and CI workflows for vulnerabilities, leaked secrets, insecure code patterns and end-of-life software. |
| Renovate | Keeps dependencies, base images and CI actions current by opening update requests, so security fixes upstream reach HD promptly. |
| Trivy | Scans the container images for known vulnerabilities in the operating-system packages and libraries they contain. |
Release 2.0.5 security work¶
The 2.0.5 release closed the findings those systems raised against the code that ships:
- Dependencies. Components with published advisories were updated, including the gRPC, WebSocket and JWT libraries in the Go services, and the web framework, sanitiser and image libraries in the web applications. The few that no update yet resolves, and that HD cannot reach, are covered by the exploitability statements below.
- Web applications. Diagrams render with the strictest setting of the diagram library and are sanitised before display. Data Explore accepts only plain column names, a fixed set of operators and whole-number bucket widths when it builds a query.
- Services. Every HTTP server bounds how long a client may take to send its request headers. Keys and certificates are written only to private, uniquely named locations. The crash vault's management interface refuses every request until its access token is configured.
- CI and supply chain. Every third-party build action is pinned to an exact commit, build jobs do not keep repository credentials they do not need, and release workflows treat their inputs as data rather than script.
- Kubernetes defaults. The management and query services run without privilege escalation, without raw-socket access and under the runtime's default system-call filter. The engine roles keep only the elevated access they need to drive network cards and storage devices directly.
Findings that do not apply to HD as delivered, such as a test fixture or a vendor sample program that is never built, are recorded in the scanners with the reason, not left open. Findings in operating-system packages of the images are addressed by rebuilding on current base images, and are described per release in the vulnerability exploitability statements below.
Signed images¶
Every HD release image in cr.fermihdi.io/hd, from 2.0.5 on, is signed with FermiHDI's cosign key, and signing is part of publishing a release. The signature is stored beside the image in the registry, and it is deliberately not written to the public Sigstore transparency log, which would publish your image names and tags. The public key is at https://keys.fermihdi.io/cosign.pub.
Verify an image before you deploy it:
curl -fsSLO https://keys.fermihdi.io/cosign.pub
cosign verify --key cosign.pub --insecure-ignore-tlog=true \
cr.fermihdi.io/hd/dms-core:2.0.5-ub2604
The --insecure-ignore-tlog flag tells cosign not to look for a transparency-log entry. It does not weaken the check against the key.
Provenance in every image¶
Every image carries three labels naming exactly what it was built from:
| Label | Value |
|---|---|
org.opencontainers.image.source |
The source repository |
org.opencontainers.image.revision |
The commit |
com.fermihdi.git.branch |
The branch that carries the commit (detached on 2.0.5 images, which were built from pinned submodule checkouts; the commit identifies the source either way) |
Read them with docker inspect --format '{{json .Config.Labels}}' <image>. Every repository commit that makes up a release is tagged with the release version, so a label resolves to one reviewed commit.
Vulnerability exploitability (VEX)¶
A scanner lists every known vulnerability in every package an image contains, whether or not HD can reach it. For each release, FermiHDI publishes OpenVEX statements for the findings that do not affect HD, for example a vulnerable command-line tool in the base image that HD never runs, with the reason. They are attached to each image in the registry as signed attestations and published beside the release downloads. Scanners that read OpenVEX, Trivy among them, use them to show only the findings that matter:
cosign verify-attestation --key cosign.pub --insecure-ignore-tlog=true \
--type openvex cr.fermihdi.io/hd/dms-core:2.0.5-ub2604
Security built into the product¶
- Mutual TLS everywhere. Every node and service proves its identity with a certificate issued by the deployment's own certificate authority, chained to FermiHDI's root. Node certificates renew themselves in place before they expire.
- Three separate planes. Management traffic, record traffic and observability traffic use separate ports, and records never cross the management plane. See the operators manual and the FHDWP network guide.
- Your identity provider, your front doors. HD does not hold user passwords. People and service accounts are authenticated by the reverse proxies you run, and HD authorises on the identity they pass on. See The front doors.
- Licences bound to the deployment. A licence is encrypted and bound to the DMS it was issued for, and capacity is enforced.
- Nothing leaves by default. No telemetry or crash data leaves your deployment unless you turn sharing on. See Data handling and opt-in.