[ANE-1377] SBOM upload

[spatten]

Overview

Delivers ANE-1377

This PR adds a new command, fossa sbom, with two subcommands, fossa sbom analyze and fossa sbom test.

fossa sbom analyze takes a path to an SBOM file and uploads it to Core to be scanned.

fossa sbom test does the equivalent of fossa test, but for the resulting SBOM project.

Links to docs: https://github.com/fossas/fossa-cli/blob/4b7d2c7feba18623a0ed652c8e7fd504d91b5c3d/docs/references/subcommands/sbom.md

Acceptance criteria

• You should be able to upload an SBOM from the CLI. This can be a CycloneDX or a SPDX SBOM.
• If you do not set the project name, then the project name will be the name of the SBOM file, but with .json or .xml extensions stripped off
• If you do not set the revision, then we set the revision to a timestamp for the current time. This timestamp will be used the next time you run fossa sbom test.
• You should be able to associate a single team with the project
• If you re-upload with the same project name, a new revision will be added to the existing project
• The CLI should print out a link to the project after it is created

Testing plan

Grab an SBOM by downloading a sample one. You can get one from this blog post.

Run fossa sbom analyze with the file you just downloaded. There are no changes required to Core, so you can just hit prod.

make install-dev
fossa-dev sbom analyze ~/Downloads/sampleCycloneDX.json

You should see a resulting report on Core:

============================================================

    View FOSSA Report:
    https://app.fossa.com/projects/sbom%2b24987%2fsampleCycloneDX/refs/branch/master/2024-05-29T22:30:13Z

============================================================

Click through and verify that this project exists and looks correct. It should have a bunch of issues.

Now run fossa sbom test:

fossa sbom test

It should show you the errors. It should also grab the timestamp that was cached in the file system when you ran fossa sbom analyze.

Do this again with a few variations. Try the --project, --revision, --team and --force-rescan flags.

Test that fossa test with a revision that falls back to a timestamp still works.

cd ~/some/project
fossa-dev analyze
============================================================

    View FOSSA Report:
    https://app.fossa.com/projects/custom%2b24987%2fvendored-dependencies/refs/branch/master/2024-05-29T22:52:26Z

============================================================

fossa-dev test
Unable to infer project revision from VCS, using current timestamp as the revision.

Using project name: `vendored-dependencies`
Using revision: `2024-05-29T22:52:26Z`

Test passed! 0 issues found

Risks

I think the only changes that are risky here are the changes that affect fossa test. As long as these changes do not break fossa test, this is low risk.

I've tested these in the test plan, and the changes are pretty strongly type checked, so I think we should be okay.

Metrics

I added telemetry to track usage of fossa sbom analyze.

References

ANE-1377

Checklist

• [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.md 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.
• [ ] 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.