I just saw an old video about (Sonatype Nexus) repository firewall which makes the product look like an interesting addition to our Sonatype nexus repositories. However in the demonstration video the demonstrator had to remove a package, then redo the pull on the proxy repo for the firewall to scan and quarantine it.
However it is unclear if this was just because the package entered the repository before Repository firewall was even enabled. Or if this is a general thing.
My concern here is that while that is really great for avoiding getting already known bad package into our pipeline, security flaws and malicious packages are often NOT discovered before some time has passed, in some cases years. So if a malicious package was downloaded into NEXUS, but it was not known that it was malicious at the time (Nexus did not find any problems at the time) - then the video makes it looks like this is never flagged somehow???
If this was the case I would still trust e.g. Nuget.org more than a local nexus server as packages there are used by thousands and I feel like it’s more likely that they will be reported and removed over time as people discover them to be malicious, I also know that nuget.org updates the security details of said package over time as vulnerabilities are discovered.
But how will Nexus + Repository Firewall work for this topic?
(Maybe Sonatype Lifecycle has to be included in the discussion?)
Hi @dotjem.com thanks for asking! The behavior that you describe for Firewall is accurate: when Firewall is enabled on a proxy repository, each new component being requested through the repository is evaluated against your organization’s risk policies only at the point of entry. If the component represents a known risk, your policy can indicate whether just to warn the developer, or flat out block the request. If blocked, the component is never stored in your proxy repository; and as long as the implicated risk is the same and the policy is still in force, subsequent requests for the same component will produce the same result. (Edit: the component is stored, and held in “quarantine.” You can choose to delete the component or release from quarantine to make it available.)
You’re right as well that risks can change over time. A proxied component that had no known risk at the point of entry might well be implicated by risk discovered later on. If that component is no longer used by your applications, it’s not an active risk, and will eventually be reaped by your Repository cleanup policies.
But if a new risk is associated with a component you rely on, the first question you’ll want to know is “in which applications are we using it?” It’s not easy to answer that question from just the view of the Artifact Repository. That’s where Lifecycle shines, allowing you to identify the applications you build, associate them with the git repositories containing the source, precisely inspect the true bills of materials for your projects, and continuously monitor the risks present in them. When fully adopted, Lifecycle will even open pull requests with the recommended remediation in the very apps that are using the dependency, either directly or transitively!
I hope that provides some clarity on the different use cases, let me know what you think!