Dockerfile support

[klautcomputing]

Would be great if licensed supported analyzing Dockerfiles and what is installed there to track all dependencies of a project!

[jonabc]

@klautcomputing this is a great topic and I'd love to support this but I'll also say that it's a hard problem to solve.

Licensed works on what is actively available on a system and requires that dependencies be installed. Dockerfile RUN commands can have hidden side effects and the only way to be sure of the state of a system is to evaluate a docker container that's run from the image built from the Dockerfile.

So, then there are a few more problems:

• how to enumerate dependencies from package managers on different base OS's?
• how to gather information from dependencies installed manually, outside of a package manager?

That's not to say that any of this is not solvable, just that it's not the easiest thing to enumerate system level dependencies 😄 . If you have ideas on how to accomplish this I'd absolutely welcome additional feedback or even a PR 🙏

[ericcornelissen]

What about using a Software Bill Of Materials (SBOM) of the Docker image¹ as a source for license information? For example, I know Syft's own SBOM format includes the name of the license of all artifacts it detects (haven't checked SPDX's or CycloneDX's SBOM formats).

I suppose the fact that Syft is able to determine the license of system dependencies in a Docker image implies that it's possible to do this manually as well. I guess, however, that it would be easier to let Syft (or another tool) do the heavy lifting and consult the SBOM it generates to contain the license information.

Two potential complications with this approach is that SBOMs typically also contain information about artifacts that Licensed already supports (e.g. npm modules or Ruby gems). So these should either be filtered out or somehow consolidated with Licensed own analysis.

Footnotes

1. Or really an SBOM of any project for that matter. I.e., the source could be "SBOM" instead of "Docker". ↩

[jonabc]

@ericcornelissen I'm curious of the use case for licensed here - what is the added benefit of licensed on top of Syft or another tool like it? Why not use the output from that tool directly?

[ericcornelissen]

@jonabc that's a fair question. I think the primary benefit is the "compliance" aspect of Licensed. As far as I know Syft doesn't support this, and I don't know of any tool that does for SBOMs (admittedly, in all likelihood such a tool already exist).

Additionally, Licensed's output is much more extensive for the ecosystems it supports, and so may be preferable to Syft's output in many regards. Admittedly, this won't hold true for system-level dependencies, but I think it means there's value in using both Licensed and (something like) Syft for a single project.

If nothing else, the implementation of Syft and tools like it may provide a starting point for Licensed to add Dockerfile support.

[jonabc]

@ericcornelissen ah good point, I'll check out Syft's output format and see if it's a good match. FWIW I'm a little concerned about confusion where there is overlap between Licensed and Syft. For example they both have ruby and go support, which will require guidance and specific configuration to avoid double reporting for those types of dependencies.

Also, is not having licensed able to check compliance on docker images a blocking issue for you? Just trying to figure out the priority here - it doesn't seem to be as needed as the other recent changes you requested but let me know if that's incorrect 🙏

[ericcornelissen]

FWIW I'm a little concerned about confusion where there is overlap between Licensed and Syft. For example they both have ruby and go support, which will require guidance and specific configuration to avoid double reporting for those types of dependencies.

My (perhaps naïve) suggestion would be to simply ignore anything in the SBOM that's for an ecosystem already supported by Licensed. I know Syft's own custom format includes information on the ecosystem, don't know about the SPDX and CycloneDX formats though.

Also, is not having licensed able to check compliance on docker images a blocking issue for you? Just trying to figure out the priority here - it doesn't seem to be as needed as the other recent changes you requested but let me know if that's incorrect 🙏

Not a priority/blocking issue for me - I just noticed this issue and wanted to share a suggestion 🙂