Program // Software Assurance
Secure Containers¶
Secure · Hardened · Validated
Three additive assurance levels. Three independently qualified artifacts. Evidence remains bound to the exact container digest assessed.
Three assurance levels¶
A higher level inherits the requirements of the levels before it, but it is constructed and qualified as a distinct container artifact. The assurance level, release decision, and evidence bundle identify the exact immutable digest to which they apply.
01 // Foundation
Secure¶
A controlled security foundation with immutable build identities, non-root runtime verification, SBOMs, functional testing, vulnerability assessment, and defined release gates.
Evidence focus: composition, runtime identity, function, inventory, and known-vulnerability policy.
02 // Restricted
Hardened¶
A distinct container derived from the exact Secure foundation, adding product-specific runtime restrictions and a tailored CIS Level 1 container-filesystem assessment.
Evidence focus: all Secure requirements plus observed diagnostic lockdown, ancestry, and tailored hardening results.
03 // Assessed
Validated¶
A distinct container derived from Hardened, adding tailored STIG container-filesystem assessment evidence and verified use of an identified FIPS 140-3 validated cryptographic module.
Evidence focus: all Hardened requirements plus bounded STIG results, cryptographic-module identity, approved-mode enforcement, and self-test evidence.
Evidence boundary
Each level is a separate container artifact—not merely a different tag. Evidence applies only to the exact digest, architecture, level, and assessment identified in its release record. Evidence does not transfer between levels, rebuilds, or deployments. Secure does not inherit Hardened or Validated claims; Hardened does not inherit Validated claims.
What makes a secure container¶
An Indian Hill Secure Container is engineered for predictable operation, controlled composition, and verifiable software assurance. It is not defined by a low vulnerability count alone.
Vulnerability counts are useful inputs, but counts without context can misrepresent risk. Package reachability, runtime exposure, configuration, compensating controls, exploitability, and the exact artifact under evaluation all matter. The Indian Hill Labs model combines preventive controls with artifact-specific evidence.
This model is informed by NIST SP 800-190, which organizes container risks across images, registries, orchestrators, containers, and host operating systems. Artifact identity follows the OCI Image Specification: a digest identifies content, while a tag is a changeable discovery label.
Security model¶
Reduce¶
Use minimal components and remove tools, services, privileges, and interfaces that are not required at runtime.
Control¶
Build from reviewed inputs using repeatable processes and apply secure runtime defaults appropriate to the workload.
Prove¶
Associate SBOMs, scan results, VEX, provenance, tests, and signatures with the exact immutable artifact digest.
Sustain¶
Continuously monitor released artifacts, reassess new vulnerability information, and remediate within defined engineering objectives.
Assessment support¶
Release documentation can provide artifact-specific evidence that supports a customer's broader security review, including applicable STIG assessment material and, where published for the release profile, FedRAMP control-support documentation. The catalog and assurance bundle identify exactly which records exist for each digest.
This documentation is supporting evidence, not a replacement for system-level assessment. The customer remains responsible for the host, orchestrator, network, identity, secrets, operational procedures, and authorization boundary surrounding the container.
Lifecycle¶
Approved inputs → Controlled build → Test and scan → Applicability analysis
→ Sign and publish → Monitor → Remediate and supersede
The exact controls and evidence vary by product and assurance level. Release documentation identifies what was performed; consumers should not infer assurance from a product name or tag alone.
Container documentation¶
Catalog and use¶
Review public artifact availability, immutable identifiers, supported versions, and consumer verification guidance.
Standard and assurance levels¶
Read the governing secure-container requirements and the complete Secure, Hardened, and Validated qualification model.
Engineering process¶
Review the ASP.NET baseline, manual construction procedure, and GitLab candidate pipeline.
Compliance and STIG evidence¶
Understand repeatable container compliance, tailored STIG assessment boundaries, and per-digest evidence.
Supply-chain evidence¶
Review SBOM, VEX, provenance, signing, vulnerability management, and artifact-assurance practices.
Operations and monitoring¶
Review assurance dashboards, supported-artifact monitoring, and the governed container-lifecycle profile.
* Indian Hill Labs assurance levels are engineering classifications. They do not constitute FedRAMP Certification, DISA approval, or system authorization. STIG and FedRAMP-supporting documentation is identified per artifact and may support—but does not replace—the customer's assessment and authorization process.