Audit-ready traceability

How Seal's per-package evidence assembles into an audit narrative for any of the frameworks covered in this section.

When an auditor asks how a high-severity vulnerability was remediated in your environment, the artifacts from earlier in this section assemble into a complete answer without further prep.

The traceability chain

For each vulnerability the auditor asks about, the chain looks like this:

1. The vulnerability identifier. CVE, GHSA, OSV, or the relevant advisory identifier.

2. The package version your build was using. Visible on the Vulnerable packages tab and recoverable from build logs.

3. The Sealing Rule (or .seal-actions.yml entry) that triggered the substitution. Visible on the Sealing rules tab in the Seal UI, or in source for Local-mode customers.

4. The sealed iteration Seal published. Identified by its -sp[N] version string.

5. The code diff. The source-level change between origin and sealed iteration.

6. The PDF attestation. Signed Seal record asserting what the sealed iteration addresses.

7. The signature on the sealed artifact your build consumed. Verifiable with Seal's published public key.

Steps 1-3 are recoverable from your Seal Project's UI state and your CI logs. Steps 4-7 are produced by Seal per sealed iteration.

What this gives the auditor

• A direct line from "this vulnerability was disclosed" to "this is what we did about it."

• Independent signed evidence at each step.

• Per-vulnerability scope that can be assembled into the larger audit narrative.

A typical audit response

For each in-scope vulnerability:

1. Pull the row on the Sealed packages tab.

2. Download the PDF attestation.

3. Open the code diff.

For bulk evidence, use the bulk-download action on the Sealed packages tab, filtered to the scope the auditor needs.

Related

• Attestations

• Code diff

• Cryptographic signing