This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
Manage projects
Learn how to manage your Endor Labs projects.
Packages are collections of generally related software functions, which are built in a repository.
A package generally may have any of the following:
- Versions - A point in time in the software development lifecycle of a given package’s source code. Versions may be named and published versions as well as versions based on the version of the repository.
- Dependencies - Other software package versions that a given software package depends on.
- Dependents - Other software package versions that depend on one or more versions of a given software package.
- Findings - A finding is a discovery of interest derived from an evaluation. Findings are default out-of-the-box implementation of rule sets. Policy for these rule sets is coming soon.
- Scorecards - Scorecards are data sheets of facts that are used to derive Endor Labs scores. Scorecards are based on analysis that Endor Labs performs on open-source dependencies used in your packages.
This section provides a basic overview of managing projects and their packages.
Package dependencies and dependents
Package dependencies are versions of other software packages your software relies on to deliver its functionality. Inversely, dependents are those package versions that depend on a specific package that you’ve created in one of your projects.
Endor Labs builds a bill of materials for each of your package dependencies. Package dependencies and dependents may be direct or transitive:
- Direct package dependencies are those package versions that are explicitly defined and imported into a package’s declaration file.
- Transitive package dependencies are those package versions that are pulled into a package because of their use in a direct dependency.
A dependency of a given package version has the following metadata associated with it directly in the table of dependencies:
-
Dependency Name and Version - The name and version of the dependencies your project or package relies on.
-
Type - If a dependency is directly imported as part of a package, it is of type Direct
. If a dependency is imported through the import of one or more direct dependencies, it is of type Transitive
.
-
Dependent Packages - In the context of a project, dependent packages are the number of packages created by the project that rely on your package.
-
Reachability - A dependencies reachability status may have three states:
- Reachable - A dependency is flagged as reachable when a call graph of the dependency is able to reach the dependency as it traverses the function calls made by a package.
- Unreachable - A dependency is flagged as unreachable when a call graph of the dependency is NOT able to reach the dependency as it traverses the function calls made by a package.
- Potentially Reachable - A dependency is flagged as potentially reachable when call graph analysis is unsupported for a given language/package manager or has failed and is unable to determine if a dependency may or may not be reachable.
-
Visibility - If a dependency is publicly available for use it is flagged as public. Otherwise, if a dependency is from a private package it is flagged as private.
-
Source Available - If the source code is auditable and directly linked with the metadata of a package then the source code is flagged as available. For dependencies where source code is unavailable, an Endor Labs scorecard is not generated for the dependency.
-
Endor Labs Dependency Scorecard - Scorecards are data sheets of facts that are used to derive Endor Labs scores. Endor Labs creates a scorecard for the security, activity, popularity and quality of a software dependency.
In addition, if you click on a given dependency a drawer with additional data points is made available to users.
- Dependency Paths - Dependency Paths show how a given version of a dependency is imported into a package. This may be used to understand the effort to update a dependency and to get visibility into how deeply embedded a dependency is in your ecosystem.
- Dependency Specification - A dependency’s specification documents the request made for a given dependency when that dependency is directly imported into a package. This helps organizations to understand if that dependency is only a test and any metadata associated with the dependency’s import.
A dependent of a given package version has the following metadata associated with it directly in the table of dependents.
-
Dependent Package Name - The name of a package that is dependent on the package you are reviewing or that is created within the context of the project you are reviewing.
-
Dependent Package Version - The version of a package that is dependent on the package you are reviewing or that is created within the context of the project you are reviewing.
-
Repository of dependent package - The location from which the package that depends on the package you are reviewing is being developed.
View package dependencies and dependents
To view the dependencies of your package:
- From the left sidebar, navigate to Projects.
- Search for and select a project to review
- Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
- Click the package to view all dependencies and the scorecards of those dependencies
To view the dependents of your package:
- From the left sidebar, navigate to Projects.
- Search for and select a project to review
- Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
- Select the package whose dependents you’d like to review
- Select Dependencies to see dependencies associated with your packages.
Dependents can be used to communicate with downstream users of your package version regarding any major modifications to your package.
View scorecards
Scorecards are data sheets of facts that are used to derive Endor Labs scores. Scorecards are based on analysis that Endor Labs performs on open-source dependencies used in your packages.
- From the left sidebar, navigate to Projects.
- Search for and select a project to review.
- Under Packages, you will see a list of all packages maintained as part of your project and any findings associated with them
- Select the package whose dependencies you’d like to review
- In the list view of dependencies you are presented with scores for Quality, Activity, Security and Popularity click on any of these scores to be presented with the scorecard for the dependency.
Scorecards show the results of the analysis from which Endor Labs scores are derived. Review the scorecard to learn more about your dependency. See also Understand Endor scores
1 - Findings
Find and manage priority issues
A finding is a discovery of significance made following the completion of a scan. Findings result from the default out-of-the-box implementation of rule sets called Finding policies.
View findings associated with a project
To view the findings associated with a project or package:
- From the left sidebar, navigate to Projects.
- To view a list of the findings associated with your project you can click the findings tab in the upper navigation.
- If you’d like to see the projects with an associated package only, select that package and then click the findings tab in the upper navigation.
- Review the list of findings. Click the finding to see its details.
View all findings
To view different types of findings associated with all projects or packages in your tenant:
- From the left sidebar, navigate to Findings.
- The preset filters help you in locating the findings that matter most to you.
- Choose Prioritized Findings to view a list of critical vulnerability findings in the last 30 days that have either a reachable function or a reachable dependency, are not test dependencies, and have an available fix.
- Choose from a list of options under Code Dependenciesto view a list of Vulnerability, Operational, License Risk, or Malware findings.
- Choose Secrets to find a list of findings related to exposed secrets.
- Choose from a list of options under CI/CD to view findings related to GitHub Actions, CI/CD Tools, and RSPM.
- Choose Containers to view container findings.
- Use Saved Filters to create and save your frequently used searches, helping you save time.
- Search for findings using basic filters.
- Toggle Advanced and search for findings using advanced filters.
- To apply exceptions to findings, select findings and click Actions > Add Exception.
- To export findings, select the findings, and click Actions > Export Selected or Export All.
.
Finding attributes
Finding attributes are characteristics or properties associated with each discovered issue or result obtained from a scan. These attributes could include the following details and metadata.
Attribute |
Description |
Blocker |
Finding was marked as blocking by an action policy. |
Direct |
Finding applies to a direct dependency. |
Exception |
Finding was marked as exempt from action policies by an exception policy. |
External Path Only |
Finding applies to a transitive dependency that can only be reached via external, non-OSS, project paths. |
First Party |
Finding applies to a dependency that belongs to the same namespace. |
Fix Available |
A fix is available for the CVE reported in this finding. |
Invalid Secret |
Finding applies to an invalid secret. |
Malware |
Finding applies to a malicious package. |
Normal |
Finding applies to a normal, non-test, dependency. |
Notification |
Finding triggered a notification based on an action policy. |
Phantom |
Finding applies to a phantom dependency. |
Policy Based |
Finding was generated by a Rego based finding policy. |
Potentially Reachable Dependency |
Finding applies to a potentially reachable dependency. |
Potentially Reachable Function |
Finding applies to a potentially reachable function. |
Reachable Dependency |
Finding applies to a reachable dependency. |
Reachable Function |
Finding applies to a reachable function. |
Same Repository |
Finding applies to a dependency that belongs to the same project. |
Self |
Finding applies only to the analyzed package version, there is no dependency involved. |
Test |
Finding applies to a dependency that is not in production code. |
Transitive |
Finding applies to a transitive (indirect) dependency. |
Under Review |
Finding applies to suspicious package under review. |
Unfixable |
There is no fix available for the CVE reported in this finding. |
Unreachable Dependency |
Finding applies to an unreachable dependency. |
Unreachable Function |
Finding applies to an unreachable function. |
Valid Secret |
Finding applies to a valid secret. |
Warning |
Finding triggered a warning based on an action policy. |
View GitHub Action findings (Beta)
GitHub Actions is a CI/CD platform that allows you to automate your build, test, and deployment pipelines. You can create workflows that build and test pull requests to your repository, or deploy merged pull requests to production. To mitigate vulnerabilities within the supply chain, comprehensive visibility into GitHub Action workflows and their relationships in your repository is crucial. You can then proceed to identify and fix weak points within the system.
When you run an endorctl scan, it detects GitHub Action workflows used in your repository. It proceeds to scan all the repositories included in the detected workflows and creates findings. The GitHub Action is mapped as a package and discovers direct and transitive dependencies.
To view GitHub Action findings:
- From the left sidebar, navigate to Projects.
- Search for and select a project and select Findings.
- Click CI Workflows to view GitHub Actions findings.
![View GitHub Actions](../../images/githubactions.png)
Note
- Vulnerabilities and dependencies associated with GitHub Action packages written in JavaScript or TypeScript are detected by Endor Labs.
- Private GitHub Actions and private reusable workflows referenced from other repositories are not detected.
Search for findings using basic filters
Use the following basic filters to search for information in your findings.
- C - Findings with critical severity.
- H - Findings with high severity.
- M - Findings with medium severity.
- L - Findings with low severity.
- Category - Choose from CI/CD, Malware, license risks, operational risks, SCPM, secrets, security, supply chain, or vulnerability and view related findings.
- Hide Dismissed - Select to hide dismissed findings. You can view active findings without clutter.
- Attributes - Narrow down the list based on a range of factors such as, if a patch is available, if the vulnerable function is reachable, if the dependency is reachable, if the dependency originates from a current repository or a current tenant, is a test dependency, is a phantom dependency, or if the finding originates from itself, direct, or a transitive dependency.
- EPSS Probability - Choose the Exploit Prediction Scoring System (EPSS) score range.
- All Time - Choose a time range.
- Eco System - Choose from available options to filter based on a language or an ecosystem.
Search for findings using advanced filters
Use advanced filters to create powerful queries that drill deeper into the dataset to fetch results with a specific context.
Important
Search using the advanced filters applies to the default branch of a repository and does not yield results from other branches.
As an example, if the default branch for the abccorp/devproject
project is set to main
and there is a second branch named bugfix/bug-description
, then using advanced filters in the search won’t yield search results from the bugfix/bug-description
branch, even if you try to filter on the context id or type.
Check Projects to see the default branch of your project. To change the default branch, use --as-default-branch
while performing the endorctl
scan. See scanning strategies for information on testing and monitoring different versions of your code.
The Advanced Filters use the GetFinding
API call to fetch results.
The following table lists some example attributes, you can use in your custom API calls. See also example combinations below.
Attribute |
API Query |
Severity |
spec.level in ["FINDING_LEVEL_CRITICAL","FINDING_LEVEL_HIGH"] |
Category |
spec.finding_categories contains ["FINDING_CATEGORY_VULNERABILITY"] |
Fixable |
spec.finding_tags contains ["FINDING_TAGS_FIX_AVAILABLE"] |
Reachability |
spec.finding_tags contains ["FINDING_TAGS_REACHABLE_FUNCTION"] |
Ecosystem |
spec.ecosystem in ["ECOSYSTEM_MAVEN"] |
EPSS score greater than 10% |
spec.finding_metadata.vulnerability.spec.epss_score.probability_score > 0.1 |
EPSS score less than or equal to 100 |
spec.finding_metadata.vulnerability.spec.epss_score.probability_score <= 1 |
Only query a given project |
spec.project_uuid=="UUID of the project" |
Examples
Show all findings of critical vulnerability and high severity that have a fix available, with a reachable function and EPSS score greater than 10%
spec.level in ["FINDING_LEVEL_CRITICAL","FINDING_LEVEL_HIGH"] and spec.finding_tags contains ["FINDING_TAGS_FIX_AVAILABLE"] and spec.finding_tags contains ["FINDING_TAGS_REACHABLE_FUNCTION"] and spec.finding_metadata.vulnerability.spec.epss_score.probability_score > 0.1
Show vulnerabilities for a specific project
spec.finding_categories contains ["FINDING_CATEGORY_VULNERABILITY"] and spec.project_uuid == "660e2bc48c7d4e60a5fc692f"
Show vulnerabilities for a specific language in a specific project
spec.finding_categories contains ["FINDING_CATEGORY_VULNERABILITY"] and spec.ecosystem in ["ECOSYSTEM_PYPI"] and spec.project_uuid == "660e2bc48c7d4e60a5fc692f"
Save search
You can save the advanced search filters that you created to fetch curated search results. You can easily access the target results and save time.
After typing in the query in the Advance Filter, enter a title in the field on the top right corner and click the Save icon or Save New Filter.
Saved queries are visible in the drop-down list.
Search for exceptions
Findings that are associated with exception policies do not trigger notifications.
To search for findings that are associated with exceptions,
- From the left sidebar, navigate to Projects.
- Search for and select a project, and select Findings.
- From the DEPENDENCY tab, choose Basic Filters.
- Click Exceptions and toggle Show Exceptions.
- You can search for a specific exception policy name, reason, or expiry range to filter the relevant results.
Manage findings
See Finding policies for details on how to configure findings.
Act on findings
See Action policies for details on how to define and trigger workflows based on findings that meet a given set of criteria.
Dismiss findings
Users can dismiss a specific finding if they think it is expected behavior, low priority, or if it is an already addressed incident. This can help reduce clutter.
- From the left sidebar, navigate to Projects.
- Search for and select a project and select Findings.
- Search for findings using advanced or basic filters.
- Click a finding and from Actions choose Dismiss Finding.
The finding is tagged as Dismissed.
Export findings
Users can export finding details to a CSV file for offline analysis.
- From the left sidebar, navigate to Projects.
- Search for and select a project and select Findings.
- Search for findings using advanced or basic filters.
- Click Export Findings and select the fields that you want to include in the CSV file.
- Click Export to CSV.
The file is downloaded to your system.
Apply exception to findings
Add an exception policy to prevent this finding from triggering action policies in future scans.
- From the left sidebar, navigate to Projects.
- Search for and select a project, and select Findings.
- Search for findings using advanced or basic filters.
- Click a finding and from Actions choose Add Exception.
See Create exception policy for details on how to create and apply exceptions.
2 - Dashboards
Discover Endor Labs reporting dashboards.
Dashboards offer a concise and visual way to monitor the security posture of the projects in your organization. They are interactive and help you visualize how you use your projects, packages, and dependencies.
Dashboards provide the following capabilities to monitor potential threats:
-
Gain real-time insights across your code inventory through a range of system widgets that display information in the form of bar graphs.
-
Aggregate and analyze findings, vulnerabilities, and dependencies using visual metrics for a clearer understanding.
-
Monitor most used or least used dependencies through real-time visibility and updates
Endor Labs comes with several out-of-the-box widgets to enable teams to understand potential risks and take preventive measures.
Widgets in the Endor Labs dashboard consolidate related data of one type and provide valuable information.
Scanned by Endor Labs
Displays information on the following scan statistics across all ecosystems in the given tenant:
- Total number of dependencies, categorized into direct and transitive dependencies
- Total number of vulnerabilities, categorized into unreachable and other vulnerabilities
- Total number of projects
- total number of packages
- Total number of scans
- Total number of configured notifications
Vulnerability prioritization funnel
Endor Labs’ vulnerability prioritization funnel systematically assesses and categorizes vulnerabilities based on their severity and category. The vulnerabilities are prioritized in the following order:
- Total open vulnerabilities - Indicates the complete list of vulnerabilities detected in all the scanned projects in this tenant.
- Not in test - Indicates the list of vulnerabilities that are present in the production code and not in the test code.
- Fix available - Indicates the list of vulnerabilities in the production code, for which a fix is available.
- Reachable - Indicates the list of vulnerabilities in production code, with a fix, that can be accessed or exploited.
- Exploitable likelihood - Indicates the list of vulnerabilities in production code, with a fix, that are reachable, and with an EPSS score greater than the specified value. See Configure baseline for EPSS score
By applying this funnel approach, organizations can prioritize addressing the most critical, exploitable, and actionable vulnerabilities first, maximizing their security efforts.
The EPSS scoring system assesses the probability of a vulnerability and indicates how likely it is to be exploited by attackers. Customize the likelihood of exploitability by setting a baseline EPSS score.
- Sign in to Endor Labs and click Dashboard.
- Navigate to the Vulnerability Prioritization Funnel and click EPSS at the end of the funnel.
- In EPSS PROBABILITY, Set a score that is recommended by the application security program of your organization. For example, set it to 8. You can now efficiently prioritize your time by focusing on vulnerabilities that have an EPSS score of more than 8% and remediate them.
- Click Save.
Development hours and cost saved
Visualize the hours and cost saved metrics information on the dashboard.
- Dev Hours Saved - Development hours saved is an estimate that is calculated after reducing the number of vulnerabilities that developers must prioritize. See Customize development hours.
- Cost Saved - Cost savings is an estimate that is made by multiplying the saved developer hours with the full-time equivalent (FTE) hourly cost for triaging vulnerabilities. See Customize cost baseline.
Customize baseline for development hours
Adjust the development baseline to meet your organization’s specific needs.
- Sign in to Endor Labs and click Dashboard.
- Navigate to the Dev Hours Saved and click the vertical ellipsis.
- Choose BASELINE and set DEV HOURS for a record on the Vulnerability Prioritization Funnel,
- Total Open Vulnerabilities - Provide approximate development hours required to triage all open vulnerabilities. By default, the development hours saved are calculated based on this baseline and displayed on the Vulnerability Prioritization Funnel.
- Not In Test - Provide approximate development hours required to triage vulnerabilities in production code.
- Reachable - Provide approximate development hours required to triage accessible and most exploitable vulnerabilities.
- Fix Available - Provide approximate development hours required to triage vulnerabilities that can be addressed with a patch or an upgrade.
- Click Save.
Customize baseline for cost
Tailor the cost baseline to reflect the Full-Time Equivalent cost of your organization.
- Sign in to Endor Labs and click Dashboard.
- Navigate to Cost Saved and click the vertical ellipsis.
- Enter an HOURLY COST and CURRENCY that applies to one full-time employee following your organization’s application security program.
- Click Save.
Top projects metrics
View the top project data by all findings, all vulnerabilities, reachable vulnerabilities, outdated dependencies, and unmaintained dependencies. You can identify the numbers for critical, high, medium, and low risk severity findings. Click the bar graph to view complete details.
Top packages metrics
View package data by all findings, all vulnerabilities, reachable vulnerabilities, outdated dependencies, and unmaintained dependencies. You can identify the numbers for critical, high, medium, and low risk severity findings. Click the bar graph to view complete details.
Top dependencies metrics
View dependency data by all findings, all vulnerabilities, and reachable vulnerabilities. You can identify the numbers for critical, high, medium, and low risk severity findings. Click the bar graph to view complete details.
3 - Dependencies
View dependencies in your project with their details.
You can view project dependencies discovered in your tenant. Additionally, you can search for dependencies using specific criteria or apply predefined filters to find relevant results.
- From the left sidebar, navigate to Dependencies.
- Use the search bar to enter search criteria and to search for dependencies.
- Click Add Filter to filter out dependencies based on specific criteria.
- Click Export Dependencies to export the list of filtered dependencies in a CSV file for offline analysis. You can choose the columns to include in your CSV file from the following fields.
- UUID of the project
- Ecosystem of the project such as Maven, npm, PyPI, GO, Nuget, or more
- Name of the dependency
- Version of the dependency
- Tags associated with the dependency
- Reachability of the dependency
- Is Direct which indicates if the dependency is direct or transitive
- License information such as file, name, type, URL, and license text from the source code that aligns with a known license’s text
- Endor scores such as activity, quality, popularity, and security scores
- Package version name that indicates the fully qualified name of the root package version
- Package version UUID that indicates the root package’s UUID
- Project name that indicates the qualified package name of the root package
- Project UUID that indicates the UUID of the root package
![Export dependencies](../../images/export-dependencies.png)
4 - Endor scores
Understand how packages are scored in Endor Labs
Endor Labs collects and analyzes a large amount of information about open-source and customer packages and uses it to compute scores. Every open source and private package is scored across different dimensions that capture both security and operation aspects of a risk.
Types of scores
Scores provide a high-level, easy-to-understand metric of how well a package does based on factors such as security, activity, popularity, and code quality.
Endor Labs scores are categorized into:
- Security: Indicates the number of security-related issues a package may have such as known vulnerabilities, following security best practices when developing code, and the results of static code analysis. Packages with lower security scores can be expected to have many security-related issues when compared with packages with higher scores. See the factors affecting the security score for more details.
- Activity: Indicates the level of development activity for a package as observed through the source code management system. Packages with higher activity scores will be more active and presumably better maintained when compared to packages with a lower activity score. See the factors affecting the activity score for more details.
- Popularity: Indicates how widely a package is used in its ecosystem by tracking both source code management system metrics (for example, the number of stars in GitHub) as well as counting how many other packages import it. A package with a high popularity score indicates that it is used widely. See the factors affecting the popularity score for more details.
- Code Quality: Indicates how well the package complies with best practices for code development and includes the results of static code analysis of that package’s source code. A package with a higher quality score has fewer code issues. See the factors affecting the code quality score for more details.
Endor Labs performs score computation for various entities such as:
- Repository score - A repository has a score that captures overall repository activity and properties that span multiple versions of the code.
- Repository version score - A repository version has a score that captures details that are specific to a version of the code.
- Package version score - A package version that captures the details that are specific to a package version.
The scoring algorithm considers the following input parameters while calculating the scores:
- Data from a version control system such as Git that provides information about files, versions and their contents.
- Data from a source code management system such as GitHub that provides information about the development activities on a project like issues, pull requests, and more.
- Data from Package managers that provide information about the properties of a package, for example, license, releases and metadata like the number of stars.
- Data from Vulnerabilities that provide information about known security issues in a package.
- Data from Static code analysis tools that provide information about specific issues in the source code of the package.
Score range
The scores for each category range between 0 and 10.
For example, a score of 5 indicates inconclusive analysis and the package is neutral. A score higher than 5 indicates that the package mostly has positive factors while a score lower than 5 indicates negative factors.
A score of 10 indicates that the package meets all the positive conditions, while a score of 0 indicates that a package meets all negative conditions.
4.1 - Activity score factors
Activity scores indicate the level of activity associated with a repository. Activity information is based on metadata gathered from a code hosting and version control system such as GitHub. Higher levels of activity can mean that the repository is well maintained and will continue to be in the future.
The following factors have a positive contribution to the activity score:
- Activity from corporate affiliated accounts that indicate that the project can have reliable backing and support.
- Activity from reputable accounts indicates that the repository is well-maintained. An account is considered reputable if it participates in multiple open-source projects and has a high rating on a source control system such as GitHub.
- Consistent and continuous commit activity over longer periods of time indicates that the project is active.
- The repository has frequent releases indicating a commitment to maintaining and supporting the codebase.
- Activity in the form of comments on issues, show there is engagement in the project.
- A high ratio of issues opened by external contributors indicates that the project is active.
- More issues being closed than opened indicates that the project is active.
- The repository keeps releasing updates to earlier release trains, this is a sign of a commitment to maintaining and supporting the users of the project.
- When a repository belongs to an organization there is a lower risk of it getting abandoned in the future
- Recent issue and commit activity means the project is active.
- Configuring topics is an indication that the repository is well-maintained
The following factors have a negative contribution to the activity score:
- Archived repositories are not active and have a low score.
- A high ratio of rejected pull requests indicates that the project may not be actively developed.
- The Lack of recent issue activity may indicate that the project is not actively used.
- Significantly more pull requests being submitted than merged indicates that the project may not be maintained.
- The repository does not have any recent releases and this could mean that it is not actively maintained.
- When a repository is personal there is a higher risk of it getting abandoned in the future
- If the majority of the repository’s activity comes from a tiny number of accounts, the project could be at risk if these accounts cannot continue their contributions.
4.2 - Popularity score factors
Popularity scores indicate how popular is the repository. Popularity information is based on metadata gathered from a code hosting and version control system such as GitHub. Popular repositories are more likely to be maintained.
The following factors have a positive contribution to the popularity score:
- Many reputable contributors affiliated with the project indicates that the project is reliable. An account is considered reputable if it participates in multiple open-source projects and has a high rating on GitHub.
- The project includes many stars indicating an interest in the project.
- Having subscribers indicates interest in the project.
- Includes many subscribers
- Includes a high number of dependent projects.
- Includes many forks.
- Some released artifacts of the repository are downloaded many times indicating the project is popular.
The following factors have a negative contribution to the activity score:
- Low fork count may indicate a lack of interest in the project.
- Few subscribers may mean a lack of interest in the project.
- Few stars may mean a lack of interest in the project.
4.3 - Security score factors
Security scores indicate the level of compliance with security best practices as well as vulnerability information for the repository that includes open and fixed vulnerabilities. Vulnerability information is based on OSV.dev
data and Endor Lab’s vulnerability database.
The following factors have a positive contribution to the security score:
- Critical and high severity vulnerabilities were discovered in the past in the repository but have now been fixed. This indicates that the code base is properly maintained.
- A SECURITY.md file highlighting security-related information is a sign of repository maturity.
- A high volume of commits related to vulnerabilities may indicate that the project has many security issues but also that they are actively being addressed. A commit is considered vulnerability-related if it mentions a CVE in its commit message.
- No vulnerabilities ever discovered in a repository indicate that there are no known security issues in this codebase.
- Recently fixed vulnerabilities indicate that the repository has lower security risk and is well maintained.
The following factors have a negative contribution to the security score:
- This package has high activity from invalid accounts.
- This package calls any of the following sensitive APIs more often than an average package.
- Access to environment information like environment variables, user and host names. Some of this information may be security sensitive, such as environment variables with API keys.
- Read or write access to the file system. This can be dangerous in combination with user-provided input, for example,, lead to path traversal vulnerabilities.
- Start of operating system processes. This can be dangerous in combination with user-provided input, as it can lead to command or parameter injection vulnerabilities.
- Dynamic programming techniques like introspection, reflection or dynamic code execution through eval() type of functions or script engines.
- Network functions, for example, to open connections or listen for incoming connection requests. This can be dangerous in combination with user-provided input, for example,, lead to data leakage or the load of data from untrusted sources.
- Cryptographic or encoding/decoding functions. Depending on the specific functions used and the data being processed, export control regulations may apply to downstream users.
- This package contains code patterns or shows behaviors that are known to be used by malware. While this is not a guarantee that this package is malicious, a review of the related code is recommended.
- A high fraction of critical vulnerabilities among the discovered vulnerabilities indicates an elevated security risk and potentially systematic security issues with this codebase.
- A high fraction of high-fix priority vulnerabilities among the discovered vulnerabilities indicates an elevated security risk and that the repository needs immediate maintenance. A vulnerability is considered a high priority based on our analysis.
- A high fraction of high severity or critical vulnerabilities among the discovered vulnerabilities indicates an elevated security risk and potentially systematic security issues with this codebase.
- Taking more time to fix critical vulnerabilities discovered in a repository indicates a lack of regular maintenance. The analysis only considers vulnerabilities associated with this repository and not its dependencies.
- A high fraction of releases with high severity vulnerabilities indicates an elevated security risk and potentially systematic security issues with this codebase.
- The package has many unmerged vulnerability-related pull requests means that the project is not actively maintained and may have security issues.
- The repository includes recently discovered vulnerabilities indicating that the repository’s security risk is increasing.
- A high number of critical or unfixed vulnerabilities discovered in a repository indicates an elevated security risk and potentially systematic security issues with this codebase.
4.4 - Code quality score factors
Code quality scores provide a view of code quality and adherence to best practices in a repository. Code quality information is based on metadata gathered from a code hosting and version control system such as GitHub and from the source code in the repository.
The following factors have a positive contribution to the code quality score:
- Activity from bot accounts shows that the project is using automation for some development tasks
- The repository has reached 1.0 release status indicating the first major release milestone and is a sign of maturity
- The project includes test code
- Attaching labels to issues allows for better tracking of issue activity in the project
- The repository has multiple files that cover basic operational aspects of the project and this shows a strong emphasis on best practices
- A large fraction of the commits in this repository are verified; this shows that security best practices are followed
- Pull requests from dependency management bot accounts indicate that the project is using automation to keep its dependencies up to date
- Attaching labels to pull requests helps organize the development activity in the project
- Pull requests from bot accounts indicate that the project is using automation for development tasks
- A large faction of the commits in this repository is associated with a pull request; this shows that development best practices are followed
- The repository has released signed artifacts which is a sign of mature security operations
- The use of continuous integration is a sign of good developer practices
- Using GitHub templates to manage issues shows that the development work in the repository is well-organized
- The repository includes badges
- Displaying the Code Coverage badge means that the repository is using code coverage tools in its development process
- Displaying the Core Infra Best Practices badge means that the repository has met a number of best practices requirements
- The repository includes documentation making it easier to understand and use
- The repository has files that cover basic operational aspects of the project and this shows an emphasis on best practices
- The repository uses CI and a high fraction of commits pass the CI checks which is a sign of good code quality
- Displaying the OSSF scorecards badge means that the repository strives to meet the OSSF scorecard checks
The following factors have a negative contribution to the code quality score:
- This package has many instances of likely incorrect code that is associated with coding issues and potential bugs
- This package has many instances of questionable code warnings that are associated with coding issues and potential bugs
- This project has a high number of indirect dependencies compared to the number of direct dependencies; this additional code increases the cost of building the project and its supply chain risk.
- The repository has many major releases in a short amount of time, this is a sign of high churn and potential instability
- Packages where the package manager license information does not agree with the license information found in the code require additional review
- Packages with multiple licenses require extra effort to determine their exact license status
- Multiple unpinned dependencies can significantly increase the risk of a codebase since packages can be updated at any moment
- Many unreachable direct dependencies unnecessarily increase the size of the codebase and the cost of building it
- The project does not have an automated build system
- The repository does not have any of the files that typically explain the basic operational aspects of the project, this may be an indication that the project is not well-maintained
- Packages or source code without license information or a restrictive license can create operational risk
- This release is old and has been superseded by multiple newer releases, it should not be used
- The repository has releases that do not follow the SemVer standard, this goes against best practices
- When a repository contains binary files it is harder to analyze and assess its functionality and risks
- Lack of access to the source code of the project dramatically limits visibility in its quality and adherence to best practices
- The repository has an unusually fast first release
5 - Call graphs
Mitigate open source vulnerabilities with call graph visualizations, pinpointing and understanding the invocation of vulnerable methods for actionable developer insights.
Endor Labs has developed a systematic approach to conduct call graph analysis. Here is a structured overview:
-
Scope Expansion: Traditional methods of static analysis are typically capable of analyzing a single project at a time. Endor Labs, however, has expanded its scope to include not only the client projects but also their dependencies, often comprising over 100 packages.
-
Enhanced Dependency Analysis: Endor Labs employs static call graphs to conduct detailed dependency analysis, enabling a comprehensive understanding of how different external components interact within client projects. By leveraging these call graphs, Endor Labs aims to minimize false positives and more accurately identify the specific locations of problems in dependencies.
-
Multiple Data Sources: To enrich the analysis, Endor Labs uses both source code and binary artifacts. This ensures swift results without a heavy reliance on test coverage.
-
Benchmarking for Continuous Improvement: Endor Labs maintains accuracy and relevance by using dynamic call graphs internally to benchmark and refine static call graphs, thereby actively identifying and addressing gaps.
-
Scalability: Addressing the challenge of scalability, Endor Labs generates call graphs not only for each project release but also for all its dependencies. This approach enables effective management of large projects with multiple versions, ensuring that the analysis is both relevant and applicable across the entire spectrum of client dependency sets.
For more information, see Visualizing the Impact of Call Graphs on Open Source Security.
Endor Labs UI provides visualizations of call graphs annotated with vulnerability data and simplified into informative call paths. This empowers developers to identify and address problematic invocations of vulnerable methods efficiently.
View call paths
The Endor Labs UI enables you to view call paths, representing the sequences of functions invoked during program execution.
To view call paths in the Endor Labs UI:
-
Navigate to the left sidebar and click My Packages.
-
Expand the package of interest and select a version by clicking the respective row.
-
In the findings list view, expand a specific finding, and click See Call Paths.
![Call Paths](../../images/call-paths.png)