How sealed packages are delivered

Build-time dependency sealing versus post-build artifact sealing, and when each applies.

Seal delivers a sealed package in one of two technical ways, called sealing approaches. Both involve Seal building from source. They differ in where the artifact lands in your workflow.

Build-time dependency sealing

The customer's build picks up the sealed dependency at build time. The build proceeds normally: the dependency manifest resolves to a sealed version, the code compiles against it, and the artifact your team ships incorporates it.

This is the path for application-dependency ecosystems: npm, pip, Maven, Gradle, Go modules, Composer, Bundler, NuGet.

Post-build artifact sealing

Seal produces a fully built artifact that replaces an existing one in a built environment. There is no rebuild on the customer side. The sealed artifact takes the slot the vulnerable artifact had; nothing else changes in the surrounding image or filesystem.

This is the approach when a rebuild is not available or not practical. The most common cases are pre-built JARs and Python wheels inside containers, where the source for the build is not at hand or the build itself happened far upstream of the deployment.

Which one applies

Seal Apps uses build-time dependency sealing.

Seal Vendor Apps and Seal My Container use post-build artifact sealing for pre-built artifacts inside container images (typically JARs and Python wheels).

Related

• The Seal product family: which products use which approach.

• Working with Seal Apps: the day-2 view of build-time dependency sealing in the application context.