Conda ecosystem support (basic) #4002
Conversation
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
Signed-off-by: Simeon Stoykov <simeon.stoykov@quantco.com>
9d13799 to
1a30969
Compare
|
Thank you, @SimeonStoykovQC! This already looks like a first sensible version that successfully produces found vulnerabilities in
This is probably the same as in every other ecosystem. Neither do they detect it. The plan for the cond ecosystem is to follow what PyPI/Python did with PEP770: Include SBOMs in packages that ship statically linked packages. For the PURLs: This will be addressed in the linked Conda Enhancement Proposal, and I know that @pavelzw is working on revamping this and getting it over the finish line. I guess this PR here should not be blocked by that, though. |
Description
This PR introduces basic support for sbom generation of packages in conda environments.
Status Quo
Up until now, syft had limited capabilities in conda environments and relied on language-specific catalogers (e.g. python and go). This meant that it wouldn't detect packages such as
zlib, even though the metadata needed is already accessible.Scope
The scope of this PR is to provide a minimum-effort conda support with the metadata that is already available, until the syft/grype and conda ecosystems decide on a more comprehensive approach (see #932 and conda/ceps#63).
The known shortcomings of this implementation are:
Implementation
The implementation partially addresses #932.
Each installed package in a conda environment produces a JSON metadata file inside the
conda-metadirectory. It provides a name and a version, among other things, and we use that to construct a package list.Type of change
Checklist: