C/C++ Application Analysis

You can analyze C/C++ applications for risks in two ways: CPE-based vulnerability matching, which leverages standardized Common Platform Enumeration identifiers, or Conan coordinate-based matching, which evaluates components by their package coordinates.

Common Platform Enumeration (CPE) Matching

CPE matching is configurable at the organization or application level via the UI or the CPE Matching REST API and its default state varies by IQ version and license.

CPE matching is available starting in IQ 193: on fresh IQ 193+ installs it’s enabled by default, but if you’ve upgraded from IQ 192 or earlier you must enable it manually (and availability still depends on whether you’re on an SBOM Manager-only, Lifecycle-only, or multi-solution plan). For full details, see the CPE Matching Experience per Solution table.

You can enable CPE Matching at the root organization (cascading to child orgs/apps via inheritance) or apply it selectively to individual applications, maintaining compatibility with existing workflows while extending coverage to any C/C++ component that includes a CPE identifier.

CPE Matching lets you leverage standardized Common Platform Enumeration identifiers embedded in your SBOM to detect known vulnerabilities in C/C++ components, even when those components aren’t published via Conan. When enabled, the scanner will:

Ingest the SBOM and locate each <cpe> element; or for components carrying only a generic purl (e.g. pkg:generic/...@version) or an unsupported purl format with no hash match, treat them as CPE candidates for matching.
Match each CPE string directly against Sonatype’s vulnerability database (which includes mappings from CPEs to CVEs sourced from public data like the NVD).
Evaluate all matches against your configured policies, reporting pass/fail results just like coordinate-based scans do.

To understand how CPE-derived findings are merged and displayed alongside other vulnerability sources in SBOM Manager and Lifecycle, see the Data Merging and Display Logic section.

SBOM Filenames for Lifecycle

For Sonatype Lifecycle to automatically detect and scan SBOMs (both SPDX and CycloneDX), the SBOM file must appear in the root of your scan target and follow these naming conventions:

CycloneDX (see CycloneDX Application Analysis):
- bom.xml
- <source>-bom.xml or <source>-bom.json
- <publicAppId>_<version>_<timestamp>.cdx.xml or .cdx.json
SPDX (see SPDX Application Analysis):
- spdx.xml or spdx.json
- <source>.spdx.xml or <source>.spdx.json

Basic CPE Matching Example

Given this CycloneDX SBOM:

<?xml version="1.0" encoding="UTF-8"?>
<bom xmlns="http://cyclonedx.org/schema/bom/1.6" version="1" serialNumber="urn:uuid:123e4567-e89b-12d3-a456-426614174000">
  <components>
    <component type="library">
      <name>firefox</name>
      <version>78.0</version>
      <cpe>cpe:2.3:a:mozilla:firefox:78.0.1:*:*:*:*:*:*:*</cpe>
    </component>
  </components>
</bom>

The scanner reads the <cpe> value and reports any CVEs associated with Mozilla Firefox 78.0.1 against your configured vulnerability policies.

CPE Matching Scenarios

Below is a table illustrating a variety of component metadata scenarios and how the scanner applies CPE-based (and coordinate-based) matching in each case:

Component Identifier	Matching Behavior	What You See in the UI
Hash	If a catalog hash match is found, we link that exact component to its vulnerabilities; otherwise, a lone hash is ignored unless paired with a PURL or CPE.	High-fidelity, hash-linked vulnerabilities. Unmatched hashes without PURL/CPE are omitted.
Supported formats / ecosystems (Maven, npm, Go, etc.)	We look up the package coordinate (group/name/version) in our catalog. See the Analysis section for details.	High-fidelity coordinate-linked vulnerabilities. If no match, the component is shown as third-party with no detailed CVEs.
Unsupported formats / ecosystems (deb, apk, rpm, etc.)	We treat the PURL as a CPE candidate and attempt to match it against our data. See the Analysis section for details.	If matched, you see CPE-based vulnerabilities. Container image PURLs are skipped for CPE to preserve container context.
CPE	We directly match the CPE identifier in your SBOM against our vulnerability database.	CPE-derived CVEs appear alongside (or instead of) other matches, according to your display settings.
Generic / unsupported PURL (without version or CPE)	Without a version or CPE, we skip detailed matching and process the component as “Third Party.”	Displayed as a third-party component with no matched vulnerabilities.

Conan coordinate-based matching

The Conan coordinate-based matching feature provides the ability to scan and evaluate C/C++ dependencies found in either a conanfile.txt, conanfile.py, or conaninfo.txt file.

What is supported

Files named conanfile.txt, conanfile.py or conaninfo.txt will be analyzed.

What do we parse from the files?

In `conanfile.txt`

Only dependencies with an exact version under the "requires" and "build_requires" groups are evaluated, for example:

[requires]
      apache-apr/0.9.1@jgsogo/stable

[build_requires]
      libxml2/2.9.8@bincrafters/stable

In `conanfile.py`

Only dependencies with an exact version (directly as strings, not built using python code) in the attributes "requires", "build_requires" and the methods "self.requires" and "self.build_requires" are evaluated, for example:

from conans import ConanFile, CMake

class ExampleConan(ConanFile):
        build_requires = "libxml2/2.9.8@bincrafters/stable"
        requires = "opencv/2.2@drl/stable"

        def requirements(self):
                self.build_requires("apache-apr/0.9.1@jgsogo/stable")
                self.requires("zlib/1.2.0@conan/stable")

In `conaninfo.txt`

Dependencies under the "requires" and "full_requires" groups are evaluated, for example:

[requires]
    glm/0.9.7.6

[full_requires]
    zlib/1.2.11@conan/stable:ec336a8e46e06995be9ad34dc1a7477dff42a7df

Steps to analyze using the CLI

Invoke a CLI scan of a directory or subdirectories containing either a conanfile.txt, conanfile.py or conaninfo.txt file. Instructions on how to do this can be found here: Sonatype IQ CLI.

Examples for each Conan file can be found above in the document.

Steps to analyze using the Jenkins plugin

By default, the Jenkins plugin will not evaluate the conanfile.txt, conanfile.py, and conaninfo.txt files. A custom Scan Target is needed.

Example Pipeline Script with Scan Patterns

nexusPolicyEvaluation iqApplication: 'SampApp', iqScanPatterns: [[scanPattern: '**/conanfile.txt'], [scanPattern: '**/conanfile.py'], [scanPattern: '**/conaninfo.txt']], iqStage: 'build'

To find more information on how to configure Jenkins please go to Sonatype Platform Plugin for Jenkins.

Steps to analyze using the Bamboo plugin

Bamboo Scan Targets control what files are examined. To evaluate C/C++, add conanfile.txt, conanfile.py, and conaninfo.txt to the scan targets via a comma-separated list e.g.

Example Bamboo Scan Patterns

**/conanfile.txt,**/conanfile.py,**/conaninfo.txt

To find more information on how to configure Bamboo please go to Sonatype For Bamboo Data Center.