C/C++ Libraries Support

[sahil3112]

Does Dependency Track able to find Vulnerability in C/C++ libraries if yes, then How we generate SBOM for C/C++ Libraries?

[stevespringett]

Dependency-Track is ecosystem and language agnostic, as is CycloneDX.

There are several package managers for C/C++ including Conda and Buckaroo. Using a package manager is obviously recommended as the SBOM can be automatically generated from it. I'm pretty sure Jake, an open source tool created by Sonatype, can generate CycloneDX from Conda environments.

Conda packages are supported by OSS Index, so you'll be able to analyze the packages using Dependency-Track for known vulnerabilities. To my knowledge, GitHub Advisories does not support Conda as of now.

However, in my experience, most C/C++ projects are stuck with practices dating back to the '70s, including manual dependency management and untracked changes to third-party and open source code. In these cases, manually maintaining a BOM may be necessary until such time the project can adopt modern development practices.

In all cases, a source BOM can also be generated using the CycloneDX CLI, however, source BOMs are not overly useful for vulnerability management and similar cybersecurity use cases.

[Kretikus]

For our C++ Project, I am keeping a handbuild BOM.json file in the repository. Since we only have a handfull dependencies (which we are distributing in via an internal nuget server to the developer machines) managing them by hand is less effort than introducing more bloat by adding any tool as abstraction.

I am creating CPE 2.3 entries by searching for exising CPEs at https://nvd.nist.gov/products/cpe/search Most of the used libraries had at least one CVE entry yet.

In general, C++ might still be dependency-wise in the 70s, but If we would only have C++ Projectswe would not need dependency-track. This need came with NPM and maven pulling in too many dependencies for my taste.

[gurucubano]

We are also creating BOM XML files with some tools for the used C/C++ libraries and for other OpenSoftware components (OpenLDAP, Apache http_server, ...). We fill only these three fields for any given component:

    <component type="library">
      <name>http_server</name>
      <version>2.4.53</version>
      <cpe>cpe:/a:apache:http_server:2.4.53</cpe>
    </component>

What I'm struggling with, is the <name>...</name> XML tag. It is necessary, but is it content somehow technical relevant, or only to identify the entry in the Dependency Track page about the components of the project?

[stevespringett]

@gurucubano The name element is not technically relevant and can be whatever you like. Like most things in the CycloneDX object model, the elements have context. So from a specification perspective, the only thing of possible technical relevance is if the component type is a file then the name becomes the file name with or without the path.

Currently, Dependency-Track doesn't use this information, but likely will in a future version.

[gurucubano]

@stevespringett I couldn't find a complete description of all the elements in the XML BOM file, is there any? Thanks.

[stevespringett]

JSON docs: https://cyclonedx.org/docs/1.4/json/ XML docs: https://cyclonedx.org/docs/1.4/xml/

[gurucubano]

One more question. We have ASCII tables with around 700 components our System is depending on for building and running (a complete Library Management System). We do have name and version, but not cpe. What would be the best approach to get the 700 cpe values?

[stevespringett]

The CPE dictionary is the only authoritative source and the data is a mess. CPE also suffers from a chicken/egg issue in that CPEs are typically not created until a vulnerability in the NVD exists. So it's not possible in most cases to proactively monitor something that hasn't had a CVE previously.

DT will likely be including fuzzy matching of CPEs in a future release. We supported that use case back in v3.0 - 3.6 I think and the implementation was problematic and resulted in an extreme number of false positives. In the new fuzzy matching implementation, we're taking a very different approach and it will be disabled by default.

If you can find PURLs for your components, that may provide a way to bridge the gap between CPEs not existing, and you'll be able to take advantage of OSS Index and GitHub Advisories for any component with a PURL.

[gurucubano]

@stevespringett Thank for your feedback. I found a relatively easy way to get to the 700 CPEs: I fetched the CPE dictionary as a compressed XML file, uncompressed it with gzip and can now grep through the name elements of it. This is more handy than the search through the web interface.