All articles

Continuous accreditation through evidence produced by every build

AGELAIOS

Doctrine

A build pipeline producing the instance evidence kit, made of an SBOM, a test report, a signed provenance manifest and a requirement-mechanism-evidence matrix.

This article is written for information-system security officers and accreditation authorities. It explains how AGELAIOS reverses the usual production of an accreditation file. Evidence is not reconstructed after the fact. It leaves the factory with every release. The article then describes the contents of the instance kit, the certification trajectory we are preparing and the security perimeter that version 1 actually claims.

The file that ages on the way to signature

In the usual programme, accreditation arrives at the end. A team then tries to reconstruct what the system contains, how it was built and which tests were run. The resulting file photographs a state that is already behind the software by the time it is signed. Each later release reopens the gap. The file describes yesterday’s system. The field runs today’s.

The authority is then left with a poor choice. It can freeze updates and leave known vulnerabilities in place, or it can accept changes that sit outside the file and empty the accreditation of its content. Neither option is a security decision. Both are a scheduling compromise.

AGELAIOS moves the burden earlier. The evidence items are build artifacts. Each release produced by the nine continuous integration pipelines of the reference repository leaves with its evidence kit, generated by those same pipelines, in the same trigger. The accreditation file is not rebuilt afterwards. It is refreshed at the exact pace of the software. The question of drift between the file and the deployed system disappears by construction.

Bit-for-bit reproducible builds complete that arrangement. An accreditor can rebuild the binaries from the published sources and compare them with the delivered artifacts. Trust in the build chain becomes a verification rather than a statement of confidence.

The reversal also changes the decision on updates. Between two releases, the authority can inspect the exact differential of the kits: components added or removed, tests changed, matrix rows touched. It can then apply a graded policy. Releases whose differential does not touch any requirement of the security target follow a lighter re-examination path. The others trigger a full review. That grading is impractical when the file is assembled by hand. It becomes a sort over artifacts when the file is a build output.

Four artifacts, one verification path

The evidence kit of an instance contains four elements.

  1. The SBOM, or Software Bill of Materials, inventories the software components of the image, with versions and provenances. It is the artifact that authorities, including CISA, promote as a foundation of software transparency, in particular for exposure analysis against published vulnerabilities [1]. A CVE published against a component can be crossed with the SBOM of each in-service release without a manual investigation of the image.
  2. The test report is the dated result of the complete suite, approximately 930 automated tests, on the x86-64 and ARM64 emulation targets, with the exact identifier of the version under test. Failures appear in that report on the same footing as successes.
  3. The signed provenance manifest attests the build chain. It describes which sources, which pipelines and which parameters produced which artifacts. The format follows the approach of the SLSA framework, which standardizes provenance attestation for the software supply chain [2].
  4. The requirement-mechanism-evidence matrix maps, for each security requirement of the target, the foundation mechanism that carries it and the evidence that attests it, whether a test, a measurement, a document or a procedure. A requirement without a mechanism or without evidence appears as a hole in the matrix. The format makes gaps visible instead of smoothing them.

A matrix row reads like this. The requirement is that the node rejects any module whose signature does not verify. The mechanism is ML-DSA-65 verification at install time, with a trust chain anchored offline. The evidence consists of public-suite tests that attempt installation of modules with an invalid, revoked or missing signature, together with the corresponding section of the threat model. The accreditor does not receive an assertion. The accreditor receives a verification path that can be walked as far as the test code.

This kit does not replace the accreditation decision. That decision remains an act of the authority on a defined employment perimeter. The kit supplies the raw material for it, current and checkable.

A certification path that starts from a smaller trusted computing base

The intended certification trajectory is ANSSI’s CSPN, the Certification de Sécurité de Premier Niveau. It is a black-box evaluation, conducted by an approved evaluation centre under a time constraint, that attests a product’s resistance against a stated attacker level [3]. The evaluation scope, the security target and the required documents follow the agency’s published framework [4]. No filing date is announced here. The calendar is an open point and will be published in the repository when it is committed.

The open character of the foundation serves that evaluation directly. A CSPN is run under a tight clock. Every hour an evaluator spends learning the product is an hour taken away from finding attacks. An evaluator who already has the sources, the threat model, the test suite and the build reports can enter the substance of the work immediately. The cost of understanding then sits on public documents that can be reviewed in advance, rather than on the evaluation days themselves.

The architectural choice that prepares this trajectory is a reduced TCB, the Trusted Computing Base: the set of components whose compromise is enough to compromise the security of the system. In AGELAIOS, business modules run isolated through namespaces, cgroups, seccomp, microVM or WASI, according to the chosen profile, and they sit outside the TCB. The evaluation target concentrates on the foundation: verified boot, signature verification, isolation and update. A smaller TCB gives a smaller evaluation perimeter. That is what keeps the cost and duration of evaluation compatible with a sustained release rhythm.

From threat model to security target

The security target is not drafted from a generic catalogue. It is derived from the threat model published in the repository, through a chain of three instruments.

  1. EBIOS RM, ANSSI’s method for digital risk assessment, structures the analysis: scoping of the perimeter, risk sources, strategic then operational scenarios, and treatment [5]. It is the method that links the assets to protect in an instance to the scenarios that are actually feared.
  2. STRIDE supplies the technical classification grid for threats, covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, applied to each interface of the foundation [6].
  3. MITRE ATT&CK brings the knowledge base of observed adversary techniques, so the model is confronted with documented practices rather than with purely theoretical attackers [7].

The output of that chain is the first column of the requirement-mechanism-evidence matrix. Each requirement of the target traces back to an identified threat scenario, and each retained scenario traces forward to at least one requirement. The accreditor can walk the chain in both directions.

System-high by design, multi-level security left unclaimed

Version 1 of AGELAIOS assumes a system-high posture. An instance operates at a single classification level, and every user of that instance is cleared to that level. The foundation does not claim to be an MLS system, meaning a system able to host several classification levels in the same instance with a demonstrated separation.

That choice applies the project’s editorial line: precision against promises. A demonstrated MLS separation is rare, expensive, and its demonstration sits beyond the frame of a CSPN. Claiming MLS without that demonstration would transfer an undocumented risk to the accreditor. The promise would appear in the file, with neither mechanism nor evidence in front of it. That is exactly the kind of hollow row the requirement-mechanism-evidence matrix is designed to make visible.

A more modest system-high posture can be demonstrated entirely with the mechanisms that already exist in the foundation. It gives the authority a perimeter it can actually instruct. The multi-level need is handled in version 1 by physical or virtualized separation of instances, one per level, federated where required by the labelling mechanisms described in the architecture reference. If that posture evolves, it will follow the same path as the rest of the product: a revised threat model, published mechanisms and evidence in the kit.

The commercial claim is therefore bounded on purpose. AGELAIOS does not sell a completed accreditation, a CSPN certificate or a multi-level security capability that the current mechanisms do not demonstrate. It sells a factory that produces current, replayable evidence for an authority that still makes the decision. The instance evidence kit is requested through the contact page, with the foundation version concerned.

Sources

  1. CISA, “Software Bill of Materials (SBOM)”, https://www.cisa.gov/sbom
  2. OpenSSF, “SLSA: Supply-chain Levels for Software Artifacts”, https://slsa.dev/
  3. ANSSI, “Présentation de la Certification de Sécurité de Premier Niveau (CSPN)”, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/certification-de-produits/presentation-certification-cspn/
  4. ANSSI, “Documents applicables à la Certification de Sécurité de Premier Niveau (CSPN)”, https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/certification-de-produits/referentiel-dexigences-pour-la-certification/documents-applicables-certification-de-securite-de-premier-niveau/
  5. ANSSI, “La méthode EBIOS Risk Manager”, https://cyber.gouv.fr/securisation/analyse-des-risques/methode-ebios-rm/
  6. Microsoft, “Threats, STRIDE model (Threat Modeling Tool)”, https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
  7. MITRE, “MITRE ATT&CK”, https://attack.mitre.org/