Secure by construction, not by decoration.
Traditional application images often inherit packages, permissions, tools, and dependencies that the workload never uses. Every inherited component adds maintenance effort, uncertainty, and potential exposure.
The IHL container program is intended to produce smaller, better-documented software foundations with clear ownership and repeatable build practices. The standard remains a draft until its requirements, pipeline controls, registry processes, signing model, and maintenance commitments are implemented and independently reviewable.
What the standard is being designed around
- Minimal runtime contents and explicit dependency ownership.
- Non-root execution and least-privilege defaults.
- Software bills of materials and release evidence.
- Build provenance, artifact signing, and controlled promotion.
- Continuous vulnerability review and scheduled rebuilding.
- Published exceptions rather than invisible deviations.
Current state
Version 0.1 is a working standard, not a completed certification mark. Public language will distinguish implemented controls from design targets so the program earns trust through evidence rather than marketing.