Checkpoint Lab — Sonatype IQ Integration, Component Intelligence, Quarantine, Policy Evaluation, and Procurement Controls

1. Scenario and operating rules

You are the artifact-platform engineer for a small organization introducing third-party procurement controls. There is no commercial Firewall license in this mandatory lab. Security has supplied a synthetic policy, development has supplied four candidate components, and one component has a temporary compatibility requirement. Your job is to classify the candidates, preserve evidence, and approve only the narrow exception authorized by the scenario.

2. Preflight and exact assumptions

3. Setup the evidence directory

mkdir -p chapter22-checkpoint/evidence
cd chapter22-checkpoint

On PowerShell:

New-Item -ItemType Directory -Force chapter22-checkpoint/evidence | Out-Null
Set-Location chapter22-checkpoint

Copy the Lesson 2 evaluate.py into this directory. Use the following fresh checkpoint fixtures so the evidence is independent from the guided lab.

4. Candidate components

[
  {"id":"pkg:maven/com.example/alpha@1.0.0","securityRisk":1,"license":"approved","malware":"none"},
  {"id":"pkg:maven/com.example/bravo@2.4.0","securityRisk":8,"license":"approved","malware":"none"},
  {"id":"pkg:maven/com.example/charlie@3.2.1","securityRisk":5,"license":"review","malware":"none"},
  {"id":"pkg:maven/com.example/delta@0.9.0","securityRisk":10,"license":"approved","malware":"synthetic-positive"}
]

Save as components.json. Use the same policy rules as Lesson 2 and start with waivers.json containing [].

5. Prediction gate — write this before execution

Create evidence/predictions.md with your expected result and reason for each component. At minimum, predict these two important state transitions:

1. Bravo will move into a synthetic quarantine disposition because of HIGH_SECURITY_RISK; no Nexus blob/database state changes in the fixture lab.
2. After a valid waiver for Bravo only, Bravo’s disposition will change to allow while its securityRisk=8 evidence remains unchanged and Charlie/Delta remain quarantined.

Also predict Alpha=allow, Charlie=quarantine for license review, and Delta=quarantine for both malware fixture + high risk.

6. First policy evaluation

python evaluate.py | tee evidence/evaluation-before-waiver.json

If your shell does not provide tee, run python evaluate.py and copy the generated results.json to evidence/evaluation-before-waiver.json. Verify the expected disposition matrix before proceeding.

7. Procurement review: evaluate alternatives before waiver

The scenario authorizes a temporary exception only for Bravo because an internal compatibility test cannot complete before the release window. Before waiving, document:

• Why Alpha cannot replace Bravo.
• Why the release cannot wait for a lower-risk Bravo version.
• Which team owns migration/remediation.
• Why seven days is sufficient.
• What happens when the waiver expires.

Do not waive Charlie or Delta. Charlie needs a license review; Delta represents a synthetic malware-positive fixture and also fails high-risk policy.

8. Apply the exact waiver

[
  {
    "component":"pkg:maven/com.example/bravo@2.4.0",
    "rule":"HIGH_SECURITY_RISK",
    "owner":"team-bravo-example",
    "reviewer":"procurement-reviewer-example",
    "reason":"Seven-day compatibility exception while replacement is validated",
    "ticket":"LAB-22-CP-001",
    "expiresAt":"2026-09-03T00:00:00Z"
  }
]

Save as waivers.json. Re-run the evaluator and preserve the output:

python evaluate.py
cp results.json evidence/evaluation-after-waiver.json

PowerShell: Copy-Item results.json evidence/evaluation-after-waiver.json.

9. Prove exactly what changed

• Bravo: decision changes from quarantine to allow.
• Bravo: securityRisk remains 8 in components.json.
• Alpha stays allowed.
• Charlie stays quarantined.
• Delta stays quarantined with both failing violations.
• No binary artifact, Nexus DB row, blob object, repository config, public upstream, or real policy service was touched.

This is the central governance lesson: the waiver changes disposition, not history or evidence.

10. Build the evidence packet

Your final directory should contain:

evidence/
├── predictions.md
├── evaluation-before-waiver.json
├── evaluation-after-waiver.json
├── waiver-review.md
├── product-boundary.md
└── verification.md

In waiver-review.md, record component, failing rule, owner, reviewer, reason, ticket, expiry, and remediation action. In product-boundary.md, record that the lab is a simulation and list the current Nexus/IQ reference versions and licensed Firewall requirement. In verification.md, record every checklist result below.

11. Map each checkpoint action to licensed product behavior

12. Optional licensed extension

Only in an authorized disposable environment:

1. Confirm Nexus 3.94+ and IQ/Firewall connection/license.
2. Create or identify a disposable supported proxy repository.
3. Start in Audit Only; capture the configured mode and repository results.
4. If the organization explicitly authorizes a quarantine demonstration, use a harmless component selected for a known lab policy—not a real malicious package—and preserve evidence.
5. Use the product’s supported waiver/release workflow only for the disposable test.
6. Return the repository to its approved baseline and remove test waivers/resources.

13. Verification checklist

• Predictions were written before execution.
• All four candidate identities are synthetic com.example components.
• Policy version is recorded.
• First evaluation matches expected allow/quarantine results.
• Exactly one waiver exists and it has owner, reviewer, reason, ticket, and expiry.
• Second evaluation changes only Bravo’s disposition.
• Underlying risk/license/malware fixture fields remain unchanged.
• Evidence packet does not contain credentials, real employer namespaces, or production URLs.
• Licensed mapping clearly distinguishes Nexus database/blob state from IQ/Firewall policy state.
• Cleanup removes only the disposable checkpoint directory or authorized live lab resources.

14. Cleanup / rollback

For the mandatory fixture lab, archive the evidence if desired and delete chapter22-checkpoint. No external rollback is needed. For an optional live lab, remove the test waiver, restore the repository’s approved Firewall mode, remove only disposable test repositories/resources, verify ordinary clients still use the governed endpoint, and preserve a redacted evidence record.

15. Knowledge check

16. Chapter summary and bridge to Chapter 23

Chapter 22 added a policy-governance layer to the production artifact-repository model: Nexus stores and serves artifacts; IQ/Firewall supplies component intelligence and procurement policy; quarantine is an observable policy disposition; waivers are scoped risk decisions with owners and expiry; and availability/security behavior must be documented rather than bypassed. Chapter 23 now broadens the evidence model to SBOMs, provenance, vulnerability governance, signatures/checksums, and supply-chain risk—showing which facts are immutable, which evolve, and which controls can be bypassed through alternate routes.

Official references and version notes

• Sonatype: Getting Started with Self-Hosted Repository Firewall — current product boundary, Nexus Repository + IQ Server requirement, and licensed Firewall integration.
• Sonatype: Firewall Configuration for Nexus Repository — Nexus 3.94.0+ repository-level Audit Only, Quarantine, and PCCS modes.
• Sonatype: Firewall Quarantine — new-request quarantine semantics and documented fail-closed behavior.
• Sonatype: Repository Firewall Waivers — waiver purpose and release-from-quarantine semantics.
• Sonatype: Waivers — hierarchy, component/version scope, expiry, stale and expired waivers.
• Sonatype: Policy Waiver REST API — owner scope, component matching strategy, expiry, and reason fields.
• Sonatype: Repository Firewall API — Nexus-side IQ connection and repository audit/quarantine API surface.
• Sonatype: Quarantine REST API — quarantine evidence and release behavior.
• Sonatype: IQ Server Versions Status — IQ Server 206 GA on 5 August 2026 and support lifecycle.
• Sonatype: Self-Hosted Nexus Repository Feature Matrix — Community/Pro Nexus entitlement boundaries; Firewall is separately licensed.
• Sonatype: 2026 Nexus Repository Release Notes — Firewall changes around 3.91–3.95 and current version context.