How DSALTA integrates with GitHub — data collected, setup guide, and automated compliance checks.
Overview
How to connect
Automated checks
Useful links
DSALTA connects to GitHub using read-only API access to collect compliance evidence automatically. Data feeds into your Data Library modules. Compliance checks re-run once a day at 02:00 America/New_York.
Read-only access. DSALTA never modifies, creates, or deletes resources in your GitHub environment.
DSALTA reads the GitHub account that authorised the connection — its name and email address, a single row on your Access page; and your GitHub resources, which appear on your Inventory page; and open security findings, which appear on your Vulnerabilities page. DSALTA does not sync your organisation’s member list, so there is no roster on that page, and the one row’s role always reads User with status Active — neither value is read from GitHub. It also reads your currently open pull requests, which appear on your Code Changes page — DSALTA does not read commits, and merged, closed or draft pull requests are discarded.It calls these GitHub endpoints:
Permissions the checks require:issues, read:org, repo, security_events. Reading branch protection needs Administration: Read on a fine-grained token, or repo on a classic token.Every request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your GitHub environment.
There is no Reconnect button. Open Integrations → Connected, click Manage on the GitHub card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from GitHub. This usually happens when API tokens expire.
Data is not syncing
Verify the connected account still holds the permissions listed under Before you begin. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.
Use a GitHub personal access token (classic or fine-grained) with the scopes required for your organization’s security tests.Before you begin
GitHub account with access to repositories to assess
Dependency graph + Dependabot alerts enabled on the repositories/organization (Settings → Code security) — required for vulnerability data
1
Start in DSALTA
Open Integrations in the DSALTA sidebar, find GitHub, and click Connect to open the connect panel.
2
Integrating GitHub with DSALTA means
DSALTA will use your token to read GitHub data (repositories, branch protection, Dependabot, code scanning, secret scanning, and related settings) for security and compliance monitoring.DSALTA only reads. There is no code path that creates, modifies, or deletes anything in your repositories or organization — every remediation is something your team does directly in GitHub.
3
Create a personal access token
Open GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens.
Choose the organization you want DSALTA to monitor as the Resource owner.
If you own that organization, the token is active right away — continue.
If you don’t own it, the token is created as Pending and won’t work until an organization owner approves it. Ask an owner to approve it under: the organization → Settings → Third-party access → Personal access tokens → Pending requests → Approve.
Select Expiration (recommended 1 year).
Set Repository access to All repositories (recommended).
Add Organization permissions (read-only): Members — lets DSALTA verify that everyone with access maps to a person on the People page (the User access to Critical System check).
Generate token and copy it once.
If the organization you pick as Resource owner requires approval for fine-grained tokens, a justification box appears directly below the resource owner field. Fill it in — what you write there is what the organization owner sees when they review the pending request.
If your organization uses SAML single sign-on and you created a classic token, the token does nothing until you authorize it: Settings → Developer settings → Personal access tokens, click Configure SSO next to the token, then Authorize next to the organization. You must have signed in to the organization through your identity provider at least once for Configure SSO to appear. Fine-grained tokens do not need this — they are authorized when you pick the Resource owner.
An organization can switch fine-grained tokens off entirely, not just require approval. If an owner has selected Restrict access via personal access tokens under the organization’s Settings → Personal access tokens → Fine-grained tokens tab, your token can only see public data and no amount of waiting for approval will fix it — an owner has to change the policy to Allow access via personal access tokens first.
4
Enable Dependency graph & Dependabot alerts
Vulnerabilities come from Dependabot alerts, which first need the Dependency graph turned on — the token can read them, but the features must be on or there’s nothing to read.In GitHub → Settings → Code security, click Enable all for both:
Dependency graph
Dependabot alerts
5
Enter token
Paste your token below and click Connect.Personal access token — Example: ghp_… or github_pat_…There is a second field in the panel: Organization. Enter the organization login exactly as you set it in the token’s Resource owner — for example my-org. DSALTA then tracks only that organization’s repositories. Leave it empty only if you are connecting a personal account, or using an org-wide classic token.
If you fill in Organization, the token must be able to read at least one private repository in it — that is the check DSALTA uses to prove the token really reaches the org. An organization with only public repositories will be rejected no matter how correct the token is. In that case leave Organization empty, or add a private repository to the org.
DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.
If the connection is rejected. Invalid token or insufficient scopes for the requested operations.The on-screen message is generic — see Connection error messages.
Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.
.png?fit=max&auto=format&n=tsMQJyneJ1xquFUo&q=85&s=4d401cc03b547d99b6f75a6bd170c334)
