Python CBOM example: pyca/cryptography

CRYPTAGION · Technical evidence note · 10 October 2026

Cryptagion scanned 243 Python files at a pinned pyca/cryptography revision and exported a CycloneDX 1.6 cryptographic bill of materials (CBOM). The scan returned 1,804 raw detections: 46 in library source, 1,746 in tests, and 12 in documentation scripts. Two runs in the same environment produced matching normalized findings and scores.

This demonstration shows how source evidence becomes an inventory. Detections include imports, algorithm constructors, lookup tables, and capability checks. They are not a count of vulnerabilities, deployed keys, or unique cryptographic systems.

What was scanned?

The target was pyca/cryptography at commit d45b7930f93c, using Cryptagion scanner commit 4c9ee2e47abd. Python files were parsed statically; target code was not executed. Tests and documentation scripts were retained to make scope differences visible.

All 243 tracked .py files were scanned with no reported skips or failures. The repository also contains 109 Rust files and 33 Python stub files (.pyi) outside this scan. Other languages, embedded CFFI definitions, certificates, live TLS, cloud services, dependencies, and deployed application usage were not assessed. A complete Python scan does not mean complete repository or algorithm coverage.

How was the CBOM generated and checked?

We used an isolated inventory database and the normal Cryptagion CLI. The demonstration policy labels the public source as public and assumes zero years of data confidentiality. Those settings describe this demonstration; they do not describe applications that depend on the library.

The scan, automated scoring output, and CBOM export came from the same inventory. Validation checked the export against the official CycloneDX 1.6 JSON schema, joined every component to its detection and score, and checked that each of the 1,804 evidence locations exists in the pinned source. The CBOM records the target commit and repository-relative evidence paths.

A second run repeated the procedure. Comparison ignored generated UUIDs and detection/assessment timestamps, then compared the substantive finding and scoring fields. These matched. This is repeatability on one machine, not independent third-party reproduction or a precision/recall benchmark. The CBOM does not include a complete dependency graph.

Why source context matters

We inspected all 46 library-source detections and recorded their interpretation in the library review ledger.

• SHA-1 can identify a key. A detection in the X.509 key-identifier helper identifies a SHA-1 call. It does not establish a security failure; the use and surrounding protocol matter.
• Recognition is different from execution. Hash constructors in the signature OID lookup support algorithm identification. They do not prove that a deployed service signs data with each listed hash.
• A capability check needs type context. The scanner labels a generic CBC capability check as AES. That line alone does not establish which algorithm the caller supplies. The review ledger marks this limitation.
• Unsupported implementation languages create blind spots. The Python Fernet wrapper delegates to Rust. Its underlying implementation is outside this Python-only scan.

Review also found a test call, DSA key generation, mislabeled as Diffie–Hellman by this scanner revision. The raw export preserves that result so the record remains auditable. Family labels across the full export have not all been independently verified. Automated risk scores and replacement suggestions are research outputs requiring review, not recommendations to change pyca/cryptography.

What does this tell a security team?

An inventory becomes useful when each record has a source location, a defined scope, and an interpretation. The next step for a deployed application is to connect relevant cryptographic usage to its owner, protocol, data, dependencies, and operating environment before deciding on migration priorities.

This case study establishes traceable Python discovery and schema-valid CBOM export for one repository revision. It does not establish a complete asset inventory, customer risk reduction, migration effort, or security certification. This is an independent Cryptagion demonstration; pyca/cryptography is not presented as a customer, partner, or endorser.

Reproduce the demonstration

Download the evidence bundle, raw CBOM, and validation results. The bundle includes the pinned runbook, manifests, commands, raw scan/scoring outputs, review ledger, validator, and hashes. Cryptagion scanner access is required to rerun; the scanner repository is currently private. Anyone can inspect the published evidence against the public target source.

To reproduce, obtain the pinned scanner revision, check out the pinned target revision, install the scanner's locked environment, and run reproduce_pyca.py with separate scanner, target, and output paths. Repeat with a fresh output directory, then use the validator as described in the runbook. Do not execute source from the target repository for this inventory demonstration.

Questions this demonstration answers

Can a CBOM be generated from Python source? Yes. This run exported a schema-valid CycloneDX 1.6 CBOM with source evidence for the detected records. Supported patterns and languages determine what is found.

Does a cryptographic detection mean a vulnerability? No. Imports, supported algorithm tables, test vectors, and real operations have different meanings. A source inventory needs context and review.

Did this demonstration cover Rust? No. The 109 tracked Rust files were outside this scanner's supported analysis scope.

Does the scan measure production quantum exposure? No. It inventories public repository source. Deployment, data lifetime, and business impact were not established.

Explore cryptographic inventory

Read what a CBOM contains, explore cryptographic inventory, or review Cryptagion's CBOM generator. To assess your own application, request a representative assessment.