Appendix: consultant delivery map
Use this reference to connect the workshop’s evidence to a customer delivery discussion. Each row identifies what you practiced, what you can show, and what would require additional work in a customer environment. The seven tracks follow one Java application from verified inputs to production and compliance review.
Map the workshop to delivery outcomes
| Track | What you practiced | Evidence to discuss |
|---|---|---|
1 — Verified base |
Run an Ansible workflow from Showroom against the bastion to verify, mirror, and verify a published Hummingbird image. |
Source and destination signature results, the mirrored digest, and a failed-verification attempt that stops publication. See Track 1. |
2 — Dependencies |
Configure Maven to use Nexus and select an exact version from the workshop OSV advisory. |
The Maven settings, affected and remediated dependency trees, and download source. |
3 — Source ownership |
Create the application through Developer Hub, record the verified inputs, and merge a real Renovate pull request. |
The catalog entry, committed Dockerfile and POM, and reviewed bot PR. See 3.1 through 3.3. |
4 — Build controls |
Remove public fetches, prefetch Maven dependencies, restrict build-pod egress, and build the image with an SBOM. |
Committed source, Pipeline and NetworkPolicy configuration, selected-run logs, image digest, inventory, and the separate known-bad attempt. See 4.4. |
5 — Signature policy |
Verify a keyless application signature, apply Conforma signature policy, and add the key-based signature used for admission. |
The exact image reference, verification outputs, policy copy, and unsigned-builder versus signed-application reports. See 5.1 through 5.3. |
6 — Production promotion |
Deploy through stage GitOps, test unsigned rejection, and promote the signed digest through a separate production repository. |
Fetched commits, Argo CD source and revision, signature verification, ImagePolicy, Ready pods, and the unsigned rejection reason. See 6.2. |
7 — Compliance evidence |
Retrieve the promoted image’s inventory from TPA, interpret the sample library advisory, and inspect ACS policy results for that image. |
Stored SBOM and advisory IDs, the exact installed GAV, locally inspected OpenVEX, ACS logs, and a written report. See 7.1 and 7.2. |
Identify the additional customer work
A workshop result provides evidence for a particular control. Before turning it into a delivery commitment, identify the customer’s operating environment, owners, policy, and acceptance criteria.
| Customer requirement | Additional work to scope |
|---|---|
Produce or maintain base images |
Track 1 consumes a published base. Operating an image factory, assessing FIPS requirements, and maintaining multiple architectures are separate activities. |
Use Artifactory or another enterprise repository |
Map the Nexus proxy and mirror pattern to that product’s repository configuration, authentication, and retention policies. Artifactory is not installed in this lab. |
Prove build provenance or a SLSA level |
Define the required provenance, generate and sign attestations, and verify the builder and build process. The workshop’s application signature and Conforma signature checks do not establish this assurance. |
Operate across a physical air gap |
Plan the image, signature, trust-material, dependency, and advisory transfer and test verification at the destination. Use Disconnected transfer planning as a starting point. |
Enforce dependency or runtime policies |
Define the allowed packages and risk thresholds, test the actual policy behavior, and assign remediation ownership. The workshop Conforma exercise checks image signatures; ACS evaluates its configured policies separately. |
Provide organization-wide incident response |
Collect inventories for every relevant artifact and deployment, define advisory refresh and response procedures, and integrate the customer’s reporting systems. Track 7 assesses one promoted image and a sample advisory. |
Deploy virtual machines, canary releases, or SIEM integrations |
Design and test those delivery paths separately. The hands-on workshop uses a container Deployment and stage/production GitOps. |
Verify supplier provenance for a real Java dependency
The seeded JAR in Tracks 2 and 7 is a synthetic workshop fixture. Do not treat it as a Red Hat-signed artifact or try to establish official supplier provenance for it. Maven repository and version evidence alone does not close this authenticity gap.
For an authorized real artifact, use Red Hat’s Java provenance verification procedure (reference checked 2026-11-10). Record the exact group, artifact, and version; obtain the JAR and matching <artifactId>-<version>.provenance.sigstore.json bundle from that coordinate’s directory. Obtain the supplier’s published PNC provenance key through an approved trust channel. Verify the attestation signature and confirm its subject digest matches the downloaded JAR. Retain the coordinate, artifact digest, bundle, trusted-key identifier, tool version, command, exit status, and verification output.
Before an instructor demonstration, confirm that the chosen Cosign release and flags support the real bundle format. The lab pins Cosign v2.4.3; that alone does not establish compatibility with every current supplier bundle. Follow the current official procedure and test the matching artifact and bundle before publishing executable customer instructions. Core workshop participation needs no supplier repository entitlement.
The enterprise repository owner should retain the matching bundle alongside the JAR and preserve both through proxy caching, retention, and mirroring. Assign trusted-key approval, rotation, and revocation response to the security or supplier-trust owner. Keep these records with the build’s dependency evidence.
Supplier provenance verifies origin and integrity of that dependency. Your later application signature covers the assembled image. Neither result proves that a vulnerability was remediated; that conclusion needs applicable advisory, version, and assessment evidence.
Use the evidence in a handoff
Start with the immutable image reference. Show which source and dependency choices produced it, which signature and policy checks you performed, and which production commit selected it. Then explain the inventory and advisory evidence, including unresolved policy findings or operational errors.
Keep statements specific: a successful signature verification identifies an accepted signer for an artifact; an SBOM lists components; an advisory describes affected products; an ACS response records a policy decision. Each answers a different question.