Reference Policy Set
Understanding and developing an open-source governance policy can be challenging. For this reason, Sonatype developed a reference policy set to be leveraged as a baseline measurement of organizational open source risk, or form the foundation of a custom governance policy within IQ Server. This document is intended to provide guidance on understanding these policies.
As a prerequisite, the IQ Server will need to be installed, configured, and running and should have connectivity to the Sonatype data services. The current reference policy set is automatically imported into new deployments of IQ Server. External connectivity issues with the data services will result in the policies not loading. To manually import the reference policy set to your Root organization, you can download it here.
The threat level (risk) rankings are based on the Common Vulnerability Scoring System (CVSS) values assigned within each finding from the Common Vulnerability Enumeration (CVE).
CVSS scoring is commonly comprised of three elements:
- Base: represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments.
- Temporal: represents the characteristics of a vulnerability that change over time but not among user environments.
- Environmental: represents the characteristics of a vulnerability that are relevant and unique to a particular user's environment.
CVSS scores reported in Sonatype data will not include specifics on your Temporal or Environmental factors in the default reference policy. Review this information on Sonatype Vulnerability Data. For details on CVSS scoring visit, https://www.first.org/cvss/user-guide.
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:
- Mitigating control has been verified and documented.
- Exploit is not applicable in the application context.
- The organization is willing to accept the risk of a legacy component.
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.
- Security issues in this category should never be allowed and immediately addressed.
- No exceptions should be made.
Firewall Specific Policies
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.
The license policy threat level (risk) rankings are based on the generalized information below, and the Sonatype categorization of license obligations.
References to open source software (“OSS”) license agreements included in license threat groups or IQ policy configurations do not constitute legal advice or guidance. You are responsible for seeking appropriate legal advice regarding your rights and obligations set forth in any such OSS license agreement.
License-Threat Not Assigned
License-Modified Weak Copyleft
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.
- Choosing the least restrictive license when the component is dual licensed.
- Overriding inaccurate license data.
- The organization is willing to accept the risk.
Licenses in this category are often determined to present too great of a risk to be used in any context. This may be due to commercial obligations (you must purchase a license) or present obligations which are too restrictive for organizational use. Always consult with your legal team regarding the effective license to use.
- A justification should always be provided in all exception requests attached to any internal legal policy.
Some OSS software includes a URL where the reported license is posted. This practice presents its own type of risk, as changes on their website could be interpreted to retroactively replace the license for previously published components. Sonatype data does capture the license data internally, but the component will be reported as License-None because a dynamic URL is not a valid license. You will need to consult with your legal team on their policy for selecting the applicable license for these components. Exceptions are made by selecting the appropriate license for usage going forward.
- Select the appropriate reported license from the developer's website.
The license on open source grants or restricts the right to use the project within your applications. OSS components without a license present a significant risk as it falls under copyrighted works by default. Consult with your legal team before making any exceptions or avoid using it altogether. Alternatively, consider making a request to the project owners to add an acceptable license.
- May be common in legacy components.
- Be careful that the selected or overridden license information is correct for the version used.
The architecture policies are used to direct development teams to avoid using undesired libraries or encourage them to improve the hygiene of the components they are using. Unpopular or older components without newer versions may hide unknown risks due to less scrutiny from security researchers. They may also hint that a project is approaching the end of its life (EOF) or is no longer supported. The threat level rankings are subjective to your organization's goals.
- Consider creating an Architecture-Banned policy against components that should not be used by your development environment. Use Component Labels to identify the components against this policy would be used to enforce.
The component coordinates match common testing libraries
The component is older or not popular
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.
- Consider waiving violations when builds cannot be modified and the organization is willing to expect the risk.
The component policy threat level (risk) rankings ratings are subjective based on your organization's goals. Your Lifecycle team should review all component policy threat level rankings.
The component has been modified from the original source
The component was not found in the Sonatype data
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.