Component Policies
Component Policies
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.
| Policy | Threat | Categories | Detection |
|---|---|---|---|
| #### Component-Similar | 7 | All | The component has been modified from the original source - Match State is Similar - Coordinates do not match maven: org.eclipse.* |
| #### Component-Unknown | 2 | All | The component was not found in the Sonatype data - Match State is Unknown - Not labeled Proprietary - Data Source has support for identity |
| #### Component-EOL | 8 | All | Detects components whose latest version has reached end of life. - The component’s EOL date has passed. |
Component Exceptions
Components not found in public open-source repositories or those that have been modified present unknown risks 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 be 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.
Component End of Life (EOL)
The Component End of Life policy detects open-source components (or specific versions) that have been officially declared as end-of-life (EOL) and are no longer supported by their publishers.
End-of-life components no longer receive enhancements, bug fixes, or security updates, which increases the risk of unpatched vulnerabilities and compatibility issues over time.
Use this policy to identify and phase out outdated dependencies, replacing them with actively maintained versions.
Search results
No results found