Product Overview¶
PostQ Code Scanner is a cryptographic asset discovery and assessment tool for application source code. It generates an inventory of detected cryptographic use and connects that inventory to source evidence, security findings, and post-quantum migration guidance.
Application teams use PostQ to locate and improve cryptographic code. Security and architecture teams use the same evidence to establish a baseline, prioritize remediation, and plan migration. Compliance specialists can retain source-level findings alongside their deployment evidence.
Discover cryptographic assets¶
Identify supported cryptographic libraries, algorithms, and operations in a repository. Examine individual API calls or related calls grouped into a logical operation, such as cipher initialization followed by encryption.
The inventory describes cryptography observed in source; it is not an inventory of every deployed key, certificate, or external cryptographic service. Generate a CBOM to share detected assets with compatible inventory tools. Associate the results with application owners in your existing records. See Cryptographic Discovery and Inventory.
Assess security and migration needs¶
PostQ assesses the available source evidence across distinct review areas:
| Review area | Customer use |
|---|---|
| Post-quantum cryptography (PQC) | Identify quantum-exposed operations and review supported PQC algorithm use when planning migration. |
| FIPS source | Investigate potential FIPS source issues and evidence gaps before reviewing module and deployment assurance. |
| Common Weakness Enumeration (CWE) | Classify supported cryptographic weaknesses and connect them to remediation tracking. |
| Crypto agility | Examine supported algorithm dependencies, configuration choices, and migration indicators when assessing how cryptography can be changed. |
| Risk signals | Review supporting context, anti-patterns, and parameter concerns without treating every observation as a vulnerability. |
These assessments answer different questions. An operation can need quantum migration without having a separate coding weakness, and source-level FIPS results do not establish deployment certification. Crypto-agility evidence supports an architecture review; PostQ does not assign a per-asset agility score or establish that a replacement will be compatible.
Unknown or conflicting settings remain visible for investigation. See Assessment Dimensions.
Investigate and improve code¶
Move from the repository assessment to the affected operation, inspect its settings and source, and use available remediation guidance to define changes. IDE integrations provide source navigation, problem indicators, report history, and comparison.
After a change, rescan and compare the evidence. Continue using application tests and code review to verify behavior and compatibility. See Reviewing Results.
Share evidence¶
Share a complete report folder with reviewers, export selected rows to CSV or JSON, or use the CycloneDX CBOM and SARIF files with compatible inventory and security tools. See Sharing Reports.
Evaluate PostQ for your applications¶
Use a representative repository and a known set of cryptographic uses to evaluate fit before a broader rollout. Review the evidence with the application owner, security team, and architect.
| Evaluation question | Evidence to examine |
|---|---|
| Does discovery cover our technology stack? | Compare the language and library coverage with known cryptographic use in the selected source. Investigate missing and unresolved items. |
| Can teams act on a result? | Follow a reported operation to its source, inspect configuration evidence, and review the available remediation guidance. |
| Can we scope a PQC migration? | Review quantum exposure and migration indicators, then add business criticality, data-protection lifetime, and compatibility requirements in your planning process. |
| Can we retain and exchange evidence? | Review the CBOM, SARIF, scan identity, and full report set; confirm that receiving tools preserve the information your process needs. |
| Does it fit our operating environment? | Complete a local, IDE, or pipeline scan and verify report access, licensing, and data-handling requirements. |
For a practical sequence, see Establish an application baseline.
Choose where to work¶
| Interface | Typical use |
|---|---|
| Command line | Local scans, scripts, and build agents |
| VS Code | Workspace scans and review alongside source |
| Eclipse or Spring Tools | Project scans, problem markers, and report comparison |
| Container | Scanning in a packaged Linux environment |
| Standalone Report Viewer | Reviewing completed reports without a scanner installation or license |
| CI/CD | Scanning checked-out revisions and retaining reports with a build |
Follow Getting Started to set up the required interface.
Understand the scope of a result¶
PostQ analyzes the source selected for a scan. Available evidence can include literal values, supported values traced through a file, Java properties, documented defaults, and configuration reused across supported operations.
Runtime settings, external services, custom wrappers, and unsupported source forms can require manual review. A scan does not establish that unmatched code is secure or that all cryptography has been found. PostQ does not automatically change source code.
Check Languages and Libraries Supported and Assessment Dimensions for your application.
Local operation¶
Source analysis, report generation, and license validation take place locally. The current beta does not provide an external analysis integration. Protect reports as security-sensitive engineering information; they can include paths, code excerpts, and cryptographic settings.
See Security and Privacy.