Best Practices
This section covers best practices to get the most out of your Repository Firewall solution.
Enable enforcement on proxy repositories
Enforcement is the primary use case for Repository Firewall. Firewall controls dependency management by preventing components with known vulnerabilities and policy violations from entering your proxy repositories.
- Enforcement is managed by IQ Server policy however, the Capability must first be configured, enabled, and have the Quarantined option checked; for each proxy that will need Repository Firewall protection.
- Repository Firewall will audit the existing components in the repository while only quarantining new components not used by existing applications.
- Avoid deleting vulnerable components from your proxy repositories so that existing builds are not impacted.
Additional protections, like dependency confusion protection, are enabled in Nexus Repository. See Getting Started for step-by-step instructions.
Allow builds to pull the components your applications already depend on before enabling enforcement
- Repository Firewall should be used to stop new risks from being introduced into your repository
- Blocking components your applications currently depend on will result in a poor experience with your development teams
- Review the note below on cleaning up vulnerable components from your repository
Block components with unacceptable risk
There are components in public package registries that should never be allowed into your environment. We recommend turning on enforcement right away for the following policies.
- Security-Malicious: components with known malicious intent
- Security-Suspicious: components where Sonatype's Releases Integrate data team is reviewing potential threats
- Security-Critical: vulnerabilities with a CVSS score of 9 or greater should be avoided as much as possible
- License-Banned: license issues can pose financial risks to an organization
Block unknown components
- Blocking Unknown Components ensures that the components entering your repositories have been identified and assessed by Sonatype Intelligence
- Components coming from public repositories are in an unknown state for a short time and automatically released when identified
- Allowing unknown components in your repository may allow risky components to enter your supply chain
For step-by-step instructions on blocking unknown components, see Release Integrity Best Practices.
Enable automatic quarantine release
- Repository Firewall helps automate your repositories' security by automatically releasing components from quarantine.
- Enabling Automatic Quarantine Release reduces the effort of administrating the Repository Firewall and reduces developer friction.
- Check out Automatic Quarantine Release for more information.
Enable policy-compliant component selection for npm proxy repositories
Policy Compliant Component Selection is a feature that reduces developer friction and administration of the Repository Firewall. With this feature enabled, only the most recent policy-compliant version of a component will install when an application installs dependencies. This prevents newly released package versions from interrupting development if your application automatically downloads the newest version of an application.
See Policy Compliant Component Selection and the Policy Compliant Component Selection FAQ for more information.
Use cleanup policies to remove vulnerable components currently in your repository
Repository Firewall is designed not to break your existing applications by only blocking new components before they are allowed into your repository. To clean up your repository, focus on removing vulnerable components from your applications while setting your cleanup policies to remove anything which has not been downloaded as frequently as you build your applications. Once your applications are no longer using those components Nexus Repository will automatically remove them from the proxy. The next time they are requested, they will be quarantined. Keep in mind legacy applications may not be built as frequently as other applications in production when setting the cleanup timing.
Define & communicate your waiver workflow to developers
Before turning on Repository Firewall enforcement, communicate to your development team the expected response when components have been automatically quarantined. Access to the proxy repository is often anonymous and quarantine messaging is easily overlooked. Repository Firewall administrators may not be able to determine who attempted to download a quarantined component in the first place. Developers need to know how and to who to reach out to have a component reviewed and released from quarantine.
Scope waivers to all versions of a component when you will accept the risk
For developer dependencies and frameworks of which new versions are automatically approved, scope waivers to include all versions of the component. This will accept the risk of a single violation for all future versions of a component while still blocking new violations when they are discovered.
Enforce organization-tailored policies
As your organization becomes more familiar with Repository Firewall, you can enable the enforcement of more policies to better manage risk in your repositories. The Repository Results screen will show policy violations for components in your repositories. This tool helps you understand the impact of enabling enforcement for a given policy and set expectations when setting a policy to fail.
Enable enforcement on supported proxy repositories
Repository Firewall works by identifying open-source from public repositories from any of the supported ecosystems. Your performance may be negatively impacted when configuring Repository Firewall on unsupported proxies.