Fast, portable and reliable dependency analysis for any codebase. Supports license & vulnerability scanning for large monoliths. Language-agnostic; integrates with 20+ build systems.
Right now, if the CLI tries to do a container scan with no OS or OS Release information set, it will fail. This PR changes so that the CLI can still return results for things that aren't system deps inside of distroless containers, e.g. Jars and any of our static programming language analyses.
System deps will still not be supported because we don't have a way to recognize distribution package locators that don't have the OS or OS release information. The team has some ideas of how to address that, but isn't really feasible to fix in the short-term, where this provides some value and paves the way for that later work.
Acceptance criteria
Containers with no linux distro information can be scanned and partial results uploaded.
Testing plan
Please see this related PR for information on reproducing.
Risks
There is potentially an explainability problem for customers - why does FOSSA find my npm/pip/etc. dependencies but not system deps?. I think this is still better than the current status quo though which is "Why doesn't FOSSA find any deps at all?"
Metrics
References
Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.
[x] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
[x] If this PR introduced a user-visible change, I added documentation into docs/.
[x] If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
[x] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
[x] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
[x] If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.
Overview
Right now, if the CLI tries to do a container scan with no OS or OS Release information set, it will fail. This PR changes so that the CLI can still return results for things that aren't system deps inside of distroless containers, e.g. Jars and any of our static programming language analyses.
System deps will still not be supported because we don't have a way to recognize distribution package locators that don't have the OS or OS release information. The team has some ideas of how to address that, but isn't really feasible to fix in the short-term, where this provides some value and paves the way for that later work.
Acceptance criteria
Containers with no linux distro information can be scanned and partial results uploaded.
Testing plan
Please see this related PR for information on reproducing.
Risks
There is potentially an explainability problem for customers - why does FOSSA find my npm/pip/etc. dependencies but not system deps?. I think this is still better than the current status quo though which is "Why doesn't FOSSA find any deps at all?"
Metrics
References
Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.
Example:
Checklist
docs/.docs/README.msand gave consideration to how discoverable or not my documentation is.Changelog.md. If this PR did not mark a release, I added my changes into an# Unreleasedsection at the top..fossa.ymlorfossa-deps.{json.yml}, I updateddocs/references/files/*.schema.jsonAND I have updated example files used byfossa initcommand. You may also need to update these if you have added/removed new dependency type (e.g.pip) or analysis target type (e.g.poetry).docs/references/subcommands/<subcommand>.md.