Documentation

5.3 GitHub Source Code Sensor

The GitHub sensor discovers cryptographic material in source code repositories. This guide follows the structure described in 5.2. Values marked as environment-specific should be confirmed against the sensor version in use.

5.3.1 Overview and What Gets Scanned

The GitHub sensor scans repository source code for cryptographic usage, so that cryptography embedded in application code is inventoried alongside cryptography deployed on infrastructure. This closes the most common blind spot in a cryptographic inventory: an estate can be fully mapped at the infrastructure layer and still have no idea which applications call which algorithms.

What it finds:

Calls into cryptographic libraries, classified by category — symmetric and asymmetric encryption, key generation, key exchange, signing, hashing, message authentication, key derivation and randomness.
The algorithm in use at each call site, together with the parameters recovered from the code — key size, curve, cipher mode, padding, digest, iteration count, initialisation vector and nonce handling.
How each algorithm value was determined: a literal, a named constant, a field access, an expression, a propagated value, or unresolved. This matters for triage: an unresolved value is a finding that needs a human, not a false positive.
The library each call belongs to, and whether the evidence is direct usage, an implementation, or a heuristic match.
A severity and a confidence per finding.
Certificates, keys and keystore files committed into the repository.
A call graph and a per-file and per-project summary.

What it does not find:

Cryptography in compiled dependencies. The binary sensor covers that.
Cryptography in code paths that exist only in a branch not scanned.
Runtime configuration that selects an algorithm at execution time from a value not present in the code.

5.3.2 Prerequisites

Network access: outbound HTTPS from the executing component to the GitHub API endpoint, or to the enterprise GitHub instance.
Authentication: a personal access token or an app installation token. An app installation is preferable for an organisation-wide scan because its scope is explicit and it is not tied to an individual leaving the company.
Required access rights: read access to repository contents and metadata for every repository in scope. No write access is required and none should be granted.
Rate limit headroom: the API is rate limited per token. Scanning many repositories under one token will throttle, so budget the token or split the scope.
Execution: supported platform-executed and API-triggered. Remote execution is applicable where the repository is a local checkout rather than remote, in which case the local Git sensor is the better fit. Off-grid is not applicable for a remote repository.

5.3.3 Configuration Fields

Endpoint: the API base URL. Defaults to the public service; set it for an enterprise instance.
Credential: the token, stored encrypted and masked on read.
Organisation or owner: the scope root.
Repository selection: explicit list, pattern, or all repositories accessible to the credential. Prefer an explicit list or pattern for a first scan.
Branch or reference: which reference to scan. Defaults to the default branch. Scanning several branches multiplies the work and usually the findings duplicate.
Path include and exclude patterns: to skip vendored dependencies, test fixtures and generated code. Setting these is the difference between a scan that completes and one that does not.
File size limit: files above which content is not parsed.
Incremental: whether to scan only what changed since the last scan of the same scope.

5.3.4 Execution Modes

Platform execution: add the sensor to a template with the configuration above, create a task referencing that template, and run it from the portal. Results arrive in the inventory and in the Source Code Visualizer.
API execution - authenticate, create the template and task through the API, execute, and poll status. The endpoints are listed in the platform’s interactive API reference, published at /docs on the CBOM-Server host.
Scheduled execution: attach the task to a schedule for recurring coverage. With incremental enabled, a recurring scan is inexpensive.

5.3.5 Known Limitations

Rate limiting: a large organisation scan under a single token will be throttled and will take substantially longer than the sum of its parts.
Binary files in the repository are not parsed for source-level findings; committed key and certificate files are still detected as material.
Language coverage is per release. Check the supported language list for the release in use rather than assuming a static set.
Unresolved algorithm values are reported as such rather than guessed. This is correct behaviour and produces findings that require human triage.

5.3.6 Troubleshooting

Authentication failed: token invalid, expired, or revoked. Tokens with an expiry are the usual cause and the failure is abrupt.
Repository not found: the credential cannot see it. For a private repository this presents identically to a repository that does not exist, so verify the credential scope rather than the repository name.
Scan runs but returns no findings: check the path exclusions first. An over-broad exclusion pattern silently removes everything, and the scan reports success.
Scan never completes: scope. Restrict the repository selection or the path patterns, and enable incremental for subsequent runs.
Rate limit errors: reduce concurrency, split the scope across tokens, or schedule the scan outside other API consumers.

5.3.7 Getting Support

Collect: sensor version, platform version, the template and task configuration with the credential redacted, the target instance type and version, the repository count in scope, and the relevant log extract.
Redact the access token before sending anything.

CBOM Secure