Connect your Git org to Ctadel#

Ctadel scans IaC, secrets, and dependencies on every push and pull request. The setup is a single click on GitHub, or a one-time OAuth authorization on GitLab. No tokens to copy-paste, no per-repo webhook configuration on GitHub.

GitHub — one-click install#

1. In Ctadel, open Settings → Integrations.
2. Click Install Ctadel on GitHub. You land on GitHub's install page for the Ctadel App.
3. Choose your organization.
4. Choose the repository scope:
   • All repositories (current + future) — recommended; new repos are scanned automatically.
   • Only select repositories — pick the ones you want covered. You can change this later in GitHub Settings → Applications → Configure.
5. Click Install. GitHub redirects you back to Ctadel.

That's it. From here:

• ✅ Webhooks are delivered automatically for every selected repo (push + PR).
• ✅ Ctadel posts three status checks (ctadel/iac, ctadel/secrets, ctadel/sca) and three PR comments per PR.
• ✅ No tokens, no per-repo webhook setup.

GitLab — OAuth + project webhooks#

GitLab doesn't have a true equivalent of GitHub Apps, so the flow is two parts:

1. OAuth to authorize Ctadel on your account.
2. Per-project webhooks with the secret Ctadel generates for you.

Step 1, OAuth#

1. In Ctadel Settings → Integrations, click Connect Ctadel to GitLab.
2. GitLab prompts you to authorize Ctadel. Approve.
3. Back in Ctadel, a yellow banner shows a one-time webhook secret. Copy it — it isn't shown again.

Step 2, configure webhooks on each project#

For every GitLab project you want scanned:

1. Open the project Settings → Webhooks → Add new webhook.
2. URL: https://<your-ctadel-host>/webhook/git (Ctadel shows the exact URL in the install banner).
3. Secret token: paste the secret from Step 1.
4. Triggers: ✅ Push events, ✅ Merge request events.
5. Add webhook.

You can reuse the same secret across all projects of the same group — that's the point of having Ctadel generate it once.

What gets scanned#

Every push and PR triggers three checks in parallel:

Each posts its own PR comment + commit status. Branch protection rules can require any subset of them.

Tuning per-family policy#

In Settings → Integrations → ⚙ (per integration) you can tune:

• Enabled / disabled (per family).
• Block PR on failure (per family) — fails the commit status if findings exceed the threshold.
• Severity threshold: CRITICAL, HIGH, MEDIUM, LOW, or ANY (secrets only — block on first leak).

Defaults match industry practice:

• IaC: block on HIGH and above.
• Secrets: block on ANY (one leak is one too many).
• SCA: info-only by default (don't block on CVEs you can't fix immediately).

What gets posted on each PR#

Open Settings → Integrations and click the ⚙ on your integration to see the active policies. Then push a commit to a PR — within ~30 seconds you should see:

• 3 status checks on the commit (ctadel/iac, ctadel/secrets, ctadel/sca).
• 3 PR comments, one per family, each with a top-10 findings table and a link to the full Ctadel scan report.

Ignoring a finding#

Two options:

1. From Ctadel UI — open the finding's detail panel, click Ignore, give a reason. The finding stays in the DB but no longer fails the status check.
2. From .ctadel.yaml in the repo root — the scanner reads it on every scan and suppresses listed findings before they hit the DB.

See Suppress or ignore a finding for the full spec.

Common pitfalls#

• GitHub install but no scans — check GitHub Settings → Applications → Configure → Recent deliveries. Failed deliveries (red) usually mean Ctadel's webhook secret doesn't match the App's. Contact your Ctadel admin.
• GitLab MR not scanned — verify the project webhook is enabled and Merge request events is checked. The webhook delivery log shows the response body on failure.
• "No matching installation" — you removed the App from your org. Re-install from Ctadel Settings.

What's next#

• IaC concept
• Secrets concept
• Vulnerability management
• Suppress or ignore a finding