[CDRIVER-5535] Add a vulnerability report artifact to the release archive

[vector-of-bool]

At long last, this final changeset should complete the work for CDRIVER-5535. It builds upon the previous PRs that introduced additional processes, scripts, and documentation, and defines the final 3rd party vulnerabilities report that is included as a release artifact.

Summary

The process defined here expands upon the approaches from those taken in libmongocrypt and the C++ driver. It more explicitly defines the content of third_party_vulnerabilities.md and what and when items should be added or removed.

Considerations

Why not use Snyk monitor and rely on the augmented SBOM?

snyk monitor takes a snapshot of the working directory and posts it to Snyk, where Snyk effectively runs snyk test repeatedly on a schedule, with the test results posted to the Snyk target/project that corresponds to the snapshot. This allows for notifications when new vulnerabilities are issued on past snapshots of the repository.

The overall intended design was that Snyk would detect vulnerabilities, Silk would collect them together, and then Silk would filter the dependencies based on the content of the SBOM lite (i.e. to remove false-positives). The resulting filtered vulnerabilities from Snyk would be inserted into the augmented SBOM. The augmented SBOM would then be the primary release artifact for vulnerability reporting.

For creation of the vulnerability report, the following points were considered when deciding not to rely on the augmented SBOM:

1. A Silk asset group must be created and correlated with a snyk monitor snapshot, and must correspond to a branch in the upstream repository. The association between a Snyk monitor and an asset group requires that snapshots be specifically tied to branches rather than release versions. We want to snapshot a release at the exact point it was taken, and not rely on the Snyk target reference name coinciding with an asset group branch name. We want to monitor past releases, and not just the tip of the release branch.
2. The augmented SBOM is updated asynchronously. It is unknown how soon after creating the Silk asset group and the Snyk snapshot the augmented SBOM will actually contain data (it can take up to 24 hours). In contrast, the vulnerability data from Snyk is immediately live and valid the moment it is requested.
3. This repository contains four dependencies, only one of which is actually tracked in the Snyk database (Zlib). This makes the prospective value-add of Silk's vulnerability collection and filtering very very small.
4. Along with the previous point: At present, there is only one vulnerability currently found against the Snyk database. Manually reviewing the vulnerability report for false-positives is a trivial task.

Does this make the SBOM pointless?

No. The SBOM still gives us structured data to represent our dependencies, including those that are not known to Snyk.

Does this make the augmented SBOM pointless?

Maybe?

If snyk monitor is not executed to create a snapshot for the repository, then Silk will never accrue vulnerabilities to be added to the augmented SBOM.

IMO, we can do better with a semi-manual process that is enhanced by Snyk's automation.

What about false-positives from Snyk?

When Snyk reports vulnerabilities and/or dependencies in the repository that are/would not actually be present in the release, it is plainly visible that something is amiss. We only have one (true positive) vulnerability at the moment, so this appears to be a non-issue. The problem can be revisited in the future if false positives become a common occurrence.

What about false-negatives from Snyk?

If there are actual dependencies and/or vulnerabilities that are missed by Snyk, then they would never have appeared in the augmented SBOM anyway. Currently, jsonsl, uthash, and utf8proc are not detected by Snyk, despite being present in the repository. It appears that these libraries are not tracked by Snyk in their package database, so adding them is beyond the reach of just fiddling with the snyk CLI.

The correction of false-negatives has been ruled out as out-of-scope for the overall project.

What about the MUST/SHOULD requirements from the linked ticket?

The following emphasized clause conflicts with these changes:

Drivers with bundled dependencies MUST integrate with a supported tool (e.g. Snyk) that can perform vulnerability scanning and feed results into Silk for SBOM generation. If Snyk is used, drivers SHOULD NOT rely on it to infer dependencies, as it is prone to false-positives and version inaccuracies.

Over the past few weeks, issues have arisen as the implementation of Silk+Snyk was explored within the C driver that would make the process overly cumbersome and error-prone. Following discussion with various teams that are deploying these tools, the processes that are outlined in this changeset are intended to meet the intent of the above requirements without necessarily matching the wording. Manually removing false-positives has been determined to be trivial for this repository.

What About Automatic Jira Reporting via Silk?

One of the stated goals of using Silk is to support the automatic creation of Jira issues corresponding to vulnerabilities that appear in monitored dependencies. This integration is not currently working, and our dependency set is currently so small that we can get away with doing it all "by hand" for now.

[vector-of-bool]

Note: These changes are paused pending resolution of some ambiguity in the third-party vuln reporting requirements.

[vector-of-bool]

One of the checklist items for conformance is:

Vulnerabilities for third party libraries are monitored on all non-EOL versions.

I have added additional process and automation to address this goal. This is separate (but related) to the requirement for the vulnerability report itself.

[vector-of-bool]

I have added and removed content significantly since the initial changeset. The new changes are based on ongoing conversations with team members about the stated goals of vulnerability tracking and what options we actually have available to us.

[eramongodb]

Minor feedback; otherwise, LGTM.