PyPI and npm both publish signed provenance for many packages now, and PurlDB doesn't collect it yet. As far as I can tell nothing in purldb, scancode-toolkit, scancode.io or vulnerablecode reads it today.
What's available:
- PyPI (PEP 740). Per-file attestations from the Integrity API:
https://pypi.org/integrity/<project>/<version>/<filename>/provenance. For sigstore 4.5.0 it returns a publisher of kind: GitHub, repository: sigstore/sigstore-python, workflow: release.yml, plus a Sigstore bundle.
- npm.
dist.attestations in the registry metadata points to SLSA v1 provenance. For sigstore@5.0.0 that's https://registry.npmjs.org/-/npm/v1/attestations/sigstore@5.0.0.
Why it'd be useful here: the attestation says which repository and workflow actually built the artifact, and a Sigstore signature backs that up. PurlDB already stores vcs_url from package metadata, but that's whatever the publisher typed. Having both lets you compare them. A package whose declared vcs_url doesn't match the repository that built it is worth a flag. That seems relevant to the malicious-package tracking planned in aboutcode-org/vulnerablecode#2438, and to filtering by vcs_url (#903).
A rough first step, which I'm happy to do:
- In the PyPI collector, fetch the provenance for each distribution file when it exists, and store the publisher fields (kind, repository, workflow, environment) in
extra_data. No schema change.
- Verify the bundle with sigstore-python before storing anything, and record whether it verified. An unverified claim shouldn't look the same as a verified one.
- Tests with recorded fixtures, so nothing hits the network.
npm could follow the same pattern after that. If you'd rather have this in its own model or a separate pipeline instead of extra_data, tell me and I'll build it that way.
A bit about me: I've contributed to sigstore-python (#1846, merged), and I maintain a GitHub Action that attests code-review coverage with Sigstore. So verification is the part I'm most comfortable with.
PyPI and npm both publish signed provenance for many packages now, and PurlDB doesn't collect it yet. As far as I can tell nothing in purldb, scancode-toolkit, scancode.io or vulnerablecode reads it today.
What's available:
https://pypi.org/integrity/<project>/<version>/<filename>/provenance. Forsigstore4.5.0 it returns a publisher ofkind: GitHub,repository: sigstore/sigstore-python,workflow: release.yml, plus a Sigstore bundle.dist.attestationsin the registry metadata points to SLSA v1 provenance. Forsigstore@5.0.0that'shttps://registry.npmjs.org/-/npm/v1/attestations/sigstore@5.0.0.Why it'd be useful here: the attestation says which repository and workflow actually built the artifact, and a Sigstore signature backs that up. PurlDB already stores
vcs_urlfrom package metadata, but that's whatever the publisher typed. Having both lets you compare them. A package whose declaredvcs_urldoesn't match the repository that built it is worth a flag. That seems relevant to the malicious-package tracking planned in aboutcode-org/vulnerablecode#2438, and to filtering byvcs_url(#903).A rough first step, which I'm happy to do:
extra_data. No schema change.npm could follow the same pattern after that. If you'd rather have this in its own model or a separate pipeline instead of
extra_data, tell me and I'll build it that way.A bit about me: I've contributed to sigstore-python (#1846, merged), and I maintain a GitHub Action that attests code-review coverage with Sigstore. So verification is the part I'm most comfortable with.