Modern software relies on complex code, external libraries, and open-source components (OSS). Managing risks requires understanding where issues come from, such as internal code, OSS, or other external dependencies.

Dependencies in a project can be classified as direct or transitive. Direct dependencies are explicitly added by developers, such as when a specific library is included in a project. Transitive dependencies are those pulled in indirectly through other libraries. While direct dependencies are easier to track and manage, transitive dependencies can introduce complexity, as they may not be immediately visible in the project’s configuration files.

Categorizing code as reachable, potentially reachable, or unreachable is another important step. Reachable code is actively invoked during normal execution. Unreachable code, on the other hand, is not used at all and can accumulate over time, leading to unnecessary complexity and potential issues. Identifying and managing these categories ensures that the codebase remains efficient and maintainable.

To help developers and security teams make informed decisions for SCA results, Endor Labs leverages a static analysis technique called program analysis to perform function-level reachability analysis on direct and transitive dependencies. This is the most accurate way to determine exploitability in the context of your application, which is critical for determining which risks should be remediated.

Function-level vs dependency-level reachability

Endor Labs supports dependency-level reachability by default for all supported languages. This type of reachability analysis is more coarse-grained than function-level reachability. It indicates that the imported package is being used somewhere in the application but does not determine whether the vulnerable package is being called by the source code.

The dependency-level reachability can be used as a good indicator for prioritization. If you’re not actually using the dependency at all, then removing that dependency could be a consideration. Determining whether or not a dependency is being called or used is another layer of prioritization you can add to your remediation process.

Dependency reachability Labels

The different dependency reachability labels include:

• Reachable Dependency: Endor Labs established that an imported package is being used somewhere in the application.

• Unreachable Dependency: Endor Labs determined that the imported dependency is not being used. The customer can use this information to remove the dependency, which is helpful for technical debt reduction initiatives.

• Potentially Reachable Dependency: Endor Labs cannot definitively determine whether a dependency is or is not in use, generally because a given language or package manager is not supported.

Function-level reachability labels

The different function reachability labels include:

• Reachable Function: Endor Labs has determined that there is a path from the developer-written code to a vulnerable function, indicating that the finding is exploitable in your environment. This is demonstrated by a call graph that illustrates each step between the source code and the vulnerable library.

• Unreachable Function: Endor Labs has determined that there is no risk of exploitation, as there is no path from the source code to the vulnerable function. This conclusion is supported by a call graph that demonstrates the absence of such a path.

• Potentially Reachable Function: Endor Labs is unable to determine whether a finding is reachable or unreachable, typically because call graph analysis is unsupported for a given language or package manager. This means that the function in question may be executable in the context of the dependent project, but the analysis cannot definitively determine if it is reachable or not.

Phantom dependencies

Phantom dependencies are packages utilized in your codebase that are not explicitly declared in your project’s manifest files, for example, package.json, or requirements.txt. These undeclared dependencies can pose significant security and operational risks, as they may contain vulnerabilities not tracked or assessed during standard dependency analysis. Identifying and managing phantom dependencies is crucial for accurate reachability analysis and comprehensive risk assessment.

Detection of phantom dependencies

Endor Labs’ reachability analysis conducts thorough scans of your codebase to identify functions and methods invoked from both declared and undeclared dependencies. By analyzing the actual usage of packages in your source code, the system identifies phantom dependencies—those that are in use but not explicitly declared. This detection ensures that all utilized code paths are assessed for potential vulnerabilities, providing a more accurate and comprehensive security evaluation.

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 uses static call graphs to perform dependency analysis at a fine-grained level. It is minimally intrusive to the developer workflow and provides results during development.

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.

Call paths are supported for Java, Python, Rust, JavaScript, Golang, .NET (C#), Kotlin, and Scala.

View call paths

Endor Labs allows you to view call paths, which represent the sequences of functions invoked during program execution.

1. Select Projects from the left sidebar.

2. Select the project for which you want to view the call path.

3. Select FINDINGS and select the finding from the list view.

4. Expand a specific finding to view more details.

   

5. In the details section, select CALL PATHS.

   

   A finding may have multiple call paths.

Endor Labs collects and analyzes a large amount of information about open-source packages and uses it to compute scores.

• Every open-source package is scored across different dimensions that capture both security and operation aspects of a risk.

• Every AI model is scored on a multidimensional scoring system grouped into four main categories: security, activity, popularity, and operational integrity.

Each category’s Endor score represents the average of all contributing factors within that category. See View scorecards for more information on checking Endor 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.

Input data for score calculation

For calculating scores of vulnerabilities, 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.

To evaluate AI models effectively, we use a multi-factor scoring system that assesses popularity, activity, operational integrity, and security.

Each model is assigned a composite score based on the following criteria:

Popularity score factors

The popularity score reflects the model’s adoption and recognition within the AI community. Higher scores indicate greater usage and community engagement.

• Number of downloads: More downloads indicate widespread adoption.

• Number of likes: More likes suggest a positive reception from users.

• Published papers: Models with linked academic papers receive higher credibility.

• GitHub repository: Models with an associated GitHub repository score higher.

• Number of spaces using the model: More integrations suggest broader utility.

Scoring approach

• Models with many downloads, likes, citations, and integrations score higher.

• Models with fewer engagements score lower.

Activity score factors

The activity score measures how actively a model is discussed and maintained.

• Discussion posts: Active community discussions contribute positively.

• Pull requests: Indicates ongoing maintenance and improvements.

Scoring approach

• Models with frequent discussions and active pull requests score higher.

• Models with limited activity receive lower scores.

Operational score factors

The operational score assesses the model’s reliability, transparency, and usability.

• Reputable provider: Models from well-known sources score higher.

• Model age: Older, well-maintained models may score higher, but outdated models may receive penalties.

• Authorization requirements: Restricted-access models score lower for accessibility but may gain points for security.

• Gated models: If a model requires special access, it may impact usability.

• License information: Models with clear licensing receive higher scores.

• License type: Open licenses (permissive, unencumbered) generally score higher than restrictive ones.

The following factors related to the availability of model metadata are also considered.

• Metric information: Essential for model evaluation.

• Dataset information: Transparency about training data boosts score.

• Base model information: Important for derivative works.

• Training data, fine-tuning, and alignment training information: Increases credibility.

• Evaluation results: Demonstrates model performance.

Scoring approach

Models with comprehensive metadata, reputable providers, and clear licensing score higher.

Models with unclear ownership, restrictive access, or missing details score lower.

Security score factors

The security score evaluates potential risks associated with a model’s implementation and distribution.

• Use of safe tensors: Secure tensor formats boost safety score.

• Use of potentially unsafe files: Formats such as pickle, PyTorch, and Python code files pose security risks.

• Typosquatting risks: Models that could be impersonating popular models receive lower scores.

• Example code availability: Models that contain example code or code snippets can introduce potential issues and hence receive lower scores.

Scoring approach

Models that follow best security practices such as safe tensors, clear documentation, or vetted repositories score higher.

Models receive lower scores if they use potentially unsafe formats such as pickle (.pkl) and unverified PyTorch (.pth) or show signs of typosquatting.

Final score calculation

Each category contributes to the overall model score. The final score is a weighted sum of these factors, with weights adjusted based on real-world relevance and risk impact.

Higher scores indicate well-documented, popular, actively maintained, and secure models, while lower scores highlight potential risks or lack of transparency.

This scoring system enables users to make informed decisions when selecting AI models for their projects.

Endor Labs continuously refines and expands its evaluation criteria; this document represents the current methodology snapshot.

Endor Labs detects malware in dependencies by scanning the packages used in the project and recognizing known malicious patterns.

Monitoring for Known Malicious Packages: Scan dependencies to identify malware by cross-referencing findings with the Open Source Vulnerability (OSV) database.

Suspicious Code Behavior: Use malware detection rules and Semgrep-based rules to scan open source packages dependencies for suspicious code patterns and behaviors. These rules analyze code structures, detect anomalies, and identify potential threats.

Classification of malware

When Endor Labs detects known malware in your dependencies, it raises a critical priority finding in your namespace for immediate remediation.

If a suspicious code pattern is detected in a dependency, a low priority finding is raised, and a security score is assigned to the package. Our security team evaluates the finding based on multiple factors, such as the nature of the detected pattern and its potential impact. If confirmed as malware, a critical priority finding is raised in your namespace and reported to you. Otherwise, it is dismissed as a false positive.

See Security score for more information.

View malware findings

You can view the malware findings, prioritize them, and take corrective action.

1. Sign in to Endor Labs and select Projects from the left sidebar.
2. Select the project for which you want to view the malware.
3. Select Malware under Code Dependencies to view malware findings.

4. Select a finding to view detailed information of the malware in the right sidebar.

   The right sidebar contains the following information:

• Project: The name of the project where the malware is found, finding policy, categories and attributes of the project.
• Risk Details:
  • Indicates if the identified secret is valid or invalid.
  • Explanation of the finding.
  • Recommended remediation.
• Metadata: Contains details such as the vulnerability ID, ecosystem, publication date, and security metrics.

5. Click View Details to explore additional information about the malware findings such as FIX INFO, DEPENDENCY PATH, and CALL PATHS.