An Important Note

In this guide, we demonstrate Software Composition Analysis (SCA) results for a specific point-in-time version of OpenCV using Endor Labs' SCA security tool. We do not mean to imply that OpenCV is flawed or insecure. We picked OpenCV for its popularity and variety of dependency locations, not as an example of poor supply-chain security. 

Introduction

Software Composition Analysis for C/C++

Software Composition Analysis (SCA) is becoming increasingly essential for identifying third-party code in software, particularly in light of the rise of supply chain attacks. This is especially critical for C and C++ applications, which are common in embedded systems, medical devices, telecommunications, and on-premises infrastructure. These systems often operate in environments where patching is infrequent or impractical, making early detection of vulnerable or untrusted code essential.

SCA also supports the creation of Software Bills of Materials (SBOMs), which list all software dependencies. SBOMs help customers and regulators verify what components are in use and assess exposure when new vulnerabilities emerge.

Challenges in C/C++ Analysis

Traditional SCA tools are less effective for C/C++ due to the absence of standard package managers and inconsistent dependency management. Developers often copy or statically link third-party code, modify it, or use code from various sources, such as GitHub or SourceForge—the use of static and dynamic linking, inlined headers, and modified sources further obscures dependency origins.

Binary-based analysis is also tricky. Build systems like Make or CMake vary widely, complicating dependency detection. Preprocessor directives and custom build scripts limit visibility, making it harder to identify third-party components and assess associated risks. As a result, security teams often lack clear insight into the dependencies in critical C/C++ systems.

In a recent blog post and white paper, Endor Labs announced support for C/C++, describing a novel methodology and making impressive claims of accuracy compared to competitors.  However convenient it would be for vendors if potential customers simply believed all our claims, we recognize that skepticism is a critical attribute for security practitioners. With this in mind, we have prepared this testing guide to enable you to compare Endor Labs with other SCA offerings for C/C++. 

Testing Method Overview 

For testing, we have chosen to use the OpenCV package and have selected a specific commit. Using a fixed version of the software is essential, as mainline code may change between testing.  As noted above, the  project we selected was  based on  popularity and the variety of dependency sources. Nothing in this testing guide should be interpreted as a criticism of OpenCV or its contributors. 

This guide will help you  run Endor Labs SCA against the project, capture the results, and compare them with your existing tool.  In this case, we are solely concerned with accurately identifying all the dependencies in the package, rather than worrying about any vulnerabilities in them (although some vulnerabilities will be reported in the results you see).  

The accuracy metrics we are interested in are:

• False Positives - dependencies  incorrectly  identified (either wrong package or version)
• False Negatives - dependencies not identified 

While it would be great to be one hundred percent accurate on all occasions, for the reasons noted in the introduction above, C/C++ presents many challenges to practical composition analysis, making it difficult to achieve perfect accuracy. 

Prerequisites 

While this test is pretty simple to run, there are some prerequisites:

1. An Endor Labs account: If you don’t already have one, you can request a demo account and receive a quick demo by filling out a simple form.
2. A supported operating system (Windows, Linux, macOS) to run the Endor Labs binary.
3. Internet access to obtain the binary, test project, and baseline results.
4. The git utility (to clone the test project).
5. (Optional) You can access a copy of the scripts used in this tutorial in this GitHub project

Running the Test

Environment Setup 

Once you have received your demo account, log in to the UI to check that you have access.

Download and install the endorctl utility on the platform you will use for testing. 

Authenticate endorctl to Endor Labs, e.g.  

endorctl init --auth-mode-google

Clone the Test  project 

Since we want to test against a specific commit, we’ll have to clone and then create a new local branch using the commit ID  we want to test against:

First, clone the repo: 

git clone https://github.com/opencv/opencv.git

Now we branch the local repo to a specific commit (43cebe52eba056d9fbb1115928cf698ae44abd60)

cd opencv

git branch endor-test 43cebe52eba056d9fbb1115928cf698ae44abd60

git switch endor-test 

Run the Endor SCA Scan

The endorctl utility is used to run the scan:  

endorctl scan -l c                         

There are some options for output; the default we are using here will output a table for easy reading.  For further processing, a JSON file format is also available. The results directly from the command will show only dependencies that contain vulnerabilities or have problematic licensing. Therefore, we will use the Endor Labs console and the API call option in endorctl to view a complete inventory. 

Viewing the Results

The endorctl command will produce a table-formatted output, which is useful but not what we need for easy comparison. 

The easiest place to view the results initially will be in the Endor Labs console. 

When you log in, the first thing you see will be  the dashboard:

From the left-hand navigation pane, choose “Projects” to get a list of your scanned projects:

Next,  choose your project and select the Inventory tab:

Here, you see a list of detected dependencies; you can drill into each one for further details, but that’s probably best left for another blog.  What we want to do is provide you with an easy way to compare this to your existing SCA tool. 

We will generate a comprehensive list of dependencies and format it as a simple CSV, making scripting comparisons easy. 

The one thing we will need to know is the project UUID, which can be obtained by either hitting the “<> Raw Data” button on the project's home page and looking at the UUID field in the project JSON, or directly from the URL:

With this UUID, we can run an endorctl command to pull just the data we require:

Process the Results 

The above command will output our data into a JSON-formatted file (in this case,  pkglist.json), which we can easily process using a simple Python script. You can find a copy of this script and others used in this project on GitHub.

This script performs simple normalization, stripping the leading  “https://” or “http://”, and setting all values to lowercase. You can download the script from the Endor Labs public git repository.

Run the command:  

api_data_parser2.py pkglist.json pkjlist.csv 

Examine the output: 

Examining the file, we see the dependency and package names listed in a comma-separated format, making it easy to compare with any other generated list. 

Here’s an example Python script to do just that: 

Now you can easily compare results with any other simple CSV list, created by a tool of your choice. 

Conclusion 

This guide has provided the framework to evaluate Endor Labs' C/C++ SCA capabilities. By running your own scans and comparing the results, you can gain a clearer understanding of your software supply chain. This process aims to reveal dependencies, enhance accuracy, and contribute to a more secure environment for your C/C++ applications. Further testing resources will be made available to support continued evaluation.

You can read our technical white paper to learn more about our approach to SCA for C/C++.