TRF
TRF (Trusted Runtime Factory) builds, hardens, scans, signs, attests, and continuously rebuilds golden images, container base images , so every workload starts from a known good, provenance verified baseline instead of an ad hoc one.
TRF gives engineering teams approved runtime foundations through automated image pipelines, CVE and vulnerability assessment, SBOM generation, signing, and attestation. The pipeline is built on a toolchain selected to fit the customer's environment, commonly cosign or an equivalent for signing, and aligns to established supply chain standards including SLSA, NIST SSDF, and the CIS Software Supply Chain Security Guide. TRF does not patch application code. It minimizes exposure at the base image layer and keeps every image scanned, signed, current, and traceable, so vulnerability triage starts from a much smaller surface.
The operating challenge
Teams often build from inconsistent base images with unclear provenance, uneven patching, and fragmented vulnerability handling, leaving security teams to chase down where a CVE actually lives across dozens of unrelated image lineages.
What TRF provides
TRF maintains governed golden images that are hardened, scanned, SBOM tracked, signed, attested, and continuously rebuilt as new base layers and patches become available, so the image a team pulled last month doesn't quietly drift out of date.
How it's implemented
TRF is a packaged accelerator, not a single fixed tool. Infer Origins implements the pipeline using scanning, signing, and SBOM tooling suited to the customer's environment, and aligns the process to SLSA, NIST SSDF, and CIS guidance rather than inventing a proprietary standard.
How teams consume TRF
Teams pull approved images from a governed registry instead of building or patching base images themselves. TRF handles rebuilds, re-signing, and promotion automatically, and surfaces exceptions or aging images that need attention, so teams inherit a maintained baseline rather than owning one.
Customization overlays
Organization or workload specific requirements are applied as overlays on top of the governed base, so teams can add what they need without forking the underlying hardened image or losing its provenance and attestations.
How adoption starts
Identify the highest volume runtime families, define acceptance policy, establish automated build and vetting pipelines, and migrate teams to approved images incrementally.
Who it is for
Platform and security engineering teams standardizing production runtimes across multiple teams and workloads.
When not to use it
When a small number of workloads can be supported adequately with existing deployment tooling and runtime standards.