microsoft / component-detection

Scans your project to determine what components you use
MIT License
436 stars 90 forks source link

Align on an output format for detected dependencies #42

Open sschuberth opened 2 years ago

sschuberth commented 2 years ago

I realized this tool is currently using its own JSON format for reporting dependencies, but I wonder whether instead it would make more sense to write out standardized formats like SPDX or CycloneDX, or at least try to align with existing formats of similar tools like the ORT Analyzer. (Disclaimer: I'm the founder of ORT.)

brphelps commented 2 years ago

Supporting multiple formats could make sense for something like this -- maximizing human usability in the default format doesn't seem like a bad thing.

sschuberth commented 2 years ago

maximizing human usability in the default format doesn't seem like a bad thing.

Agreed. Though I'd argue there are better formats for human usability than JSON 😉

coderpatros commented 2 years ago

I did raise #22 for this. Although the title indicates CycloneDX output format, it can leverage the CycloneDX/SPDX interop library to also be able to support SPDX output.

JamieMagee commented 2 years ago

I've added this as a topic for our first community meeting. See #49.

The TL;DR is: another team at Microsoft is building an SBOM generation tool, taking a dependency on Component Detection to get dependency info. They plan to open source it "soon". Duplication of work wouldn't be great, but maximising the utility of Component Detection for other users outside of Microsoft would be great!

sschuberth commented 2 years ago

another team at Microsoft is building an SBOM generation tool, taking a dependency on Component Detection to get dependency info. They plan to open source it "soon".

Ah, I read about that tool over here, and I actually though this project is the tool that Microsoft announced over there. Thanks for the clarification that it's yet another tool!

Duplication of work wouldn't be great, but maximising the utility of Component Detection for other users outside of Microsoft would be great!

Speaking of duplication of work... the ORT community certainly would have appreciated contributions to its analyzer tool (esp. regarding NuGet support, as we're not .NET people) instead of creating yet another tool with a very similar purpose :wink:

JamieMagee commented 2 years ago

We discussed this topic in our community meeting on Wednesday 26th January and we've decided to go ahead with adding support for SPDX and CycloneDX support. I don't know when exactly, but it's on our backlog now.

coderpatros commented 2 years ago

That's great news @JamieMagee

I've poked around in the code base a bit. I think an appropriate approach would be adding a "ManifestFileFormat" option. Default would be the existing format, with options for CycloneDX and SPDX JSON formats.

Then add handling for it in the BcdeScanCommandService.WriteComponentManifest(detectionArguments, scanResult) method.

The CycloneDX project already has a library that will convert from CycloneDX to SPDX format. So the only extra bit would be adding a method to convert the internal format to CycloneDX. Perhaps an OutputFormatService?

Does that sound like a reasonable approach to you?

JuergenGutsch commented 9 months ago

Hi, Is there any news on that? The PR is there but not yet merged: https://github.com/microsoft/component-detection/pull/115 We want to use https://dependencytrack.org which only supports CycloneDX formatted SBOM. Thanks, Juergen