C/C++

FOSSA supports C and C++ codebases through three strategies designed to detect and/or track dependencies

Table of Contents

• How It Works
• Constraints
• Using it

How It Works

Detecting Vendored Source Code

The FOSSA CLI scans the project, generating cryptographic fingerprints of the files in the project. The CLI then uploads those fingerprints and their associated file paths to a backend service in the FOSSA Cloud.

The fingerprints derived from the files are designed to handle changes to the comments and whitespace in the file, so changes to those areas of the file don’t stop the matching algorithm from working. It is impossible to derive the original code from the fingerprints that are uploaded: they’re known as “one way cryptographically secure” hashing functions. Specifically, we use the SHA256 algorithm to fingerprint the code after in-memory transformation in the FOSSA CLI, and only those secure fingerprints (and associated file paths) are uploaded.

The backend service compares the uploaded fingerprints and paths to the fingerprints of known open source projects in the FOSSA database at the directory subtree level, meaning that it algorithmically matches across subdirectories of the scanned project with open source projects that use similar directory trees. If a subtree matches more than one project or more than one version of a project, the backend chooses the statistically most likely candidate to report as the detected dependency for that subtree.

Once the backend has evaluated the whole project, it reports the list of dependencies to the FOSSA CLI, which then bundles those identified dependencies up with any others it finds in the scanned project via other analysis strategies. Finally, the entire set is uploaded to the FOSSA instance and made available to view as a project.

Tracking Statically-linked Libraries

Since statically linked libraries are compiled directly for a target OS and architecture, it is difficult to perform similar matching with them as we do for source code. Instead of identifying such static libraries, we provide users the ability to track the use of static libraries in their applications.

When a team builds a static library for internal distribution in an organization, they can integrate the FOSSA CLI into their CI pipeline. The FOSSA CLI scans the source code of the project building the static library and registers the static library in FOSSA, attached to that project.

Then when another project vendors that static library somewhere in its directory tree, FOSSA identifies that static library inside the project directory and links the original project that built the static library as a dependency in the dependencies view.

Detecting Dynamically-linked Libraries

The FOSSA CLI integrates into the CI pipeline after a build completes, and is provided a path to the output binary of the project being scanned. The CLI then uses built-in tooling in the operating system to determine which libraries are dynamically loaded by the binary at runtime and then uses the system package manager to determine the owning package for each of those dynamically loaded libraries.

Finally, the CLI uploads the libraries, along with the name and version of the OS, to the FOSSA backend just like any other library. The FOSSA backend then uses our database of operating system libraries to determine licensing and vulnerability information for each dynamically linked dependency.

Constraints

Detecting Vendored Source Code

📘

Vendored Source Code

Library source code must be “vendored” in the project directory tree, meaning that some meaningful portion of the original source code (or source code with only comment and whitespace modifications) present in the open-source library is present in a standalone directory tree inside the project.

The following is a very basic example of a directory structure that the vendored source code strategy would be able to use to disambiguate third party code from first-party code:

/project
  /src
    main.c
  /libs
    /lib_a
    /lib_b

A counterexample is a case where open source code and first party code are mixed together inside the same directory. In such cases the algorithm may be able to detect the library anyway if enough of the directory is made up of the library that it is able to be statistically confident of the library being present, but if too much of the directory is made up of first party code the algorithm can no longer confidently claim that the library is present, and it will be unreported.

Tracking Statically-linked Binaries

The static library registered in FOSSA must be present in the actual source tree of the project using it in order for it to be detected. If the static library is used from some central location in a build system, it cannot be detected through this system.

Detecting Dynamically-linked Libraries

Dynamic link detection is supported on the following platforms:

• Linux
  • Debian-based distributions (Debian, Ubuntu, etc)
  • Redhat-based distributions (Redhat, CentOS, Fedora, etc)

Dynamic link detection makes use of local build tooling and system package managers, so the following must be present in the $PATH when running the FOSSA CLI:

• Debian-based distributions (Debian, Ubuntu, etc):
  • ldd
  • dpkg
• Redhat-based distributions (Redhat, CentOS, Fedora, etc)
  • ldd
  • rpm

CLI (fossa-cli)

To get started, install the latest release of fossa-cli from our Github Releases page. We always recommend using the latest version of the CLI whenever possible, but C/C++ support requires version 3.1.3 or greater.

curl -H 'Cache-Control: no-cache' https://raw.githubusercontent.com/fossas/fossa-cli/master/install-latest.sh | bash

Once installed, run fossa analyze inside of your repo's root directory to analyze your project.
Scanning C and C++ projects requires the use of additional options, documented below.

These options are all able to run alongside one another or any other dependency identification strategy used by the FOSSA CLI: dependency identification strategies in the FOSSA CLI are additive.

For more information on these or other dependency identification strategies in the FOSSA CLI, see our CLI documentation.

Detecting Vendored Source Code

Use the --detect-vendored flag to enable vendored source code identification.

fossa analyze --detect-vendored

Detecting Dynamically-linked Libraries

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

fossa analyze --detect-dynamic out/bin/service

Tracking Statically-linked Libraries

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

While most of FOSSA's C and C++ support is supported, this portion of functionality is still experimental; see FOSSA's CLI documentation for more details.

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