Cryptographic Discovery and Inventory¶
PostQ helps you answer three questions: Where does this application use cryptography? What is it doing? Which settings can we establish from the source? The result is an inventory linked to the code, ready for security review and migration planning.
A key capability is grouping the steps of a cryptographic operation into one logical asset. PostQ brings together the algorithm, settings, and related calls so the operation can be assessed with the context needed to understand its security.
Cryptographic asset inventory¶
PostQ identifies supported cryptographic calls and records their source files, locations, libraries, and operations. Individual calls provide a detailed inventory; related calls can be viewed together as a logical operation.
This inventory describes the source included in a scan. A call count, an operation-group count, and an algorithm count measure different things. They are not counts of deployed keys, certificates, or running services. An empty inventory does not establish that an application contains no cryptography.
Multi-step cryptographic operation grouping¶
Cryptography often takes several steps in code. Encryption, for example, can involve choosing an algorithm, configuring a key and initialization vector (IV), processing data, and completing the encryption. Each call contributes only part of the operation's security information.
PostQ identifies supported relationships between these calls and treats the combined operation as one logical cryptographic asset for assessment. Each call and its source location remain available for detailed review.
| Steps in an encryption operation | Information brought into the assessment |
|---|---|
| Choose the cipher | Algorithm, mode, and padding, where available. |
| Configure encryption | Key, key size, IV or nonce, and other supported settings. |
| Process data and complete encryption | The calls that use the configuration to perform the operation. |
Assessing the related steps together supports more accurate, context-aware assessment. For example, the final encryption call may not state its algorithm or IV. Grouping connects that call to the earlier configuration, making those settings available to the operation's assessment and keeping missing or conflicting information visible.
The same approach applies to supported multi-step operations such as key generation, digital signatures, hashing, and message authentication. It also helps reviewers see which source locations need attention when an operation changes.
Grouping depends on the relationships PostQ can establish in the source. A group does not prove successful execution or correct handling of every result. For instructions on reviewing the grouped asset, see Operation Groups.
Cryptographic operation identification¶
PostQ identifies the purpose of supported cryptographic use, including:
| Operation area | Examples of what the inventory can describe |
|---|---|
| Data protection | Encryption and decryption, including available mode and padding choices. |
| Keys | Key generation and key establishment or exchange. |
| Digital signatures | Creating and verifying signatures. |
| Hashing and message authentication | Digests and message authentication codes (MACs). |
| Password and key derivation | Deriving keys or password-protection values, with available work settings. |
| Randomness | Supported random-generation calls and relevant source settings. |
| Protocols, certificates, and tokens | Selected cryptographic and configuration uses that provide review context. |
The operation matters: the same algorithm can be used for different purposes that need different assessment and remediation. Detecting token or certificate use does not establish the correctness of the application's entire authentication process.
Language and library identification¶
Library information shows which cryptographic interfaces the application depends on. It helps you distinguish standard library use from third-party cryptography and locate dependencies that may need attention during a change.
The next capability page lists Languages and Libraries Supported and their coverage limits. An identified library does not guarantee that every setting or runtime implementation is known.
Algorithm and parameter details¶
PostQ makes explicit and supported implicit settings visible together.
| Detail | Examples, where supported |
|---|---|
| Algorithm identity | Cipher, hash, signature, key-establishment algorithm, or named parameter set. |
| Key and curve settings | Key size and named elliptic curve. |
| Encryption settings | Mode, padding, initialization vector (IV), nonce, and authentication-tag length. |
| Derivation settings | Salt, iterations, memory or other password-derivation costs. |
| Implementation choice | A requested provider or available library-specific option. |
Reported values retain their meaning and units; a key size in bits is different from a length in bytes. A known algorithm name alone does not describe every security-relevant setting. The evidence distinguishes established values, documented defaults, and settings that remain unknown. An established value is not automatically a secure value.
Values traced through source¶
A cryptographic setting is often defined away from the call that uses it. In supported cases, PostQ follows local assignments, constants, and same-file configuration so the inventory can show both the value and where it came from. Available source locations help your team verify the path from a setting to its use.
For example, a locally defined key size can appear with the key-generation operation that uses it. Values obtained only at runtime, through external services, or through unsupported paths remain unresolved rather than being guessed.
Java properties configuration¶
Supported Java settings read with a literal property key through Properties.getProperty(...)
can be resolved from unambiguous project .properties values. The relevant configuration must be
included in the project scan. Ambiguous definitions, environment overrides, deployment profiles,
and secret-store values require separate review.
API default settings¶
Cryptographic APIs can supply default settings when the code does not specify a value. PostQ identifies supported API defaults when their applicable conditions are known, making these implicit choices visible alongside the settings explicitly written in the code.
An uncertain provider-dependent default can remain unknown. A default does not replace an explicit setting whose runtime value is unresolved.
Configuration reused across calls¶
Some libraries configure an object once and reuse it for later operations. For supported local uses, PostQ can carry the applicable settings into the review of those later calls. Selected object-copy patterns can also preserve the settings established at the time of the copy.
This helps avoid reviewing a later operation without its earlier configuration. Coverage depends on the library and source form. Unknown changes, unclear object relationships, and unsupported copies can leave the later settings unresolved.
Conflicting configuration¶
When supported evidence points to competing parameter values, PostQ keeps the conflict visible. It does not silently choose a value because its source line is nearby. The contributing locations help your team investigate which configuration applies.
Discovery boundaries¶
PostQ analyzes source without executing the application. It does not recover runtime secrets, inventory deployed cryptographic material, or provide unrestricted tracing across files and services. Custom wrappers, reflection, generated code, and runtime inputs can reduce the evidence available. Discovery results should be checked against the application's known cryptographic use.
The inventory supports the five Assessment Dimensions. For instructions on opening, navigating, and exporting it, see Reports and Data.