Manual lists of CVEs to include and exclude

[KeplerBoyce]

Closes #775.

Adds data/cve_include.json and data/cve_exclude.json which can be used to manually add CVEs for any package releases or ignore CVEs that the osv.dev API returns. Here are what the json formats would look like, using the grafana package as an example (should we include examples like this somewhere to show how to make changes to these two files?)

In data/cve_exclude.json:

{
    "grafana": [
        {
            "id": "CVE-2018-15727",
            "releases": [
                "grafana (Build 2266) - (STABLE)",
                "grafana (Build 2267) - (STABLE)"
            ]
        }
    ]
}

In data/cve_include.json:

{
    "grafana": [
        {
            "id": "CVE-2018-15727",
            "details": "Grafana 2.x, 3.x, and 4.x before 4.6.4 and 5.x before 5.2.3 allows authentication bypass because an attacker can generate a valid \"remember me\" cookie knowing only a username of an LDAP or OAuth user.",
            "severity": "CRITICAL",
            "affected_releases": [
                "grafana (Build 2266) - (STABLE)"
            ]
        }
    ]
}

I also switched the bin/zopen-audit script from using commit hashes to find CVEs to using release timestamps. For example, if we manually add a vulnerability for one release of a package that has the same commit hash as another release of that package, then using release timestamps instead of commit hashes ensures that the audit script is checking for CVEs under the correct release in docs/api/zopen_vulnerability.json.

[IgorTodorovskiIBM]

Excellent! A couple of comments:

Can data/cve_include.json use the community commit sha rather than or in addition to affected_releases This way we dont need to update data/cve_include.json every time we do a rebuild of the port project.

Are you able to remove zopen_releases.json and zopen_releases_latest.json from the PR? We update that automatically so it will quickly become outdated, causing the current set of conflicts.

[KeplerBoyce]

Hmm, do you think it would work to use the package version rather than community commitsha? I was thinking that the version might be easier and also allow for adding CVEs for package releases that were built from tarballs (especially since these are the packages where we don't get CVEs from the osv.dev database). Even once all packages are migrated to git repos, there will still be the old releases without community commitsha, right?

Also, I guess there is never any circumstance where we would want to add a CVE to one specific release of a package? The original reason I chose the release name was so we can target specific releases that use the same package version as other releases, but on second thought that probably isn't necessary since the releases should have the same CVEs if they use the same package version.

I'll remove the releases json files from the PR along with these other changes.

[IgorTodorovskiIBM]

Hmm, do you think it would work to use the package version rather than community commitsha? I was thinking that the version might be easier and also allow for adding CVEs for package releases that were built from tarballs (especially since these are the packages where we don't get CVEs from the osv.dev database). Even once all packages are migrated to git repos, there will still be the old releases without community commitsha, right?

Also, I guess there is never any circumstance where we would want to add a CVE to one specific release of a package? The original reason I chose the release name was so we can target specific releases that use the same package version as other releases, but on second thought that probably isn't necessary since the releases should have the same CVEs if they use the same package version.

I'll remove the releases json files from the PR along with these other changes.

That's a good idea. Let's go with that