Roll out OpenThunder to your team

Everything local is free and needs no account. When a team wants shared visibility into what's being verified , without putting source code in a cloud , that's what OpenThunder Cloud and the CI integration are for. This guide is the practical rollout.

1. Everyone works locally first

Each engineer runs OpenThunder locally (Desktop, VS Code, or CLI). The understand/verify loop , verify a change, decide if it's safe to ship , is keyless and private per developer. No central setup is required to get value on day one.

2. Gate merges in CI

Put the same verdict everyone runs locally into the pipeline, so nothing merges without evidence:

openthunder can-i-ship          # SHIP / CAUTION / HOLD, fail the job on HOLD
openthunder security check      # fail on new critical findings, secrets, unauthenticated protected routes

OpenThunder ships as a GitHub Action, a GitLab component, and an Azure DevOps task. openthunder cloud ci-init scaffolds a workflow. See Use OpenThunder in CI.

3. Publish results for shared visibility (privacy-first)

To see posture and trends across the team, publish the derived results , not the source:

openthunder cloud publish       # publish a scan result to OpenThunder Cloud (no raw code)

The Cloud receives scores, findings, and trends only; raw code never leaves the machine by default. See OpenThunder Cloud and the Privacy FAQ for exactly what syncs and when.

4. Route high-risk work through verified missions

For auth, billing, migrations, and security changes, standardize on verified missions so an independent reviewer challenges the change and its checks run before it's accepted , the output is a diff plus an Evidence Pack, not just a diff.

What a team gets