Know what a CipherMap finding proves—and what it does not
CipherMap is a local static scanner for supported source and configuration signals. It helps teams find, identify, and review cryptographic usage during migration planning. It is one input to a cryptographic inventory, not a complete inventory of a deployed system and not a readiness certification.
Detection lifecycle
From observation to reviewed finding
- 01
Observe supported source signals
Language rules inspect selected cryptographic APIs, algorithm names, key material patterns, randomness usage, and configuration signals. The Go scanner also uses AST imports and supported call-site details.
- 02
Attach explicit rule identity
A finding carries a rule identity, severity, source location, and report provenance so reviewers can trace what was observed and which producer and rule bundle emitted it.
- 03
Apply the requested policy boundary
The base rules identify source risk. Authorized commercial profiles can add policy-oriented findings; profile output remains detection evidence rather than a compliance determination.
- 04
Review before acting
A source owner confirms purpose, reachability questions, compensating controls, false positives, and migration priority. Supported proposals remain review material; production source publication is unavailable in this release.
Cryptographic inventory has multiple layers
Source scanning answers a different question from package, runtime, network, certificate, and hardware inventory. A defensible programme combines the relevant layers and preserves their different evidence.
- Inventory layer
- Source and configuration
- CipherMap role
- CipherMap's primary scope
- Boundary
- Supported language source, Go AST imports and selected call sites, selected IaC/TLS configuration, committed-key patterns, and weak-randomness signals.
- Inventory layer
- Dependencies and manifests
- CipherMap role
- Separate path
- Boundary
- Selected manifest checks and optional enrichment are distinct from source findings. They do not prove that a dependency is loaded, reachable, or deployed.
- Inventory layer
- Runtime and network
- CipherMap role
- Outside source-scan evidence
- Boundary
- Running processes, protocol negotiation, service endpoints, network appliances, and observed traffic require runtime or network inventory tools.
- Inventory layer
- Certificates, keys, and HSMs
- CipherMap role
- Outside complete inventory
- Boundary
- Certificate stores, key-management systems, HSM inventories, rotation state, ownership, and deployed key material require authoritative platform records.
Finding identity and review
Supported report formats retain rule and source-location identity, and the versioned JSON report includes producer and rule-bundle provenance. That identity helps CI, review, and downstream reconciliation refer to the same signal; it does not make the signal self-validating.
- • Review the exact file and surrounding code, not only a summary count.
- • Confirm whether the code is active, generated, test-only, vendored, or configuration-dependent.
- • Record the reviewer, disposition, rationale, and follow-up outside any unreviewed scanner claim.
- • Re-run the same scoped workflow after changes and compare identities rather than assuming equivalence.
CycloneDX 1.6-shaped boundary
When an authorized commercial build enables CBOM generation, the current serializer targets a CycloneDX 1.6-shaped document with cryptographic-asset cryptoProperties. The browser Visualizer likewise accepts an existing document that declares CycloneDX specification 1.6.
This is a precise compatibility boundary—not a claim that 1.6 is the newest CycloneDX revision, that every possible field is populated, or that the document has received third-party conformance certification. Undetermined properties are omitted instead of invented. The normal Free source-preview build does not generate Tier A CBOM output.
Review the documented CBOM commandKnown interpretation limits
- Pattern matches can produce false positives, and unsupported syntax, aliases, generated code, exclusions, or novel abstractions can produce false negatives.
- Most language rules are source-pattern rules. They do not provide whole-program data-flow, control-flow, or reachability analysis.
- A source reference does not prove that a primitive is executed, externally exposed, exploitable, or used in a production deployment.
- A zero-finding result is not evidence of cryptographic absence. Scope, ignored paths, generated assets, binaries, runtime systems, and external services still matter.
- Policy profiles help organize findings against selected guidance. They do not certify a system, replace an assessor, or decide which mandate controls a customer environment.
Test the method against a representative repository
A controlled evaluation begins by agreeing what is in scope and which inventory layers remain outside the source scan. Bring the languages, repository shape, environment, and policy question you need to assess.