Setting up the NoDowntimeShield GitHub App on your org (step-by-step)
Installing the NoDowntimeShield GitHub App takes about three minutes. This page walks you through the steps, explains every permission we request, and shows you what to expect on your first scanned pull request.
Step 1 — start the install
From your dashboard, go to Integrations → GitHub → Connect. We bounce you to GitHub's standard install page. You can pick:
- All repositories (recommended for full org visibility).
- Selected repositories (start small, expand later).
You can change this later from your GitHub Settings → Applications.
Step 2 — review the permissions
GitHub will ask you to approve the permissions. Here is exactly why we need each:
Repository permissions
| Permission | Why | |-----------|-----| | Contents (Read) | Read source files to scan for secrets, vulnerable dependencies, and SAST findings. | | Pull requests (Write) | Post inline review comments on PRs that fail security checks. | | Issues (Write) | Open issues for findings that don't map to a specific PR. | | Checks (Write) | Post the "NoDowntimeShield Security" check status next to your CI. | | Metadata (Read) | Read repo names, descriptions, default branch — required by GitHub. | | Secret scanning alerts (Read) | Import GHAS alerts so they appear alongside our findings. | | Dependabot alerts (Read) | Same as above for dependency vulnerabilities. | | Code scanning alerts (Read) | Same as above for SAST. | | Administration (Write) | Auto-configure branch protection on first install. Optional — if you decline, your admin must enable manually. |
Organization permissions
| Permission | Why | |-----------|-----| | Members (Read) | Map findings to committers; produce per-person leaderboard for security training. |
Webhook events
| Event | Why |
|-------|-----|
| pull_request | Trigger PR scan on open, sync, reopen. |
| push | Catch secrets in pushes that bypass PR review (force-push, squash-merge). |
| installation | Bootstrap branch protection. |
| installation_repositories | Add new repos to the scan rotation. |
| secret_scanning_alert | Mirror GHAS alerts in our dashboard. |
| dependabot_alert | Same for dep vulns. |
Step 3 — first scan kicks off automatically
Within seconds of install, our worker enumerates the repositories the app has access to. For each, we:
- Add
nodowntimeshield/security-scanas a required status check on the default branch (only if you granted Administration → Write). - Schedule a baseline whole-repo scan — runs in 1–10 minutes per repo depending on size.
- Subscribe to PR webhooks so future PRs are scanned within 30 seconds.
Step 4 — what your first PR looks like
The first time someone opens a PR after install, the experience changes:
- Within 30 seconds of opening the PR, our scan runs. A check named "NoDowntimeShield Security" appears next to your existing CI checks.
- If the diff is clean, the check goes green. No comments.
- If we find something — a leaked secret, a dep with a known CVE, a SAST finding — we post one summary comment with severity counts and inline review comments on the offending lines.
The comment auto-updates as the PR evolves. If the developer pushes a fix, the next scan re-evaluates.
Step 5 — configuring routing and alerts
From the dashboard:
- Severity routing: pick which findings go to Slack vs Email vs WhatsApp vs PagerDuty.
- Auto-resolve: opt in to auto-resolve findings if the developer pushes a fix in the same PR.
- Live credential validation (off by default): if you enable, we ping the issuing service (AWS, Stripe, etc.) for a 2-second timeout to confirm the leaked key is real. Bumps severity to critical when validated.
- PR comment style: choose between a single summary comment (default) or one comment per finding.
Step 6 — uninstalling
Two clicks: GitHub Settings → Applications → NoDowntimeShield → Uninstall. We retain finding history for 30 days post-uninstall (so you can reinstall without losing data); after that, all GitHub-derived data is purged.
Common questions
Q: Do you store our source code? A: No. We read files in memory during the scan and discard them. Findings reference file paths and line numbers but never raw source.
Q: Will it slow down our PRs? A: Our check runs in parallel with your existing CI. The PR is not blocked unless you have set us as a required status check (which you control).
Q: What about private repos? A: Same coverage as public. Permissions are scoped to what you grant.
Q: Can we self-host? A: Self-hosted is on the roadmap; for now we are SaaS-only. The data we store is the finding metadata, not your code.
If anything is unclear, the help center covers the longer cases. Start your free trial at /check.