C and C++ are popular languages because of their performance and ubiquity, especially in performance-critical domains such as browser engines, databases, and games.

But, historically, many organizations have faced challenges identifying dependencies in these languages. This is because C and C++ are unmanaged languages lacking manifests. While a few package managers like Conan exist, they are not universally adopted. Each organization has its own way of using and organizing dependencies in C and C++ projects, so accurately identifying dependencies in any arbitrary C or C++ project is rather complex.

FOSSA is excited to announce the GA of our security and license scanning for C and C++ projects, which will help users tackle these challenges and secure their mission-critical applications.

Unlike other C/C++ scanning tools, FOSSA does not take a one-solution-fits-all approach to dependency identification in such a complex and layered ecosystem. FOSSA uses multi-pronged strategies (as described below) to accurately identify dependencies and surface security and license risks — regardless of how the code is included.

Using FOSSA C/C++ Security and License Compliance

To get started with FOSSA C/C++, download FOSSA CLI version 3.1.3 or later from our GitHub releases page.

The next step depends on how C/C++ dependencies are included in your project — since they are unmanaged languages, there are a few ways that C/C++ could be used in your organization.

Vendored Code

In this scenario, C/C++ dependencies are included via an src or vendor folder as shown below. Since these dependencies are considered part of their first-party projects, the open source dependencies also get built along with the first-party project.

Detecting Vendored Source Code Dependencies

Use the --experimental-enable-vsi flag to enable vendored source code identification.

Example
fossa analyze --experimental-enable-vsi

Static Linking

In some cases, teams distribute the binary and its associated headers instead of vendoring the code. Typically, these statically linked binaries are also stored inside the project directory, as shown in the screenshot below.

Detecting Statically Linked Dependencies

Use the --experimental-link-project-binary <DIR> flag to enable registering files in the provided directory as outputs of the project being analyzed.

Example
fossa analyze --experimental-link-project-binary out/bin/

Dynamic Linking

This is the most popular way of including dependencies in C/C++ projects. It involves using pre-built dependencies that are typically provided by the operating system package manager; the application loader then links them into the first-party application at run time

Detecting Dynamically Linked Libraries

Use the --experimental-analyze-dynamic-deps <BINARY> flag to enable inspecting the binary at the provided path for dynamically linked libraries.

Example
fossa analyze --experimental-analyze-dynamic-deps out/bin/service

Once scanning is done, you can find a summary of your security and licensing issues in the FOSSA dashboard. You can proceed to triage, resolve or remediate them.

We will begin rolling this feature out to customers next week. For any questions or feedback, please reach out to us at support@fossa.com. If you aren't currently a FOSSA customer but are interested in trying this feature, you can request a demo here.