What remains to be built

This page names what the product aims for and does not yet deliver. It has two sources: what the V3 security white paper itself describes as in progress, and the areas the white paper does not cover, whose specifications live in the repository. What the white paper states as a commitment or a guarantee does not appear here: those points are described in the pages that cover them, including Supply chain and Compliance posture.

This page gives no dates, no delivery commitments, and no detail that would help attack the product.

Two rules apply:

• no legal advice: the fact that an area remains to be built is an engineering observation, not a compliance assessment;
• no claim without traceability: each point refers to the white paper section or the repository specification that covers it.

What the white paper describes as in progress

LDAP and Kerberos integration. Authentication goes through the organization’s identity provider, over OpenID Connect, or through local accounts for isolated environments. Integration with an LDAP directory and with Kerberos is in progress (V3 security white paper, section 6.1).

Security target evaluation. The security target is written in CSPN format and provided on request. The evaluation itself has not started: it will begin once the scope is frozen (V3 security white paper, section 10.4).

Scanning tooling at an isolated customer site

Each release ships with its bill of materials (SBOM) and its exploitability statement (VEX), which you load into your own vulnerability management tools (V3 security white paper, section 9.1). The white paper does not provide for the product to embed its own scanner. A repository specification goes further (specs/2026-07-29-air-gap-vuln-mgmt/): it starts from the observation that an inventory frozen on the delivery date says nothing about a vulnerability database that has moved since.

The buildable core of this specification exists in the repository, under security/vuln-mgmt/ and scripts/airgap/:

• packaging a scanner based on the tools used in continuous integration (OSV-Scanner, Trivy), with their database, so it works offline;
• an offline copy of the vulnerability database, with a dated freshness file;
• a freshness indicator, reported in the scan report, that flags a stale database.

What does not exist:

• no published release embeds this scanner or its database, and the cadence for importing the database over controlled media or through a diode is not tooled;
• the absence of network calls during a scan is verified by hand, with no automated check.

Static analysis of proprietary code

Every code change is reviewed before merge (V3 security white paper, section 9.1). The automated checks described on this site cover dependencies, secrets and container images. They do not cover code written by the vendor: no static security analysis is in place on proprietary code (identifier SEC-10.5-01, with no reservation).

No static analysis results are presented as long as the tooling does not exist.

The vulnerability response process

The reporting channel is published (SECURITY.md): a dedicated address, what a report must and must not contain, an acknowledgment deadline, an assessment deadline, a deadline for a fix or an explanation, a safe harbor clause for good-faith researchers, the scope of covered components, and the procedure for a customer without Internet access. A PGP key is provided on request.

Notification deadlines for an actively exploited vulnerability, and the split of responsibilities between the vendor and the host, are set by the V3 security white paper (sections 7.3 and 11.1).

What is not written (specs/2026-07-29-air-gap-vuln-mgmt/spec.md, §6):

• on-call roles and the internal triage chain;
• the scope of supported releases and the support duration per release;
• a published PGP key.

These commitments are organizational and contractual in nature: they are made with named people, not with code.

The regulatory control catalog

The security dossier that ships with the product consists of six items, described in the V3 security white paper (section 10.1). The catalog below is an additional tool, which the white paper does not provide for.

The method is settled (specs/2026-07-29-conformite/spec.md, §3): a unified catalog where each control carries its level of verifiability, its mapping to one or more regulations and articles, and its inheritance from the technical identifiers SEC-*. Per-regulation views are projected from it, never maintained by hand, which prevents the same fact from having several statuses.

This catalog exists only as a specification. No “CRA coverage” or “GDPR coverage” view can be produced. An answer to a procurement questionnaire relies on the items in the security dossier and on the artifacts and checks described in Supply chain, taken one by one.

What this page does not say

• no unfixed, unpublished vulnerability: the channel is SECURITY.md, not the documentation;
• no exploitable detail: no file, no symbol, no restatement of a specific weakness. An area to be built is named; how to exploit it is not;
• no delivery dates.

What this page says is verifiable: the specifications cited live in the repository, dated, with their decisions and their rejected options. A contractual audit can access them.