Certification

Criteria and levels

Every criterion Brunel measures for a reliability certificate, its weight and exactly what it checks, and the minimum score and mandatory criteria of each level. Generated from the signed catalog.

Every criterion is measured by Brunel's own deterministic analysis of the commit, never by the AI and never from what the requester says. Each one passes, fails or does not apply (for example, Dockerfile criteria in a repository without a Dockerfile), with evidence.

Criteria

Catalog version 1.0.0. Weights add up to 100; the score is the weighted share of criteria met.

CriterionCategoryWeightWhat is measured
No committed secretsecrets.nonesecurity14No secret-looking value was found in the files, Compose files, Dockerfiles or infrastructure code at the commit.
Dependencies lockeddeps.lockfiledependencies7Every package ecosystem with a manifest also has a lockfile or exact pins Brunel could read.
No critical known vulnerabilitydeps.no-criticaldependencies14No locked dependency version matches a critical advisory in the OSV database at evaluation time.
No high known vulnerabilitydeps.no-highdependencies9No locked dependency version matches a high advisory in the OSV database at evaluation time.
Continuous integrationci.presentdelivery6A CI configuration is present (GitHub Actions, GitLab CI, CircleCI, Jenkins, Bitbucket, Azure).
Actions pinned by commitci.actions-pinneddelivery5Third-party GitHub Actions are referenced by a full commit SHA, not a movable tag.
Workflows hardenedci.hardeneddelivery6No critical or high workflow finding (untrusted pull request code with secrets, script injection, write-all token).
Base images pinneddocker.pinned-basecontainers4Every Dockerfile base image has a version tag or a digest (not latest).
Containers run as non-rootdocker.non-rootcontainers5Every Dockerfile switches to a non-root user.
Infrastructure code without high-risk settingsiac.no-high-riskinfrastructure5Existing Terraform, Kubernetes and Compose files have no critical or high misconfiguration Brunel checks for.
Automated teststests.presentproject8Test files are present in the repository.
Licenselicense.presentproject4A license file is present at the root of the repository.
Security policysecurity-policy.presentproject4A SECURITY policy file tells people how to report a vulnerability.
SBOM or build provenancesupply-chain.provenancedelivery3A GitHub Actions workflow generates an SBOM or signed build provenance (SLSA generator, attestations, Syft, CycloneDX).
Protected default branchgithub.branch-protectiondelivery4GitHub reports the default branch as protected (branch protection or rulesets), read through the GitHub API at evaluation time.
Signed commits requiredgithub.signed-commitsdelivery2A GitHub ruleset on the default branch requires signed commits, read through the GitHub API at evaluation time.

The score is the weight of the criteria that pass divided by the weight of the criteria that apply, out of 100.

Levels

LevelMinimum scoreMandatory criteria (all must pass)
Bronze50No committed secret
Silver65No committed secret · No critical known vulnerability · Dependencies locked · Continuous integration
Gold80No committed secret · No critical known vulnerability · Dependencies locked · Continuous integration · No high known vulnerability · Automated tests · Actions pinned by commit · Workflows hardened · Containers run as non-root · License · Security policy
Platinum92No committed secret · No critical known vulnerability · Dependencies locked · Continuous integration · No high known vulnerability · Automated tests · Actions pinned by commit · Workflows hardened · Containers run as non-root · License · Security policy · Base images pinned · Infrastructure code without high-risk settings · Protected default branch · SBOM or build provenance

A certificate is valid for 90 days from issuance.

A level needs its minimum score and every one of its mandatory criteria. A failed mandatory criterion caps the level whatever the score: a high score never buys a level while, for example, a critical vulnerability is known.

Criteria that cannot be measured

A criterion Brunel cannot measure (the vulnerability database is unreachable, GitHub settings are unreadable) fails, and issuing is refused until it can be measured. Branch protection and signed commits are read from GitHub with your access.

Versioning

The catalog has a version and a content digest, both signed into every certificate. Any change to a criterion, a weight or a level is a new version; a snapshot test in Brunel's CI prevents the version from drifting from its content. A certificate is always checked against the catalog it was issued with.

Criteria and levels · Brunel Docs