Support for "dll" references (non-nuget) projects in .NET based projects

[tarakg]

Can we add support for including components that are added as "dll" references in .NET projects, in the generated CycloneDX BOM? I understand that the "dll" reference may not have all the information CycloneDX spec will require - but for teams who need to aggregate all their components to BOM - this will be a good feature. This feature could be added as optional, managed by a optional parameter to the tool.

[stevespringett]

I believe the minimum requirement for a component is the type, name, and version.

[tarakg]

@stevespringett And, I do agree - type, name and version is needed. Will it be feasible to to pick the relative paths (of dynamic link libraries) from the .NET project file, then retrieve the name and version information directly from the libraries, and add it to the BOM?

[coderpatros]

@tarakg is this full framework or .core? And I think for explicitly referenced dlls this should probably be default behaviour.

[tarakg]

@coderpatros I would like it to support both. One thing I figured out though is that this tool will not help "identify & add" the CPE information - something that Dependency Check does. Dependency Track however expects us to provide the CPE. (correct me if I am wrong) I wonder if adding the support for dlls will help with the ultimate goal - which is finding the CPEs/CVEs for the same Dlls.

[stevespringett]

@tarakg Dependency-Check does not identify CPE's. It performs fuzzy matching against CPEs in hopes of a match. Each match has a confidence score. DC is centered around evidence-based analysis. It produces false positives and false matches by design.

In comparison, SBOMs are a statement of fact. There isn't a way to reliably look up a DLL and find its CPE as a centralized naming and alias lookup service does not exist. This is a known problem. We've solved the global namespace problem only once, DNS. Additionally, CPE is deprecated by NIST and will be replaced by SWID tags in the near future, where each vendor will be able to publish their own SWID tags to NIST. So it's more of a decentralized responsibility model rather than the centralized model that CPE uses with CNAs. If all vendors do their part and publish SWID tags, these can be used by the NVD directly to identify known vulnerabilities without having to guess.

One thing to note however is that the NVD only supports (currently) applications, operating systems, and hardware. They do not get granular down to the component level. So if an app ships with 50 DLLs specific to it, then the app would have a single SWID. You wouldn't necessarily know exactly which DLL was affected unless it was a shared library and had its own SWID tag.

[stevespringett]

The @CycloneDX/core-team will need to update the CycloneDX spec in order to support SWID. Currently the spec does not formally provide this capability although one could write a schema extension to support and use it today. Refer to https://github.com/CycloneDX/specification/issues/26

[tarakg]

@tarakg Dependency-Check does not identify CPE's. It performs fuzzy matching against CPEs in hopes of a match. Each match has a confidence score. DC is centered around evidence-based analysis. It produces false positives and false matches by design.

In comparison, SBOMs are a statement of fact. There isn't a way to reliably look up a DLL and find its CPE as a centralized naming and alias lookup service does not exist. This is a known problem. We've solved the global namespace problem only once, DNS. Additionally, CPE is deprecated by NIST and will be replaced by SWID tags in the near future, where each vendor will be able to publish their own SWID tags to NIST. So it's more of a decentralized responsibility model rather than the centralized model that CPE uses with CNAs. If all vendors do their part and publish SWID tags, these can be used by the NVD directly to identify known vulnerabilities without having to guess.

One thing to note however is that the NVD only supports (currently) applications, operating systems, and hardware. They do not get granular down to the component level. So if an app ships with 50 DLLs specific to it, then the app would have a single SWID. You wouldn't necessarily know exactly which DLL was affected unless it was a shared library and had its own SWID tag.

Thanks Steve for your detailed reply. The SWID change was a revelation. and I have two related questions:

• When SWID is adopted, how is NIST going to retroactively require all publishers to submit SWID for existing published CPE/CVEs? How will it impact existing solutions like yours which rely on CPEs? Will our BOMs with CPEs feed in DepTrack keep working/monitoring?
• When SWID comes out does that mean CPEs will be removed? Or both would be supported?

[stevespringett]

These are all questions for the NVD, however, I can tell you that they will have a lengthly migration period in which CPE and SWID will be supported for a few years simultaneously.

The NVD already has working REST endpoints that allow software producers to publish SWID tags to the NVD. I'm assuming it's private beta for now - but just guessing.

The existing methods of identifying vulnerabilities with CPE will continue to work during the long migration period. The NVD is fully aware that there are a lot of tools out there that rely on CPE. That will not change over night.

CycloneDX has already deprecated CPE. In v1.1 of the spec, CPE is deprecated, but can continue to be used. In v1.2 of the spec, SWID is being supported. So a CycloneDX BOM will be able to contain the few SWID fields necessary for vulnerability identification use cases. It can optionally support the entire SWID document as well. Once CycloneDX v1.2 is out (June timeframe), Dependency-Track will be updated to support it. So in the summer timeframe when the NVD announces all this, the CycloneDX + Dependendy-Track ecosystems will already be positioned to support it.

[tarakg]

@Steve Do you know if NIST has officially announced a summer 2020 timeframe? I checked https://csrc.nist.gov/Projects/Software-Identification-SWID/news . Didn't see anything new.

One more thing, do you have any plans for DepTrack to support RETIREJS datasource. Of late, I have seen at least two occasions (Angular and Jquery vuln) which got reported in RETIREJS, and DepTrack could not catch them.

[stevespringett]

NIST has not publicly committed to a timeframe yet. Last week at the NTIA meeting (it was public), Dave Waltermire stated 'sometime this summer' when referring to the messaging that NIST will provide around SWID, its benefits, and timeframe. So, all I know is that NIST will be communicating its plans publicly this summer and that those plans include CPE -> SWID migration.

If Retire.js is able to catch vulnerabilities that NPM Audit and OSS Index cannot find, then those should be reported to https://github.com/nodejs/security-wg and https://github.com/OSSIndex/vulns respectively. Once the vulnerabilities are included in NPM Audit and OSS Index, Dependency-Track will be able to identify those vulnerable components.

There are no plans to support Retire.js directly as its missing many of the fields necessary to make an accurate analysis.

[y4ppieflu]

Would like to also vote for this capability. We have a legacy solution, which has dependencies defined in a .vbproj file via the following syntax: <ItemGroup> <Reference Include="AjaxControlToolkit"> <HintPath>..\..\common\libs\AjaxControlToolkit\4.1.50731\AjaxControlToolkit.dll</HintPath> </Reference> ... </ItemGroup> cyclonedx-dontnet currently fails to identify any dependencies defined this way.

[asymmetricblue]

@coderpatros What do you think about swapping out the direct reading of the project file XML that exists today and instead taking a dependency on MSBuild and some Microsoft.Build packages that will handle reading/parsing the project file natively? This could make it easier to add support for direct assembly references as well as Project References. It may also simplify capturing other project file metadata that has been requested in other tickets and not captured yet.

The potential downside is that the system that this runs on will need MSBuild installed on it. Given that it is part of the .NET SDK, that might be a reasonable prerequisite. I'm not sure it would operate with only the runtime installed.

I can take a stab at it if you are agreeable.

[coderpatros]

@asymmetricblue that would be great. Tighter integration with the build engine is required for accuracy due to a few edge cases. So I'm very much in favour of that idea.

[asymmetricblue]

@coderpatros I'll give it a whirl. First obstacle, I'll need to feed MSBuild some more-complete project files than what the current test mocks are creating. Eventual second obstacle, I'll likely want some sort of assembly or assembly stand-in to pull information from.

Do you have a preference or suggestion for how I go about doing this? The obvious answer is to drop a directory into the repository with some test files to work with.

[neoKushan]

We're coming up against this issue ourselves. We have a legacy solution that pulls in all kinds of weird and wonderful dependencies directly, rather than via nuget. Luckily these dependencies don't change but I'd like my tooling to account for them anyway.

What's the current "best" way of adding this information to our SBOM's, given that CycloneDX doesn't support it? Should we just insert some static text manually, or is there a "nicer" way of pushing in dependency information that can't be automatically detected?

[mtsfoni]

What's the current "best" way of adding this information to our SBOM's, given that CycloneDX doesn't support it? Should we just insert some static text manually, or is there a "nicer" way of pushing in dependency information that can't be automatically detected?

You could create a second SBOM containing only your non-nuget dependencies and use CycloneDX CLI's merge function to merge it with the generated SBOM.

[github-actions[bot]]

This issue is stale because it has been open for 3 months with no activity.