Repository discovery identifies supported static declarations at an exact relative path, line and column. It is inferred evidence about source code—not proof that the code is built, deployed, reachable or used at runtime, and never proof of complete repository or organizational coverage.
What the local scanner inspects
The first rule set recognizes selected cryptographic API imports and calls, dependency declarations, and TLS, certificate or cipher configuration in supported text files. Each match records the rule, category, language, relative path, location, allowlisted symbol and a SHA-256 digest of the file.
The browser applies explicit file-count, per-file, total-byte and finding limits. Hidden paths, dependency vendor trees, build output, binaries and secret-like files are excluded before content inspection.
- Supported API patterns for Go, JavaScript and TypeScript, Python, Java and .NET.
- Selected package manifests and deterministic dependency identifiers.
- Selected TLS protocol, cipher and certificate configuration directives.
- Exact inspected, excluded, unsupported, unreadable and truncated coverage counts.
What leaves the browser
The service rejects unknown rules, categories, languages and symbols instead of trusting a client-provided interpretation. It recomputes normalized identity, evidence, confidence and migration relevance using the server-side rule catalog.
| Retained metadata | Not transmitted |
|---|---|
| Source label and scanner/rule versions | Repository archive, source file or file content |
| Relative path, line, column and allowlisted symbol | Matched line, surrounding snippet or arbitrary symbol |
| File SHA-256 and deterministic finding identity | Private key, password, token or credential |
| Bounded coverage counters and limits | Git history, author identity or remote URL |
How to interpret a repository finding
A repository finding is retained as an inferred, medium-confidence asset with its exact static-analysis evidence. Public-key API declarations can require migration review, while a generic cryptographic library dependency usually requires confirmation of the algorithms and runtime path actually used.
Importing a newer manifest for the same source creates source-scoped NEW, CHANGED, RESOLVED and UNCHANGED comparisons. RESOLVED means the static finding was absent from the newer bounded manifest; it does not prove removal from every branch, build artifact or deployment.
Frequently asked questions
Does Cipher Discovery upload my repository?
No. The supported files are read and matched locally in the browser. Only the explicitly reviewed metadata manifest is submitted; source content and snippets are not included.
Does a match prove the cryptography runs in production?
No. It proves only that a supported deterministic pattern appeared at the recorded source location. Build, deployment and runtime use remain unknown until supported by separate evidence.
Does no finding mean the repository contains no cryptography?
No. Unsupported languages, generated or excluded paths, indirect dependencies, dynamic behavior and files outside the selected directory can remain unknown. The coverage section shows the bounded inspection performed.
Can this expose secrets?
The scanner excludes secret-like and hidden paths and never puts source lines or snippets in the manifest. Users must still select only repositories they are authorized to assess and review the metadata before import.