Wiring cryptographic scans into GitHub and CI
Move from one-off audits to continuous discovery by running the scan in your pipeline — install the app, gate on new vulnerable crypto, and keep the inventory current without anyone remembering to re-run it.
Continuous beats one-off
A cryptographic inventory built once is stale the next week. Wire the scan into CI so every pull request and every build is checked, new vulnerable cryptography is flagged before it merges, and the readiness score updates automatically. The GitHub App reports findings inline on pull requests; the CI step is your enforcement point.
The difference between a migration program that drifts and one that holds is automation. If keeping the inventory current depends on someone remembering to run a scan, it will rot. Putting discovery in the pipeline makes 'no new quantum-vulnerable crypto' a property the codebase maintains on its own.
Install the GitHub App
- Install the Quantakrypto GitHub App on your organization and grant it read access to the repositories you want scanned.
- Select repositories explicitly rather than granting org-wide access if you want to start with a pilot.
- The app scans on push and pull request, and posts findings as a check and inline annotations on changed lines.
- Review the first full-repo scan as your baseline inventory before turning on any gating.
Add a CI step for enforcement
- Add the scan as a job in your existing pipeline (GitHub Actions, GitLab CI, or similar) so it runs on every build.
- Configure it to fail the check when a new quantum-vulnerable algorithm is introduced, while allowing the existing backlog through — you gate on regressions, not on the whole legacy estate at once.
- Publish the readiness score as a build artifact or status so the trend is visible in the pipeline, not just in a dashboard.
- Wire failures to the team that owns the code, not a central inbox, so findings land where they can be fixed.
Gate on new debt, not the whole backlog
If you fail the build on every pre-existing RSA usage on day one, teams will disable the check. Instead, set the baseline from your first scan and fail only when new vulnerable crypto is added. That stops the backlog from growing while you work it down deliberately — a ratchet, not a wall.
Least privilege for the scanner too
The scanner needs read access to code and dependency metadata — not write access, not secrets. Grant the minimum scope, scope it to the repositories in play, and review the app's permissions like any other third-party integration. A discovery tool should never become a new attack surface.