Ignore "withdrawn" vulnerability reports from PyPI's vulnerability service

[woodruffw]

Similar to #385, but for the default (PyPI) vulnerability service: we should handle vulnerability reports that are marked as "withdrawn" by ignoring them.

This is going to require a little more investigation/thought, since PyPI's JSON API doesn't expose the full OSV-style schema. Instead, it has a subset:

class VulnerabilityRecord(db.Model):

    __tablename__ = "vulnerabilities"

    source = Column(String, primary_key=True)
    id = Column(String, primary_key=True)

    # The URL for the vulnerability report at the source
    # e.g. "https://osv.dev/vulnerability/PYSEC-2021-314"
    link = Column(String)

    # Alternative IDs for this vulnerability
    # e.g. "CVE-2021-12345"
    aliases = Column(ARRAY(String))

    # Details about the vulnerability
    details = Column(String)

    # A short, plaintext summary of the vulnerability
    summary = Column(String)

    # Events of introduced/fixed versions
    fixed_in = Column(ARRAY(String))

    releases = orm.relationship(
        "Release",
        back_populates="vulnerabilities",
        secondary=lambda: release_vulnerabilities,
        passive_deletes=True,
    )

So, this may be a Warehouse-side change rather than a pip-audit one: Warehouse may need to occasionally prune entries from the vulnerabilities table, depending on whether they're been withdrawn from OSV. Alternatively, Warehouse could naively mirror with withdrawn field from OSV, and leave it up to the client to handle it appropriately. In the latter case Warehouse changes would still be required, but they'd be much smaller (similar to what we did in pypi/warehouse#11858).

[jenstroeger]

@woodruffw is it possible to guesstimate when this change (including Warehouse/PyPI server side) comes online? I’ve got a bunch of breaking workflows and I have two options:

• wait for that “CVE” to be withdrawn and status mirrors and tools catch up to that new status; or
• temporarily disable pip-audit for all our workflows to unblock them.

Either way, we’ll refactor our workflows as well such that future audit failures don’t break CI anymore and instead just issue a warning.

I guess I was a bit too optimistic with my assumption that a CVE either has already received a fix or will receive one quickly.

[woodruffw]

My best guess is that I'll have time to address this issue and make a new release later this week. However, as you pointed out, this will not fix the underlying issue, which is a data quality issue that I ultimately don't control. Unfortunately, I have no sense of how long MITRE's CNA will take to respond, or if they'll even bother to.

In the mean time, you actually have a third option: you can use the --ignore-vuln ID option for raw pip-audit invocations, or the ignore-vulns setting in GitHub Actions.

For example, here's how I'm currently ignoring the bogus pytest CVE in one of my repositories:

      - name: Run pip-audit
        uses: trailofbits/[email protected]
        with:
          virtual-environment: env/
          ignore-vulns: |
            GHSA-w596-4wvx-j9j6

With that, you'll be able to continue running your workflows while ignoring the current bad report.

[di]

(As much as I don't want folks ignoring CVEs, that example/explanation is good and should probably land in our docs!)

[woodruffw]

(As much as I don't want folks ignoring CVEs, that example/explanation is good and should probably land in our docs!)

Yep, completely agreed. I can open a PR for that in a moment.

[woodruffw]

#389 has the doc updates.

[woodruffw]

pypi/warehouse#12443 should be all we need: with that, PyPI will prune vulnerability reports on its own.

pypi/warehouse#12443 will add the withdrawn field to PyPI's API responses, which will allow us to do the appropriate filtering here.

[woodruffw]

#393 adds the code that supports pypi/warehouse#12443.

[woodruffw]

Closing since all of the code on the pip-audit side is merged; we just need the upstream PyPI changes for them to become effective.