Supply-Chain Assurance¶
How pyobfus's existing, shipped evidence maps to the current open standards an auditor or procurement reviewer is likely to ask about — SLSA v1.2, CycloneDX 1.7 (ECMA-424 2nd ed.), and PEP 740 attestations. This page does not add a mechanism; it names, in standard vocabulary, what the release pipeline and the build/provenance outputs already produce, and states the level honestly rather than over-claiming.
This is the reader-facing anchor of pyobfus's "verifiability" line. The three underlying documents remain the source of truth for each artifact: Verifiable build report, Provenance manifest, SARIF code scanning.
What pyobfus produces today¶
| Evidence | Where it comes from | What it establishes |
|---|---|---|
| PEP 740 attestations | GitHub Actions release workflow → PyPI Trusted Publishing (OIDC, no long-lived token) | The published wheel/sdist was built and published by pyobfus's GitHub identity; verifiable against PyPI's integrity API |
Verifiable build report (--build-report) |
Core, at build time | A versioned fact model of one build: selection, effective config, transform/cache counters, syntax-verification evidence, output SHA-256, artifact roles |
Provenance manifest (--provenance-manifest) |
Core, at build time | Supply-chain relationships for one run (input/output roots, config_hash, git commit, mapping digest) with an embedded CycloneDX section |
SARIF (--check --sarif) |
Core preflight | Code-scanning-format projection of findings, ingestible by GitHub code scanning |
| CodeQL | CI on every push | Static analysis of the codebase itself |
Mapping to SLSA v1.2 (Build track)¶
SLSA Build levels are cumulative (L1 ⊂ L2 ⊂ L3).
| SLSA level | Requirement (paraphrased) | pyobfus status |
|---|---|---|
| L1 | Provenance exists, describes how the artifact was built, and is distributed to consumers | Met — PEP 740 attestations are generated by the release workflow and published to PyPI alongside the artifact |
| L2 | Provenance is generated and signed by the build platform; consumers can verify its authenticity | Met — GitHub's OIDC identity signs the attestation (Sigstore-backed); anyone can verify it via PyPI's integrity endpoints or gh attestation verify |
| L3 | Hardened, tamper-resistant builds; provenance is unforgeable by the project | Partially satisfied, not formally claimed — the build runs on GitHub-hosted ephemeral runners and the attestation is minted by the hosted builder (not the project), which covers the key isolation/unforgeability properties. pyobfus does not assert a certified L3. |
Honest boundary: these levels describe build/publish integrity of the pyobfus package. They say nothing about the security of the code a user obfuscates, and obfuscation is not encryption — see the threat model.
Mapping to CycloneDX 1.7 / ECMA-424¶
CycloneDX 1.7 (published Oct 2025, ratified as ECMA-424 2nd ed. Dec 2025) is the last release of the 1.x line and stays backward compatible with 1.4–1.6.
- The provenance manifest's embedded CycloneDX section now declares
specVersion: "1.7". The emitted field subset is valid under both 1.6 and 1.7;--verify-provenance-manifestaccepts either, so manifests written by older releases remain valid. - pyobfus deliberately does not yet use 1.7's new optional structures (Data Provenance & Citations, TLP distribution constraints, CBOM). TLP is a sharing label, not access control, and the citation blocks are not needed for a single-run manifest. Declaring 1.7 is an honesty upgrade, not a feature claim. See Provenance manifest.
The build report's outputs[].sha256 gives the component-level digest an SBOM
consumer expects; cross-file output is deterministic for the same input and
config (fixed in 0.5.25), so a third party can rebuild and confirm the digest.
Mapping to PEP 740¶
PEP 740 attestations are published to PyPI by the OIDC release workflow. Verify a released version without trusting this page:
# The attestation lives on PyPI's integrity endpoint, not the plain JSON API.
curl -s https://pypi.org/integrity/pyobfus/<version>/<filename>/provenance | jq .
(The plain pypi.org/pypi/pyobfus/json API reports provenance as null; use the
/integrity/ endpoint.)
What this covers in OSPS terms¶
This page is the "verify integrity and authenticity of releases" documentation (OSPS-DO-03.01/03.02) and the SBOM-direction record (OSPS-QA-02.02), tying them to the same evidence rather than duplicating it.
Deliberately out of scope¶
- A certified SLSA L3 claim (see the L3 row above).
- Using CycloneDX 1.7's TLP/citation/CBOM blocks (not needed yet).
- Any assertion about the runtime security of obfuscated user code.