Reference Policies

The Architecture Cleanup policy is for components that should not be distributed with an application and are probably included by accident, misconfigured builds, or incorrectly scoped scanning targets. Start by reviewing the scan process during the build and address discovered issues with your development teams. Including development tools in production environments should be avoided wherever possible.

Components not found in public open-source repositories, or those which have been modified, present unknown risk which may not be acceptable to some organizations. Unfortunately, policies meant to catch these components may also unintentionally catch Innersource Components developed by your organization or third-party vendors. The source of all components should be determined before any exception is made. Setting the Proprietary Configuration and using SBOMs to identify components unknown to Sonatype during a scan will greatly reduce any noise from these policies. You may also choose to Claim Components coming from an external source. We highly recommend efforts are made to reduce these sorts of violations so that true threats can be identified. The worst-case scenario would be for real risk to hide among ignored violations.

Components that have been modified present both additional security and license risk. In some situations, internal teams may choose to patch projects where no non-vulnerable version exists or upgrading is difficult or impossible. This practice leads to version lock-in and technical debt, which should be avoided whenever possible. If not, use short-term waivers to regularly assess the risk. The weak-copyleft license obligation is triggered when modifications are made to OSS which has not been shared back with the project owners. See the License Policies above for details.

The Temporary and Environmental context of your specific use case may adjust the criticality of reported CVSS scores. When making exceptions for components violating security policies consider the following:

Malicious components are exploitive by their nature and should never be allowed in your code. Components found to be 'Suspicious' in their Integrity Rating (see Firewall Specific Policies below) should also be avoided until their safety can be verified.

Firewall Policies are specific to the enforcement of component requests through proxy repositories. This occurs through Firewall's integration with your artifact repository, such as Nexus Repository.

When multiple licenses are present, it may not be clear which licenses are effective for your use case. In some cases, the reported effective licenses may differ from the findings of your legal team. Tracing where the license was discovered/reported for the component and research on the component's development website may be required. When a discrepancy is discovered, you may need to override the reported license with the recommendation from your legal team.