Skip to content

Container assurance levels

Indian Hill Labs evaluates container candidates against three additive assurance levels:

Secure → Hardened → Validated

A higher level cannot qualify unless every preceding level qualifies for the same source revision and exact runtime and application image digests. A successful pipeline means the assessment completed. The qualification decision in each retained level report determines which claim, if any, the candidate earned.

An assurance level is not a cosmetic tag. Each manually started pipeline selects one constructed candidate through the typed container-level pipeline input, which is mapped to CONTAINER_LEVEL for the jobs. The default hardened build first creates an immutable Secure runtime, then derives a distinct Hardened runtime from that exact digest and builds the reference application on it. A secure pipeline assesses the Secure runtime directly. A validated pipeline adds a third image from the exact Hardened digest, pairs the unchanged checksum-pinned OpenSSL FIPS boundary with a checksum-pinned supported OpenSSL base library, and repeats Secure and Hardened qualification on that new digest before evaluating Validated. The pipeline records both ancestry links in variant-lineage.json and evaluates only the claims the selected pair can legitimately earn.

Level Qualification boundary Bounded claim
Secure Immutable build identities, SPDX SBOMs, functional and non-root runtime verification, GitLab and Grype scanning, no reported High, Critical, or CISA KEV policy matches. Pipeline-qualified Secure candidate.
Hardened A distinct child of the exact Secure digest; everything in Secure; .NET debugger, profiler, EventPipe, and diagnostic IPC entry points disabled; and both exact images accepted by the tailored CIS Level 1 container-filesystem profile. Pipeline-qualified Hardened candidate with a CIS-aligned Level 1 engineering assessment.
Validated Everything in Hardened; both exact images accepted by the tailored STIG container-filesystem profile; and the exact approved cryptographic module, supported non-validated base library, module digest, approved-mode enforcement, integrity/self-tests, and application tests. Pipeline-qualified Validated candidate with bounded STIG image evidence and verified use of the identified FIPS 140-3 validated module.

Important boundaries

Secure and Hardened are Indian Hill Labs engineering levels. Hardened is CIS-aligned, not CIS certification or a CIS-CAT result. Raw CIS and STIG results remain visible at every tier; only the reviewed tailored CIS profile is an enforcement gate at Hardened.

Validated adds a tailored STIG container-filesystem enforcement gate and describes use of a validated cryptographic module. It does not mean DISA approved the image, that every system-level STIG control was assessed, or that NIST validated the entire container or deployed system. The initial controlled target is the OpenSSL FIPS Provider 3.1.2 identified by CMVP certificate 4985. The provider is configured with fips=yes, strict security checks, and self-tests on every load. It is copied unchanged into OpenSSL 3.5.7 LTS, whose base library is outside the validated boundary but remains on a supported release train as required by the OpenSSL FIPS module support policy. The Validated decision is not-qualified unless the runtime produces the required digest-bound report for both identities and approved-mode behavior.

Evidence contract

Each candidate produces these machine-readable decisions:

  • secure.assurance-level.json;
  • hardened.assurance-level.json; and
  • validated.assurance-level.json.

The reports identify the same two immutable image digests, source revision, controlled assurance policy hash, constructed candidate level, individual checks, qualification decision, and claim limitation. variant-lineage.json binds those digests to the exact Secure and Hardened parents used to construct them. The export job validates additive inheritance and includes all three reports in the exact SHA-256 evidence manifest handed to the private assurance dashboard.

The controlled machine-readable policy is compliance/assurance/container-levels.json. Changing a definition, module identity, or claim boundary is a reviewed policy change and produces a different policy hash.

Current implementation status

The pipeline constructs all three candidates from distinct runtime Dockerfiles. A Secure candidate cannot qualify as Hardened, and neither lower candidate can qualify as Validated. The Hardened boundary requires observed .NET diagnostic lockdown and accepted tailored CIS Level 1 results for both immutable image filesystems. The Validated boundary additionally requires accepted tailored STIG results for both images, the exact OpenSSL 3.1.2 module source hash, provider identity and digest, the OpenSSL 3.5.7 LTS base-library source hash and runtime identity, FIPS/base provider activation, fips=yes resolution, successful integrity and KAT self-tests, approved SHA-256 and AES-GCM application operations, and blocked MD5 resolution. The exported manifest reports secure-baseline, cis-level1, stig, and fips-validated-module as separate claims so an operator can see exactly which boundary was satisfied. Each level has an independent protected publication gate and tier-explicit lab tag. After publication, both exact digests are keylessly signed and verified against the controlled GitLab main pipeline identity, issuer, and manifest-bound annotations. A deterministic release bundle is uploaded to the GitLab Generic Package Registry. Validated publication and deployment additionally bind the exact FIPS module SHA-256 and evidence boundary. Production ACR infrastructure, workload federation, protected variables, and environment approval rules are provisioned. Promotion still requires a separate eligible Maintainer; the pipeline triggerer cannot approve their own production deployment.