Sonatype Nexus Repository 3.83.0 Release Notes

You can now extend Sonatype Repository Firewall’s automatic policy enforcement to containerized applications, enabling your team to block non-compliant or vulnerable Docker images before they enter your development environments.

Repository Firewall analyzes Docker images as they are requested through a protected proxy repository. Images that violate your defined policies are automatically quarantined, ensuring developers and deployment pipelines only use trusted containers. Violations are reported in a new Containers dashboard that also provides clear insights into which components within a container triggered enforcement.

You can also apply waivers to container-level violations directly from the container report or via the new Container Waivers API, streamlining security review and enabling critical images to proceed when necessary.

This functionality supports Docker Schema 2 (both single and multi-architecture) images from any container registry proxied by Sonatype Nexus Repository. To optimize performance, local disk storage is recommended for temporary container analysis. Note that Sonatype does not ingest or retain container data during analysis.

For full configuration instructions, supported formats, and usage details, see the Repository Firewall for Docker help documentation.

You can now customize Sonatype Nexus Repository’s password hashing algorithm to best align with your organization’s security standards. Supported options include SHA-512 (default), PBKDF2WithHmacSHA256, and PBKDF2WithHmacSHA1. This enhancement allows for greater flexibility and alignment with modern security policies.

Additionally, secrets encryption now supports both PBKDF2WithHmacSHA256 and PBKDF2WithHmacSHA1 (default), offering improved configurability for securing sensitive data within the system.

A new Verify and Repair Data Consistency task is now available in Sonatype Nexus Repository to improve the recovery experience when the database and blob stores become out of sync. This task replaces the legacy Repair - Reconcile component database from blob store task and offers faster performance, enhanced precision, and greater flexibility.

Use this task to recover missing component metadata for artifacts that exist in storage but are no longer referenced in the database. This scenario may occur when restoring from backups or during failover events where the database and storage were finalized at different points in time. You can also restore soft-deleted artifacts before they're permanently removed from blob storage.

Administrators can scope the task by blob store, repository, and time window. A Dry Run option is also available so that you can preview changes before executing them, allowing for safer and more controlled recovery workflows.

For implementation details and API usage, see the Verify and Repair Data Consistency task help documentation.

Note that any scheduled Repair - Reconcile component database from blob store tasks will be automatically removed during the upgrade to Nexus Repository 3.83.0 and later. This is to prevent errors since the legacy task is not compatible with a date-based blob store layout, which Nexus Repository now uses by default.