Expected Nexus Firewall Quarantine Numbers


Hi Everybody,

I’m looking for someone to share their experience when they implemented Nexus Firewall.
I am going to use Nexus Repository as gateway to the public Repos with IQ Server providing the Firewall to filter out CVSS 9 or greater.
I have about 10,000 developers in my organisation who will be using the Repo. I am worried that the volumes of CVSS 9+ will be too big to manage.

Has anyone on the forum, or can a Sonatype customer engineer please give me an idea of what to expect in terms of quarantine library numbers

Thanks in Advance




We find in many organisations that current practices for managing open source components, are based around a manual approval process, for example

a developer has to request approval for the use of the version of a component; this request goes through a formal review process. This usually requires one or more security professional has to investigate the version of the component, identify any vulnerabilities, license obligations etc. In many cases, this requires a review of the CVE via the https://nvd.nist.gov/. This is time consuming and as with many manual processes, is potentially error prone.

The Nexus IQ Server Firewall provides a facility to intercept versions of components as they are downloaded into the business; scan and identify those that breach your policy settings to place them into a quarantine area. This allows the business time to review the implications of these breaches and then decide on the appropriate actions, either to allow or not allow.

At Sonatype we have already catalogued components and version across multiple ecosystems; a team of security analysts review the public vulnerabilities declared in the NVD, but also from many other sources (not all projects declare their vulnerabilities to the NVD). They create clear unambiguous reference details for each security vulnerability; not just a copy of details from the NVD, but a detailed explanation of the issue, how to detect the vulnerability, a recommendation of how to mitigate the issue, the root cause of the issue (not just the component package), and details of any public advisories. This makes the decision making process for reviewing the limited number of items which get quarantined a much more simple prospect.

So, firewall intercepts existing threats; but as we have seen in recent months new vulnerabilities appear periodically on components that projects may also have already consumed, and perform critical functions in applications that are already deployed within a business. Therefore Nexus IQ Server Lifecycle, should be deployed to scan applications as part of their development lifecycle, to catch these issues during development. But also to use the continuous monitoring feature to catch those applications which are already running in production, to generate a zero day alert for new issues.

I am not able to provide a number to indicate how many components (and versions) across all ecosystems match this criteria currently; or more importantly how many will receive such scores in the future. It is fair to so however, that the implementation of the Nexus IQ Server products, firewall and lifecycle, will significantly reduce the effort associated with the governance of open source components.