Skip to content

IHL-SCS-001 — Secure Container Standard

Version: 1.0
Status: Approved Engineering Standard
Effective date: 2026-08-30
Publisher: Indian Hill Labs
Scope: Public engineering requirements for Indian Hill Secure Containers

Important limitation

IHL-SCS-001 v1.0 is an Indian Hill Labs engineering standard. It is not FedRAMP authorization, FIPS validation, DISA approval, government certification, or third-party certification. No such status should be inferred unless separately obtained and explicitly identified for a particular artifact or service.

1. Purpose

This standard establishes baseline engineering and evidence requirements for an Indian Hill Secure Container. It promotes small and controlled runtime composition, secure defaults, repeatable assessment, and artifact-specific assurance.

The standard is intended to help producers build and maintain container artifacts and help consumers evaluate what was released. It does not replace a system-level risk assessment or the consumer's responsibility to configure and operate containers securely.

2. Normative language

The terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY express requirement strength:

  • MUST / MUST NOT: required for a claim of conformance to this standard.
  • SHOULD / SHOULD NOT: expected unless a documented, risk-based reason justifies another approach.
  • MAY: optional or context-dependent.

3. Scope

This standard applies to a released OCI-compatible container image and the processes used to compose, build, assess, publish, and maintain it. A conformance claim applies to an identified artifact digest and release, not automatically to every tag, variant, future version, deployment, or surrounding system.

The following are outside the direct scope of this version:

  • authorization of a deployed information system;
  • security of the consumer's host, cluster, network, identity, or secrets infrastructure;
  • certification against government or third-party programs;
  • guarantees that no unknown vulnerability exists; and
  • suitability for a consumer's particular legal, regulatory, safety, or mission requirements.

4. Secure container principles

4.1 Minimal attack surface

  1. The runtime image MUST contain only components required for its declared purpose or required to support the artifact safely.
  2. Build tools, package caches, test data, shells, and diagnostic utilities SHOULD NOT be present in the runtime image unless operationally justified.
  3. Unused services, listeners, set-user-ID or set-group-ID executables, and unnecessary privilege mechanisms MUST be removed or disabled where technically feasible.
  4. The release record MUST identify required network interfaces, ports, persistent paths, and externally supplied configuration at an appropriate public level.

4.2 Controlled composition

  1. Base images and software sources MUST come from reviewed sources.
  2. Build inputs MUST be version-controlled, pinned, locked, or otherwise constrained sufficiently to support repeatability and investigation.
  3. The build process MUST NOT embed credentials, private keys, tokens, or environment-specific secrets in the artifact.
  4. Dependency additions and material composition changes MUST be reviewable.

4.3 Secure runtime defaults

  1. The workload MUST run as a non-root identity unless a documented technical requirement and risk review justify root operation.
  2. The image MUST NOT require privileged mode as its normal operating condition.
  3. Required Linux capabilities, writable paths, mounts, ports, and device access MUST be minimized and documented.
  4. The application SHOULD tolerate a read-only root filesystem when its function permits.
  5. Default configuration MUST NOT disable authentication or transport protection when those controls are required for the declared use.
  6. Secrets MUST be supplied at runtime through an approved external mechanism, not stored in image layers.

5. Build and release controls

5.1 Build process

  1. Release builds MUST use an authorized, documented build process.
  2. The process MUST preserve enough information to identify the source revision and material inputs associated with the output.
  3. Release artifacts MUST be identified by immutable digest.
  4. A failed required control MUST block release unless an authorized, time-bounded exception is recorded.

5.2 Functional verification

  1. The release MUST pass defined functional tests relevant to its declared purpose.
  2. Health behavior and expected startup, shutdown, and failure modes SHOULD be tested where applicable.
  3. Test results included in public assurance evidence MUST identify the artifact digest or a verifiable relationship to it.

5.3 Runtime security verification

Verification SHOULD test applicable runtime properties, including declared user identity, exposed ports, file permissions, privilege requirements, writable locations, and expected process behavior. Tests MUST NOT be represented as comprehensive if they cover only a subset of the security model.

6. Software inventory and vulnerability management

6.1 SBOM

  1. A machine-readable software bill of materials MUST be generated for each released artifact.
  2. The SBOM MUST be associated with the immutable artifact digest.
  3. The SBOM SHOULD identify components and versions with sufficient detail to support vulnerability and license analysis.
  4. Known limitations in component discovery SHOULD be documented.

6.2 Vulnerability assessment

  1. The artifact MUST be scanned before release using maintained vulnerability intelligence.
  2. Reported findings MUST be evaluated for applicability when they would otherwise affect release or consumer action.
  3. Findings in the CISA Known Exploited Vulnerabilities Catalog MUST receive explicit handling.
  4. Applicable Critical and High findings MUST satisfy the current release gate or receive an authorized, documented exception.
  5. Assessment records MUST identify the artifact digest, tool or data context, assessment time, and disposition status.

6.3 VEX

Vulnerability Exploitability eXchange statements SHOULD be used when communicating that a reported vulnerability is not affected, affected, fixed, or under investigation. A VEX statement MUST include a rationale appropriate to its status and MUST NOT be used to hide uninvestigated findings.

6.4 Continuous monitoring and remediation

  1. Released and supported artifacts MUST be reevaluated as relevant vulnerability intelligence changes.
  2. Applicable findings MUST enter a documented remediation or exception process.
  3. Superseding releases and material security notices SHOULD be communicated through approved public channels.
  4. Engineering remediation targets MUST be treated as objectives unless a separate agreement expressly creates a service-level commitment.

See Vulnerability Management for the initial engineering objectives and public operating model.

7. Provenance, signing, and evidence

7.1 Provenance

Each release MUST retain provenance sufficient to associate the artifact with its source revision, build process, material inputs, and relevant build identity at the disclosure level approved for the product. Sensitive infrastructure details MUST NOT be exposed merely to satisfy public transparency goals.

7.2 Signing

  1. Released artifacts MUST be signed or accompanied by an approved integrity-and-identity verification mechanism.
  2. Verification instructions MUST define the expected artifact digest and trust policy or signer identity.
  3. Private signing material MUST NOT be placed in the image, source repository, public documentation, or release bundle.
  4. Signature verification MUST be treated as evidence of identity and integrity, not as a complete security assessment.

7.3 Artifact assurance evidence

Assurance evidence MUST be associated with the exact immutable digest. The available bundle SHOULD identify artifact metadata, SBOM, vulnerability assessment, VEX, functional and security tests, provenance, attestations, signature-verification information, approved exceptions, and applicable certification state.

8. Exceptions

An exception to a MUST requirement requires explicit authorization through the applicable Indian Hill Labs governance process. Exceptions must be scoped, risk-based, time-bounded where feasible, and tracked to resolution or renewal. Public evidence may state that an exception exists and describe consumer impact without disclosing sensitive internal details.

An undisclosed deviation is not an exception and cannot support a conformance claim.

9. Conformance statement

A public conformance statement should include:

  • standard identifier and version;
  • exact artifact digest;
  • artifact version and supported platform;
  • assessment date;
  • evidence location;
  • known deviations or exceptions that affect consumers; and
  • statement of the standard's limitations.

Conformance is valid only for the identified artifact and evidence set. Material modification, rebuilding, or repackaging creates a different artifact that requires separate evaluation.

10. Change control

Version 1.0 establishes the approved baseline for future conformance claims. Revisions may refine assurance levels, evidence formats, test profiles, approved exception handling, or product-specific overlays. Material normative changes require a new version; editorial corrections may update the review date without changing conformance requirements.

Version 1.0 supersedes the v0.1 draft. Artifacts assessed against the draft retain their original assessment label until they are reassessed against this version.

11. Normative and informative foundations

This standard uses the OCI digest model for artifact identity and draws on established container and secure-development guidance. The following sources are informative unless a requirement above explicitly incorporates them: