patriksvensson / covenant Goto Github PK

Problem

I have a dependency on a component that does not have a SPDX License Id. For example the System.IO 4.3 package only have a license URL to the Microsoft .NET Library license, which does not fulfill the requirements to be included in the official SPDX License ID list.

Converting the SBOM to CycloneDX will only include the license URL which can not be used to identify the license in Dependency Track. Dependency Track relies on SPDX license ID for identification.

Current Behavior

• Converting to SPDX will generate a custom license ID that is unique only the SBOM file (and possibly undeterministic?)
• Converting to CycloneDX will generate only a license URL

Proposed Behavior

• Make it possible to map license url:s to custom license Id:s
• Make mapped license id:s part of CycloneDX conversion

This would solve the problem of identification in Dependency Track.

Stretch

• Add default mappings that can be enabled/disabled and overriden (this can be nice for common packages from Microsoft)
• Add support for the ScanCode License Database

I was looking for an alternative to https://github.com/microsoft/sbom-tool with CycloneDX support and came across this repo. Thanks for the tool! :-)

One suggestion though: The SBOM generation failed for me because I had no project.assets.json in one of my subprojects. As a result no SBOM was generated at all. My preference would be to see missing project.assets.json as an warning that does not prevent the generation of the SBOM.

and

What do you think?

Hi,

I tried running Covenant on a solution that contains F# projects and it successfully generated a report, but when I tried running it directly against an fsproj file I got

SBOM was not created since no components could be found

I had a go at making it recognize .fsproj project files in main...Numpsy:covenant:fsproj and it appeared to work, so - is that something you'd be interested in supporting?

Thanks

A component may consume 3rd party licensed elements at a more granular level than a package or library, it would be useful to be able to represent these smaller-scale dependencies in the generated SBOM.

For example, a given code file may re-use or derive its own implementation from another source. Whilst this use can be acknowledged via a comment in the affected code file and other higher level documentation, this doesn't offer a structured way to record the dependency and any licensing requirements attached to its use.

Approaches like the debian/copyright file provide a means of recording licensing requirements on a per-file basis.

Adding support to Covenant so it can understand such conventions would enable it to include the license details of these 'sub-library' dependencies.

The SPDX specification includes support for recording information at the file level which seems like it would cater for this type of scenario.

It should be possible to explicitly allow a component, regardless if it's not part of an "allow" SPDX license expression or if the component license has explicitly been banned.

Hi,

I had a go at running Covenant on a project that uses the 'UseArtifactsOutput' build option that was added in .NET 8 (which causes all the 'obj' directories to get put under a single 'artifacts' directory under the build root), and that failed as it couldn't find the project.assets.json file.

I haven't had much of a look at the issue, but I guess it might be down to
https://github.com/patriksvensson/covenant/blob/afaa6d6b83d00f9cbe8005f2091f521cb4a4dbfd/src/Covenant/Analysis/Dotnet/DotnetAnalyzer.cs#L223C38-L223C38
which looks for the assets file in a fixed location under the directory containing the project file.