Sonatype IQ Integration, Component Intelligence, Quarantine, Policy Evaluation, and Procurement Controls: Configuration, Design Choices, and Tradeoffs

1. Start with the control objective, not the toggle

The wrong design question is “Should we enable quarantine everywhere?” The better question is “Which requests must be governed, what evidence should influence the decision, how quickly must that evidence arrive, who can override the decision, and what is the acceptable failure behavior?” The Nexus mode is one implementation choice inside that control objective.

2. Audit, quarantine, or PCCS?

3. Repository procurement context versus application context

Repository Firewall sees a component as it crosses a repository procurement boundary. That is powerful because it can stop risky third-party content before many builds consume it. But the repository request does not necessarily know every application-specific fact: whether a library is reachable at runtime, whether a compensating control exists, or which business system will include it.

Lifecycle policies can use application and organization hierarchy. Waivers can also be scoped across repository/application/organization contexts depending on the product workflow. The architectural rule is to avoid forcing every application exception into a global repository waiver. Broader scope is easier operationally, but it increases the blast radius of a mistaken risk acceptance.

4. Human review versus automated waiver

flowchart TD
  Q[Quarantined component] --> RQ[Waiver request]
  RQ --> OWN[Owner + rationale]
  OWN --> REV[Authorized reviewer]
  REV -->|reject| ALT[Choose alternative version]
  REV -->|approve narrow scope| W[Time-limited waiver]
  W --> REL[Release / allow]
  W --> EXP[Expiry]
  EXP --> RE[Re-evaluate]
  AUTO[Automation] -. only pre-approved bounded cases .-> W

Automation is appropriate only when the organization can express a bounded, reviewable rule. “Automatically waive every security violation under CVSS 9” is not a safe default because policy evidence is multidimensional and future intelligence can change. Human review costs time, but provides context and accountability for exceptions that cannot be safely encoded.

5. Intelligence and policy freshness are operational dependencies

Artifact bytes can remain unchanged for years while vulnerability, malicious-component, license, and policy knowledge changes. Therefore a procurement design needs freshness objectives: how recently was the component evaluated, when did policy last change, what happens when IQ connectivity is degraded, and when is re-evaluation required?

Do not put a vulnerability score into a build manifest and then treat it as immutable artifact identity. Capture the evaluation timestamp and policy version separately. Chapter 23 will make this distinction explicit when comparing checksums, SBOMs, provenance, and vulnerability intelligence.

6. False-positive handling versus bypass culture

Any policy program can produce disputed findings, unavailable upgrade paths, or business-critical exceptions. The safe response is a governed exception path. The unsafe response is to teach developers that a blocked build means “disable Firewall,” “use Maven Central directly,” or “ask for a root-level permanent waiver.” Those shortcuts destroy the repository boundary and make future audit data misleading.

• Prefer an alternative allowed version before a waiver.
• Require a reason and owner.
• Use the smallest component/hierarchy scope.
• Use short expiry and renewal review.
• Preserve the violation; do not rewrite evidence to make dashboards green.
• Close direct-upstream bypass routes through client/network governance where appropriate.

7. Availability, latency, and failure behavior

Quarantine enforcement adds an external policy service to the dependency-resolution path. That can add evaluation latency and creates a service dependency. Current Sonatype quarantine behavior fails closed when the service is unavailable, so teams need a documented incident plan and developer communication. The correct response to availability pressure is architecture and operational readiness—not an undocumented fail-open bypass.

Measure before tuning: distinguish upstream latency, Nexus cache state, IQ/Firewall evaluation latency, database/blob IO, client retries, and local package-manager caches. A slow build is not automatically an IQ performance problem.

8. Configuration ownership and drift

9. Worked scenario: choose and justify

A 400-developer organization is onboarding Firewall for Maven and npm proxies. It has no established waiver SLA, does not know its false-positive rate, and release pipelines are time-sensitive. A reasonable staged design is:

1. Start supported proxies in Audit Only for a defined observation period.
2. Measure violation categories, owners, and review turnaround.
3. Create a waiver request/review process with small scope and default expiry.
4. Move high-confidence supported policies to Quarantine only after the operational path is proven.
5. Consider PCCS for npm where its package-resolution behavior is understood and useful.
6. Control direct-upstream bypass so enforcement cannot be silently avoided.

This is slower than enabling blocking everywhere on day one, but it gives measurable evidence and reduces the chance that the organization responds to first-week friction by disabling the control permanently.

10. Decision table

11. Knowledge check

12. Summary and next step

You can now choose policy modes and exception scope based on evidence, availability, ownership, and developer impact rather than checkbox preference. Lesson 4 stress-tests that design against licensing mistakes, blanket waivers, service outages, stale evidence, and unsafe troubleshooting.

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.