Sonatype IQ Integration, Component Intelligence, Quarantine, Policy Evaluation, and Procurement Controls: Concepts, Architecture, and Mental Model

1. The practical problem: a repository can store bytes without deciding whether you should consume them

Chapter 21 established artifact identity and promotion. That still leaves a procurement question: when a developer asks a proxy repository for a third-party component, should the organization admit it? Nexus Repository can authenticate the request, route it to an upstream, cache the bytes, and serve them. Those mechanics do not by themselves tell you whether a component violates a security, license, architecture, or malicious-component policy.

Repository Firewall adds a policy decision at the repository boundary. It uses component intelligence supplied through the Sonatype IQ platform and applies configured policy actions to supported proxy requests. The crucial mental separation is storage state versus intelligence/policy state. A policy outcome may change tomorrow when intelligence or policy changes while the artifact bytes and checksum remain identical.

2. Product boundary: four names that must not collapse into one

A Nexus Community installation can participate in a licensed Firewall deployment; this does not make Firewall a free CE feature. Conversely, buying Nexus Pro is not the same as buying Lifecycle or Repository Firewall. Always verify the actual entitlement and IQ Server license.

3. Mental model: request → identify → evaluate → disposition

flowchart TD
  DEV[Developer or CI] -->|request component| NX[Nexus proxy repository]
  NX --> UP[Public upstream]
  UP --> CAND[New component candidate]
  CAND --> IQ[IQ Server / Firewall service]
  IQ --> INTEL[Component intelligence]
  POL[Configured policy context] --> IQ
  IQ --> DEC{Policy disposition}
  DEC -->|allowed| CACHE[Nexus cache / serve]
  DEC -->|failing policy| Q[Quarantine]
  Q --> REVIEW[Human or governed review]
  REVIEW -->|scoped waiver| REL[Release]
  CACHE --> DB[(Nexus database metadata)]
  CACHE --> BLOB[(Nexus blob bytes)]

The request begins at Nexus, but the policy decision depends on external intelligence and configured policy. When content is allowed into the proxy, Nexus persists normal repository state: database metadata and blob bytes. Quarantine adds policy/disposition state around the requested component; it is not a special checksum algorithm and it does not transform the artifact.

4. Current Nexus 3.94+ Firewall modes

Do not copy pre-3.94 instructions that create a Firewall Audit and Quarantine capability as the current workflow. Sonatype explicitly labels that capability path legacy for older versions. On 3.94+, configuration lives in the repository configuration itself.

5. Quarantine is a disposition, not a malware verdict

A component can be quarantined because a policy with a failing action was triggered. The evidence may involve security risk, license governance, malicious/suspicious research findings, or another configured policy. Therefore “quarantined” means the current policy says do not deliver this newly requested component. It does not mean a forensic analyst proved malware.

Sonatype also documents a subtle boundary: Firewall quarantine applies to newly requested components. Content already present in a proxy repository is audited but is not retroactively quarantined in the same way, specifically to avoid suddenly breaking existing builds. That is one reason repository admission controls and application-level continuous monitoring are complementary.

6. Availability behavior must be documented, not guessed

For repositories using quarantine, current Sonatype guidance states that the Firewall quarantine service fails closed: if the service is unavailable, new component requests are placed into quarantine until they can be evaluated and released. That is different from Audit Only, where the point is observation rather than blocking.

7. A waiver is scoped risk acceptance

Releasing a quarantined component generally requires the failing violations that caused quarantine to be waived. A waiver does not patch the dependency, change its checksum, remove the vulnerability, or prove the license acceptable. It records that an authorized reviewer is accepting a defined risk for a defined scope.

8. State map: what actually changes

• Nexus repository configuration: IQ/Firewall connection details and per-repository Firewall mode.
• Nexus database/blob state: normal component/asset metadata and binary content for admitted/cached artifacts.
• IQ/Firewall state: component identification, policy configuration, violations, quarantine records, waiver records, intelligence freshness.
• Client state: repository URL, credentials, package-manager caches, received HTTP errors such as a blocked/quarantined request.
• Governance evidence: reviewer, rationale, expiry, exception ticket, policy snapshot, timestamps.

Never “repair” a policy problem by deleting Nexus database rows or blob files. Those are different state stores and direct manipulation can corrupt repository consistency without changing the underlying policy decision.

9. Read-only inspection before enabling enforcement

1. Record Nexus version, edition, Java runtime, repository format/type, and whether the target is disposable.
2. Verify the actual Firewall/IQ license and IQ Server version; do not infer entitlement from Nexus CE/Pro alone.
3. For Nexus 3.94+, inspect the repository’s Firewall section and current mode without changing it.
4. Verify IQ connectivity using the product’s supported connection test; never print the service credential.
5. Inventory repository content already present versus content not yet requested; quarantine semantics differ.
6. Export or document the relevant policy/waiver context and identify who owns exception decisions.

10. Why this matters in DevOps

Artifact governance is strongest when it becomes a deterministic boundary rather than an informal approval message. CI asks Nexus for a component; Nexus routes the request; Firewall/IQ supplies policy evidence; a disposition is observable; exceptions are scoped and expire; downstream teams can explain why a component was admitted. This creates the foundation for Chapter 23, where SBOM, provenance, vulnerability intelligence, signatures, and policy evidence are compared explicitly.

11. Knowledge check

12. Summary and next step

You now have a precise boundary between repository storage and component-policy intelligence, a current 3.94+ Firewall mode model, and a governance interpretation of quarantine and waivers. Lesson 2 turns that model into a completely local, fixture-driven procurement workflow that requires no commercial service.

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.