Sonatype IQ Integration, Component Intelligence, Quarantine, Policy Evaluation, and Procurement Controls: Guided Hands-On Workflow and Core Operations

1. Lab design: simulate the decision boundary, not the vendor implementation

The mandatory exercise does not emulate IQ Server internals, vulnerability research, or Nexus plugin code. It models the governance contract: a component has synthetic intelligence, a policy evaluates that evidence, a failing action can quarantine a new request, and an authorized waiver can release a specific disposition without changing the underlying evidence.

This distinction matters. A useful free lab teaches the state transitions and audit questions. It should never claim that a 30-line Python script reproduces Sonatype’s intelligence engine.

2. Preflight

• Python 3.10+ available locally; no third-party packages required.
• Create a disposable directory such as chapter22-policy-lab.
• No real Nexus/IQ URL, credentials, employer package names, vulnerability IDs, or production policy exports.
• Use only the synthetic package URLs under pkg:maven/com.example/....
• If you have a licensed lab, keep it optional and read-only until the fixture workflow is complete.

mkdir chapter22-policy-lab
cd chapter22-policy-lab
python --version

PowerShell users can create the same directory with New-Item -ItemType Directory chapter22-policy-lab and then Set-Location chapter22-policy-lab.

3. Create synthetic component intelligence

The following fixture deliberately uses invented scores and labels. They are teaching inputs, not real Sonatype research data.

[
  {"id":"pkg:maven/com.example/clean-lib@1.0.0","securityRisk":2,"license":"approved","malware":"none"},
  {"id":"pkg:maven/com.example/risky-lib@2.1.0","securityRisk":9,"license":"approved","malware":"none"},
  {"id":"pkg:maven/com.example/review-lib@3.0.0","securityRisk":4,"license":"review","malware":"none"},
  {"id":"pkg:maven/com.example/malware-fixture@0.1.0","securityRisk":10,"license":"approved","malware":"synthetic-positive"}
]

Save it as components.json. The immutable identity in this tiny lab is the component ID string; the risk fields represent mutable intelligence that could change in a later evaluation.

4. Define explicit policy rules

{
  "policyVersion": "lab-2026-08-27",
  "rules": [
    {"id":"MALWARE_FIXTURE","field":"malware","equals":"synthetic-positive","action":"quarantine"},
    {"id":"HIGH_SECURITY_RISK","field":"securityRisk","gte":8,"action":"quarantine"},
    {"id":"LICENSE_REVIEW","field":"license","equals":"review","action":"quarantine"}
  ]
}

Save this as policy.json. The rule design makes policy causality visible: the same component can have multiple failing violations, and a later waiver should refer to specific failing evidence rather than simply changing quarantine to allow.

5. Evaluate without mutating the fixtures

import json
from pathlib import Path
from datetime import datetime, timezone

components = json.loads(Path("components.json").read_text())
policy = json.loads(Path("policy.json").read_text())
waivers = json.loads(Path("waivers.json").read_text()) if Path("waivers.json").exists() else []
now = datetime.now(timezone.utc)

def active_waiver(component_id, rule_id):
    for w in waivers:
        if w["component"] == component_id and w["rule"] == rule_id:
            expiry = datetime.fromisoformat(w["expiresAt"].replace("Z", "+00:00"))
            if expiry > now:
                return w
    return None

def violations(c):
    out = []
    for r in policy["rules"]:
        value = c[r["field"]]
        hit = ("equals" in r and value == r["equals"]) or ("gte" in r and value >= r["gte"])
        if hit:
            out.append(r["id"])
    return out

results = []
for c in components:
    failing = violations(c)
    waived = [r for r in failing if active_waiver(c["id"], r)]
    unwaived = [r for r in failing if r not in waived]
    results.append({
        "component": c["id"],
        "violations": failing,
        "waived": waived,
        "decision": "quarantine" if unwaived else "allow"
    })

Path("results.json").write_text(json.dumps(results, indent=2) + "\n")
print(json.dumps(results, indent=2))

Save as evaluate.py and run python evaluate.py. Before running it, predict the four dispositions. The clean component should be allowed; the other three should be quarantined. The script writes a separate results.json, preserving inputs as evidence.

6. Interpret the first evaluation

Notice that the malware fixture has two failing violations. A policy engine should not hide one merely because the other is more severe. This models why a real quarantine release may require all failing violations that cause quarantine to be waived.

7. Model one narrow, expiring exception

Assume an owner approves risky-lib@2.1.0 for seven days while a replacement is tested. Create waivers.json:

[
  {
    "component":"pkg:maven/com.example/risky-lib@2.1.0",
    "rule":"HIGH_SECURITY_RISK",
    "owner":"team-example",
    "reviewer":"security-reviewer-example",
    "reason":"Temporary compatibility exception for lab only",
    "ticket":"LAB-22-001",
    "expiresAt":"2026-09-03T00:00:00Z"
  }
]

Run python evaluate.py again. Only risky-lib changes from quarantine to allow. Its synthetic risk score remains 9; the waiver changed the governance disposition, not the evidence.

8. Map the fixture to a licensed Nexus/Firewall deployment

flowchart TD
  CF[components.json] --> INT[Component intelligence fixture]
  PF[policy.json] --> POL[Policy configuration fixture]
  EV[evaluate.py] --> DEC[Policy evaluation fixture]
  DEC --> Q[Quarantine result fixture]
  WF[waivers.json] --> EX[Scoped waiver fixture]
  EX --> DEC
  INT -. licensed equivalent .-> IQ[IQ Server intelligence]
  POL -. licensed equivalent .-> IQ
  Q -. licensed equivalent .-> FW[Repository Firewall quarantine]
  EX -. licensed equivalent .-> W[Firewall / IQ waiver state]
  FW --> NX[Nexus proxy repository]

In the real product, the component intelligence and policy engine are not these JSON files. The mapping is conceptual: inputs, decision evidence, quarantine state, and waiver state remain distinct. That separation makes the lab transferable without falsifying product behavior.

9. Optional licensed read-only inspection

If—and only if—you have an authorized disposable Firewall deployment, verify rather than mutate:

• Nexus version is 3.94+ before following the repository-level Firewall mode UI.
• IQ/Firewall connection is enabled and connection verification succeeds.
• The selected repository is a supported proxy repository and shows its configured mode.
• Use a dedicated integration service account; do not use a shared administrator credential.
• Inspect repository results/quarantine evidence without releasing or waiving any real component.

Nexus also documents REST endpoints under /service/rest/v1/iq for connection/audit configuration. Treat the running instance’s OpenAPI as authoritative before scripting them.

10. Challenge: choose the control, do not copy the sequence

A fifth synthetic component has securityRisk=3, an approved license, and no malware signal, but your procurement team wants visibility for 30 days before blocking any security rule. Which control belongs at the repository boundary?

The best answer is an Audit Only rollout with documented review metrics, not an all-components waiver. A waiver exempts policy; Audit Only changes enforcement mode while preserving evaluation visibility.

11. Verification and cleanup

• components.json and policy.json are unchanged by the evaluator.
• First run has one allow and three quarantines.
• Second run after the narrow waiver changes only risky-lib to allow.
• The waiver has owner, reviewer, reason, ticket, and explicit expiry.
• No network request or commercial API was required.
• Delete the entire disposable directory when finished; no Nexus/IQ state exists to clean up.

12. Knowledge check

13. Summary and next step

You built a repeatable, no-paid policy lab, preserved evidence, demonstrated quarantine and scoped waiver semantics, and mapped each fixture to the licensed product boundary. Lesson 3 turns those mechanics into architecture decisions about enforcement, scope, review, freshness, and developer experience.

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.