GitHub

The GitHub integration connects a GitHub App installation to Keldyn’s continuous-evidence engine. Once connected, Keldyn reads repository access, organization authentication settings, branch protections, pull-request reviews, deployment approvals, per-change check results, commit/branch/tag history, vulnerability-scanning results, GitHub Actions workflow and run history, and Actions secret metadata on a schedule, and turns them into live evidence for the related controls. Some of that evidence depends on you telling Keldyn what a workflow is for. Keldyn proposes those mappings; you confirm them, and nothing counts toward a control until you do — see Confirm your workflow mappings.

Integrations and automated evidence are typically managed by workspace admins. See Evidence & audits for how automated evidence fits alongside manual evidence.

What it’s used for

Keldyn uses the data it reads from GitHub to keep evidence for source-code access, change management, testing of changes, version control, secure development, and vulnerability management current. Each refresh updates the evidence and freshness status shown in the integration’s Controls covered table. The integration contributes evidence to these ISO 27001 controls:

Control	Topic	Coverage
A.8.4 — Access to source code	Repository permissions and protected write paths	Full
A.8.32 — Change management	Branch protections and pull-request approval history	Full
A.8.8 — Management of technical vulnerabilities	Dependency and code-scanning posture and findings, or a confirmed scanning workflow’s run history	Full
A.8.28 — Secure coding	Your confirmed code-quality gate passing on every merged change	Full, once confirmed
A.8.29 — Security testing in development and acceptance	Your confirmed test run passing on every merged change, plus the artifacts it retained	Full, once confirmed
A.5.7 — Threat intelligence	Run history of your confirmed threat/dependency watch workflow	Full, once confirmed
A.5.17 — Authentication information	Last-updated timestamps for the secrets you put in rotation scope, plus your confirmed rotation workflow’s runs	Full, once confirmed
A.5.15 — Access control	Repository-level access assignments	Partial
A.8.5 — Secure authentication	Organization two-factor authentication requirement	Partial
A.8.25 — Secure development life cycle	Pull-request reviews and static analysis	Partial

It also contributes evidence to these SOC 2 controls:

Control	Topic	Coverage
Software changes approved	Branch-protection config, pull-request approval records, and deployment approver + timestamp per release	Full
Testing of changes	CI pass/fail status gating each merge, sampled per pull request	Full
Version control software	Repository list plus commit, branch, and tag history	Full
Vulnerability scans	Run history of your confirmed security-scan workflow	Full, once confirmed

Full coverage means the data is the artifact the control asks for. Partial coverage means the data usefully contributes but does not, on its own, replace everything the control requires. For example, pull-request reviews support a secure development life cycle but do not prove that the complete life cycle is defined and followed. Full, once confirmed means the data is the artifact the control asks for, but only after you tell Keldyn which workflow or secret plays that role — see Confirm your workflow mappings. Keldyn labels partial coverage so it isn’t mistaken for complete coverage.

GitHub’s own scanners cover application and dependency vulnerability scanning only (Dependabot alerts, code scanning, and the code-scanning analysis run history), so on their own they leave Vulnerability scans Partial. If you already scan more broadly through your own GitHub Actions workflow, confirming that workflow closes the gap: its run history evidences scans running on your schedule with their results recorded, whatever they scan. Otherwise, infrastructure-level scanning still needs a Tenable/Qualys-style source connected separately.

Before you begin

Use a GitHub organization owner

Installing the Keldyn GitHub App on an organization requires organization owner approval. If you aren’t an owner, GitHub may leave the installation pending until an owner approves it.

Choose the repositories to include

During installation, choose whether Keldyn can read all repositories or only selected repositories. Evidence only covers repositories included in the GitHub App installation.

Keldyn only ever reads

The GitHub App uses read-only repository and organization permissions. Keldyn never changes repository settings, merges code, edits branches, or modifies security alerts.

Set up the integration

Open Integrations

In the Keldyn web app, go to Integrations and select GitHub.

Connect

Select Connect. GitHub opens the Keldyn GitHub App installation flow. Choose the organization and repositories to connect, review the requested read-only access, and approve the installation.

Authorize your GitHub account

Complete the GitHub authorization request. Keldyn uses it to verify that your GitHub account can access the installation; it does not store your user access token.

Run the first sync

After GitHub returns you to Keldyn, select Sync now to pull evidence immediately, or wait for the scheduled refresh. The Controls covered and Evidence sources tables then show what was collected and how fresh it is.

From the integration detail page, Controls covered shows whether GitHub is actively feeding each control and whether the control is satisfied. Evidence sources shows each data fetch, the controls it covers, and its freshness.

Confirm your workflow mappings

Keldyn can read what your GitHub Actions workflows are configured to do — that one runs a scanner every Monday, that another runs your test suite on each pull request. What it cannot know is which of them your compliance posture actually rests on. A workflow named security.yml might be a real scan or an experiment someone left behind, and a job that never mentions “test” might still be the suite that gates your releases. So Keldyn proposes, and you confirm. After the first sync, the Workflow and secret mappings card on the GitHub integration page lists each workflow and automation secret Keldyn thinks plays a role, along with the signal that prompted the proposal — the schedule it runs on, the actions it invokes.

A proposed mapping evidences nothing. Until you confirm it, Keldyn collects no run history for that workflow and the control it would feed stays unsatisfied. This is deliberate: an auditor should never be shown a control marked satisfied on the strength of a guess Keldyn made about your pipeline.

For each proposal you can:

Confirm it, which records your name and the time against the mapping and starts collecting that workflow’s run history on the next sync.
Reject it, which stops Keldyn proposing it again. A rejected mapping is never revived by a later sync.

Secrets work slightly differently. Keldyn lists every repository and organization Actions secret it can see and asks which ones your rotation policy covers, because a secret’s name says nothing reliable about whether it is in scope. When you confirm a secret you also set its rotation period, defaulting to 90 days. Keldyn reads secret names and timestamps only — GitHub never exposes secret values, and Keldyn never stores one.

Confirm the workflow that genuinely represents the control, not the one that runs most often. A weekly scan you actually act on is better evidence than a nightly job whose results nobody reads.

What data Keldyn collects and why

Keldyn requests read-only access and collects only the data needed to build control evidence.

Data collected	What it contains	Why Keldyn collects it	Refresh
Repository collaborators	Direct collaborators and their permission levels for each included repository	Shows who can access source code and what level of access they hold	Daily
Organization 2FA requirement	Whether the connected organization requires two-factor authentication	Contributes evidence for secure authentication	Daily
Default-branch protection	Protection settings for each repository’s default branch, including review and status-check requirements, kept as a point-in-time snapshot	Shows how repositories restrict direct changes and gate merges — a later weakening stays visible in evidence history even though the live check only judges the current state	Daily
Pull-request reviews	Recent merged pull requests and their review and approval history	Provides a review trail for change management and secure development — a merge with no recorded approval shows as a gap	Daily
Deployment approvals	Each environment’s required-reviewer protection rule, plus the approval or rejection events raised against recent workflow runs (approver and timestamp)	Evidences that deployments to protected environments require and receive a recorded approval per release	Daily
Check results on merged pull requests	The required status checks configured on the branch, plus every check run at the merge commit with its name and conclusion, for a sample of recently merged pull requests	Evidences that automated tests actually ran and passed — or were required at all — before a change was allowed to merge. Keeping every check, not just the required ones, is what lets your confirmed quality gate or test run be found by name even when branch protection treats it as advisory	Daily
Repository, commit, branch, and tag history	Repository metadata plus a sample of commit, branch, and tag history (author and timestamp only — not commit messages)	Evidences that source code is kept under version control with a retrievable change history	Daily
Workflow definitions	Each workflow’s name, file path, enabled state, the events that trigger it, its schedule (cron), and the actions its steps run	Lets Keldyn propose which workflow evidences which control, and shows what your pipeline is configured to do. Workflow files are read to derive these fields and are not stored	Daily
Workflow run history	For confirmed workflows only: each run’s trigger event, status, conclusion, commit SHA, and start/end timestamps	Evidences that a scheduled scan, watch, or rotation job actually runs on its cadence and what each run concluded — not merely that it is defined	Daily
Run artifacts	For confirmed workflows: each artifact’s name, size, and creation and expiry timestamps	Supporting evidence that a run produced retained output, such as a test report or scan result. Artifact contents are never downloaded or stored	Daily
Actions secret metadata	The names and created/last-updated timestamps of repository and organization Actions secrets	Evidences that the credentials you placed in rotation scope are actually being changed within your rotation period. Secret values are never read — GitHub does not expose them, and a timestamp shows that a secret changed, never what it changed to	Daily
Dependabot alerts	Whether Dependabot is enabled and the open dependency-vulnerability alerts for each repository	Evidences dependency scanning and active vulnerability findings	Hourly
Code-scanning alerts	Whether code scanning is enabled and the open static-analysis alerts for each repository	Evidences static security testing and active vulnerability findings	Hourly
Code-scanning analysis runs	Per-repository analysis run history: which tool ran, the scanned ref, when results were uploaded, and how many results each run produced	Evidences that scans are actually run on an ongoing basis, not just enabled	Hourly

Keldyn does not collect pull-request titles, commit messages, workflow file contents, artifact contents, or secret values. If Dependabot or code scanning is disabled, Keldyn records that state as evidence instead of treating the sync as a technical failure. A repository with no branch protection, no required status checks, or no recorded deployment approval is likewise recorded as real (unfavorable) evidence rather than a sync failure.

Permissions

The Keldyn GitHub App requests these read-only permissions:

Permission	Purpose
Repository metadata	Discover included repositories and read collaborator access
Repository administration	Read collaborator permissions and default-branch protection
Pull requests	Read recent merged pull requests and their reviews
Checks	Read check-run results at each merge commit for CI status
Actions	Read workflow definitions, workflow run history, and run-artifact metadata
Environments	Read deployment-environment protection rules and approval history
Contents	Read commit, branch, and tag history, and the workflow files used to derive schedules and action names
Secrets	Read Actions secret names and timestamps. GitHub never returns secret values through this permission
Dependabot alerts	Read dependency-scanning posture and alerts
Code scanning alerts	Read static-analysis posture, alerts, and analysis run history
Organization administration	Read the organization’s two-factor authentication requirement

Keldyn stores the GitHub App installation ID and organization metadata. It mints short-lived installation tokens when it refreshes evidence and does not store a per-user GitHub token.

Troubleshooting “Access required”

A control shows Access required when the GitHub App cannot read the matching data. Common causes include:

The repository isn’t included in the GitHub App installation.
The installation is waiting for organization owner approval.
A required read permission isn’t granted to the GitHub App.
Organization administration access isn’t available for the 2FA requirement.
The Environments, Checks, or Contents permission isn’t granted, which blocks deployment-approval, CI-status, or version-control-history evidence respectively.
The Actions permission isn’t granted, which blocks workflow definitions, run history, and run artifacts — so no mappings are proposed and the controls that depend on a confirmed workflow stay unsatisfied.
The Secrets permission isn’t granted, which blocks rotation evidence for A.5.17.
GitHub Actions is disabled for a repository. Keldyn records this as an empty workflow list rather than a failure.

A control can also stay unsatisfied without any access problem at all: if its mapping is still proposed, nothing has been collected for it yet. Check the Workflow and secret mappings card before treating it as a permissions issue. Open your GitHub App installations, confirm the organization, repository access, and permissions, then run Sync now again. Controls not affected by the missing access continue to refresh normally. If the installation was suspended or removed, Keldyn marks the connection Reauth required. Select Reconnect and complete the installation flow again.

Keeping evidence current

Keldyn refreshes access, authentication, change-management, testing, version-control, workflow-definition, run-history, run-artifact, and secret-rotation evidence daily. Dependabot, code-scanning alert, and code-scanning analysis-run evidence refreshes hourly. Evidence that hasn’t refreshed within its expected cadence is marked stale, and failed pulls are marked failed so you can spot gaps. You can also trigger an immediate refresh at any time with Sync now. Confirmed workflows are additionally judged against their own schedule, not Keldyn’s refresh cadence: a workflow you confirmed as a weekly scan fails its control if it hasn’t run in roughly two weeks, however recently Keldyn last synced.

GitHub deletes workflow run artifacts after 90 days, and ages out run history. Keldyn therefore accumulates run and artifact evidence rather than replacing it on each refresh, so a record captured while it was live stays available as evidence for an audit period longer than GitHub’s own retention window. This also means the evidence for these controls builds up over time — the first sync after connecting shows only what GitHub still holds.

Next steps

Evidence & audits

Learn how automated integration evidence works alongside manual evidence and audits.

Home

Getting started

Integrations

AI Tooling

Guides

Security & compliance

What it’s used for

Before you begin

Set up the integration

Confirm your workflow mappings

What data Keldyn collects and why

Permissions

Troubleshooting “Access required”

Keeping evidence current

Next steps

Evidence & audits

​What it’s used for

​Before you begin

​Set up the integration

​Confirm your workflow mappings

​What data Keldyn collects and why

​Permissions

​Troubleshooting “Access required”

​Keeping evidence current

​Next steps

Evidence & audits

What it’s used for

Before you begin

Set up the integration

Confirm your workflow mappings

What data Keldyn collects and why

Permissions

Troubleshooting “Access required”

Keeping evidence current

Next steps