Wiring cryptographic scans into GitHub and CI
Move from one-off audits to continuous discovery: install the app so the platform can keep the inventory current, and add the Action to your pipeline to gate on new vulnerable crypto, without anyone remembering to re-run a scan.
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 Action is your enforcement point and annotates findings on pull requests; the GitHub App keeps the platform's inventory current by dispatching scans and receiving the results.
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 does not scan on push or pull request. When the platform requests a scan it fires a repository_dispatch, the workflow runs in your repo's own GitHub Actions, and the results are posted back to the platform with a one-time token. The app itself holds only read access to contents and metadata plus the dispatch permission.
- 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 (the quantakrypto Action on GitHub Actions; the CLI on 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.
- On pull-request runs, the Action posts findings inline on the changed lines (enable its comment-pr input and pass a github-token). Inline annotations come from the Action, not the app.
- 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.