Policies to detect open-source risks
Open source risk policies generally fall into one of several categories:
- Vulnerabilities - Known vulnerabilities associated with a software component.
- Operational Risk - Issues that may make it more expensive to address any application impacting bug, including a security vulnerability.
- License Risk - Issues that may cause legal or compliance risk associated with your software.
Out-out-of box open source finding policies
Endor Labs provides the following out-of-the-box finding policies to detect open-source risks.
|Vulnerabilities indicate security weaknesses or flaws in the dependencies used by a software project. They can pose risks to the overall security and stability of a project. Raises findings for projects where vulnerabilities are detected.
|Outdated dependencies are software libraries, frameworks, or modules that are being used in a project but have newer versions available. They are usually superseded by newer releases that offer bug fixes, security patches, improved functionality, or better performance. Raises findings for projects with outdated software libraries, frameworks, or modules.
|Unmaintained dependencies refer to external libraries, frameworks, or modules that are no longer actively maintained or supported by their developers. These dependencies may have reached end-of-life, without updates, bug fixes, security patches, or any form of support. Raises findings for projects with unmaintained packages.
|Unpinned Direct Dependencies
|Unpinned direct dependencies indicate the absence of a specific version or range of versions for a dependency. This can lead to potential issues because different versions of dependencies may introduce changes, bug fixes, or even breaking changes, which can impact the project’s behavior or stability. Raises findings for projects with unpinned dependencies.
|Unused Direct Dependencies
|Unused direct dependencies are listed in a project’s configuration or dependency file and are not utilized or referenced in the project’s source code. Raise findings for projects with unused direct dependencies.
|Low Endor Activity Scores
|Projects with low Endor Labs activity scores are less likely to be kept up to date. They are susceptible to software bugs and security risks. Raise findings for packages with low Endor Labs activity scores.
|Missing Source Code
|If you cannot audit the source code associated with a software component, there is limited visibility that can result in operational and security risks. Raises findings for packages with missing source code.
|Low Endor Quality Scores
|Projects with low Endor Labs quality scores are highly likely to be susceptible to security and operational risks. Raise findings for packages with low Endor Labs quality scores.
|Typosquats is a malicious practice where a domain name closely resembles popular or legitimate domain names but contains typographical errors. This can deceive or exploit users who make mistakes while typing the intended website’s URL or package name. Raises findings for packages that contain potential typosquats.
|Low Endor Popularity Scores
|A popularity score indicates how well the software component is being used by developers. Raise findings for repositories that have low popularity scores.
Policy Templates for Open Source
Endor Labs provides the following out-of-the-box finding policy templates that you can use to quickly create a finding policy. The following policy templates help teams customize policy for open source software management:
- Permit only specified software licenses - Use this template to define an allowed list of software licenses permitted within your organization or a subset of projects. Endor Labs will raise findings when dependencies in packages or projects have licenses that are not on the allowed list.
- Restricted software licenses - Use this template to define a blocked list of software licenses that should be restricted from use or only used within specific contexts within your organization. Endor Labs will raise findings when dependencies in packages or projects have licenses that are on the blocked list.
- Restricted software license types - Use this template to create an organizational policy to restrict certain license types or limit a license type to specific contexts within an organization. This is useful to identify license risks and violations in 3rd party open source packages. The license type classification in this policy follows the industry best practice rules defined by Google license types.
Was this page helpful? Send your feedback to email@example.com