Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align on an output format for detected dependencies #42

Open
sschuberth opened this issue Jan 17, 2022 · 8 comments
Open

Align on an output format for detected dependencies #42

sschuberth opened this issue Jan 17, 2022 · 8 comments
Labels
status:ready Ready to start implementation type:feature Feature (new functionality)

Comments

@sschuberth
Copy link

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
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Member

JamieMagee commented Jan 25, 2022

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
Copy link
Author

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 😉

@JamieMagee JamieMagee added status:ready Ready to start implementation type:feature Feature (new functionality) labels Jan 28, 2022
@JamieMagee
Copy link
Member

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
Copy link

coderpatros commented Jan 29, 2022

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:ready Ready to start implementation type:feature Feature (new functionality)
Projects
None yet
Development

No branches or pull requests

5 participants