Most teams know they use cryptography. Very few know exactly where, why, and how much of it will become a post-quantum problem. Theory is important in cybersecurity, but it is the projects that help you transform knowledge into actual skill. Projects can be much more effective in terms of learning than simply reading about things. This is because doing a project helps you think like an analyst, engineer, and defender simultaneously. This means you will stop wondering things like "what is TLS?" and "what is RSA?" and start wondering more useful things like "where in this application is cryptography actually used?" and "what are the vulnerable points?" This is precisely the kind of thinking that a cybersecurity team should have in a real-world environment, and this is precisely the kind of thinking that QuantumLedger-CBOM has. According to the repository, it is a Flask-based scanner for CBOM that can be used to scan for crypto-related components and to report them.
What Is a CBOM?
Before going into an explanation of the project itself, it is necessary to first describe what exactly is meant by the term 'CBOM'. In this repository, it is described as "a practical list of cryptographic-related findings within an application or surrounding infrastructure such as TLS endpoints, certificates, SSH keys, JWT signing, database transport encryption, backup encryption, crypto libraries, and infrastructure context." The project also goes on to describe an important distinction: "Note that this is not an SBOM; it is not an enumeration of packages in general. This is an application-specific crypto inventory intended to identify what is dependent on public-key crypto versus symmetric crypto, an important consideration in post-quantum planning in cybersecurity."
Why CBOM Matters in Cybersecurity ?
This is why I think such projects are important in the cyber world. Security is not only about identifying vulnerabilities or running tools, but also about creating visibility. If an organization is unaware of the usage of cryptography, they will not be able to evaluate the risks or prepare for the attacks of the future, such as quantum attacks on RSA or ECC. A project such as QuantumLedger-CBOM is important because it takes the ad hoc usage of cryptography and presents it in an organized manner, which can actually be used for analysis and enhancement. The description provided on the DeepWiki page for the tool explains how the tool is targeted towards the specific area of "quantum exposure" and how it makes the distinction between public key cryptography, which is vulnerable to Shor's algorithm, and symmetric cryptography, which is not.
Building QuantumLedger-CBOM
Another aspect of the code that I'd like to be more open about is the way I constructed this code. One piece of the process was definitely a bit AI-assisted in terms of its vibe-coding style. However, the key point to understand is that the code was not simply "automatically generated." The actual effort was in designing the code, deciding what to scan, and defining what constitutes a useful output in a CBOM and making sure that output was meaningful for security analysis and not just slick code. The code also reflects that this is a structured codebase that has defined scan modes, analyzers, and exports with optional AI features layered on top of deterministic scanning.
The QuantumLedger-CBOM codebase is a Flask-based web application security scanner. According to the codebase, it can scan repositories, ZIP archives, and Git URLs. It can also accept manual analyst input for external crypto contexts like TLS, SSH, database, KMS/HSM, and third-party services. This is important because cryptography in real-world applications isn't always entirely visible in the source code. It can also be in the configuration files, infrastructure code, and operational context outside the codebase.
This is important because in real-world applications, cryptographic code doesn't always exist in isolation within the codebase. Some of it is in configuration files, some of it is in infrastructure, some of it is in operational decisions outside of the code repository.
How the Architecture Is Structured ?
One of the parts I care most about in this project is that it was not built as a single script. QuantumLedger-CBOM is structured more like a small security platform. At a high level, the architecture is split into a Flask-based web application layer, a scanning pipeline, a CBOM and migration-planning layer, and an optional AI integration layer. DeepWiki describes the web layer as using an application-factory pattern and blueprints, while the service layer connects the routes to the scanning engine and persists results under the scan workspace.
Inside the scanning pipeline, the flow is organized around dedicated components rather than one generic parser. RepoLoader prepares the workspace for each scan, FileDiscovery walks the target and categorizes relevant files, and specialized analyzers inspect certificates, TLS, SSH, database crypto, dependencies, and crypto usage in source code. After that, the CBOMBuilder deduplicates findings and assigns IDs such as CBOM-0001, while the MigrationPlanner groups the results into a three-tier roadmap.
That structure matters because cryptography in real applications is scattered across multiple layers. It is not only in source code. It can appear in certificates, config files, deployment manifests, proxy settings, database connection parameters, and infrastructure notes. Designing the project in modular layers made it easier to model that reality instead of pretending that crypto visibility can come from a single regex pass over source files.
How the Workflow Works ?
The workflow begins from the web interface. The documents for the repository describe the flow as follows: open the home page, start a new scan, select either Manual Input mode or Auto Scan mode, submit the scan inputs, and wait for the synchronous scan to complete. After that, the user can proceed to the Findings Dashboard to view the results. From there, the user can proceed to the CBOM Viewer, the Migration Plan, the HTML Report, or the Exports.
The tool supports more than one type of input, as real-world security reviews are rarely just about code. In Auto Scan mode, the tool can accept a local repository path, a Git URL, or a ZIP archive. In Manual Input mode, the tool can accept analyst-provided context like primary domains, additional TLS endpoints, SSH information, database encryption information, KMS/HSM information, external configuration references, and custom crypto notes. If both manual context and repository source are provided, the tool can merge them into a single CBOM.
Internally, the tool will create a scan workspace, process the source, perform file discovery and analysis, normalize the results, build the CBOM, create the migration plan, and finally save the result in scan_result.json and the exported reports.
What the Outputs Look Like ?
The Tool does not end at mere scan results. The CBOM results have useful information such as ID, asset type, crypto function, algorithm, risk level, quantum exposure, migration recommendation, and notes for each result. The scan results have useful information such as scan_result.json, HTML reports, JSON export, CBOM CSV export, and Markdown reports. In addition, if AI is enabled, the tool will generate results such as AI-assisted summaries, migrations, and QKD results. The HTML reports are useful because they contain all information in one document, including scan summaries, assets found, CBOM results, RSA/ECC information, crypto information, and the migration roadmap.
A Personal Note on Building This Project
What was interesting to me in this project was that it was really an amalgamation of all these ideas in cybersecurity. It wasn't just scanning code; it wasn't just post-quantum theory. It was really about making things visible, making things structured, making things operational.
Part of this process was also an AI-assisted vibe coding. While AI was there to help speed up the process of ideation, drafting, and even some of the structural aspects of things, it was never really about making code. It was always really about deciding what we wanted to find in this scanner, what we wanted to find in terms of cryptographic concepts, how we wanted to structure the CBOM, and how we wanted to make all of that useful.
What I think I like most about projects in cybersecurity is that it really gets you to move beyond definitions and into designing things. You're no longer just learning what these technologies are; you're really learning how you're supposed to think about them in real-world situations.
GitHub
Repo Link: https://github.com/BnHany/QuantumLedger-CBOM
If you would like to explore the project, review the code, or contribute ideas, feel free to check the repository. Contributions, feedback, and suggestions are always welcome.
DeepWiki
DeepWiki Link: https://deepwiki.com/BnHany/QuantumLedger-CBOM
For a more structured walkthrough of the project, architecture, and technical flow, the DeepWiki page provides a helpful overview.
Final Thoughts
Ultimately, growth is not only about succeeding and finishing tasks, but about who we become along the way. We can always learn something new and valuable from every challenge and every step forward. We can become better thinkers and better people with more strength and patience and understanding. What is important is that we can continue to learn and improve and go on with purpose and determination.
Built with ❤️ to make CBOM analysis and post-quantum security thinking easier, clearer, and more accessible.
Author: BnHany License: MIT