# 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](https://help.sonatype.com/en/public-data-sources.html "Public Data Sources for CPE Vulnerabilities") or the [CPE Matching REST API](https://help.sonatype.com/en/cpe-matching-rest-api.html "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](https://help.sonatype.com/en/cpe-matching-experience-per-solution.html "CPE Matching Experience in SBOM Manager vs. Lifecycle") 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 `` 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](https://help.sonatype.com/en/sonatype-vulnerability-data.html "Sonatype Vulnerability Data") (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](https://help.sonatype.com/en/cpe-matching-experience-per-solution.html#lifecycle-data-merging-and-display-logic-390066 "Lifecycle 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](https://help.sonatype.com/en/cyclonedx.html "CycloneDX Application Analysis")): - `bom.xml` - `-bom.xml` or `-bom.json` - `__.cdx.xml` or `.cdx.json` - **SPDX** (see [SPDX Application Analysis](https://help.sonatype.com/en/spdx-application-analysis.html "SPDX Application Analysis")): - `spdx.xml` or `spdx.json` - `.spdx.xml` or `.spdx.json` ### Basic CPE Matching Example Given this CycloneDX SBOM: ``` firefox 78.0 cpe:2.3:a:mozilla:firefox:78.0.1:*:*:*:*:*:*:* ``` The scanner reads the `` 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](https://help.sonatype.com/en/analysis.html "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](https://help.sonatype.com/en/analysis.html "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](https://help.sonatype.com/en/sonatype-iq-cli.html "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](https://help.sonatype.com/en/sonatype-platform-plugin-for-jenkins.html "Sonatype Platform Plugin for Jenkins - Lifecycle"). ### 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](https://help.sonatype.com/en/sonatype-for-bamboo-data-center.html "Sonatype for Bamboo Data Center"). ## Search results No results found