GitHub Code Scanning Connector

The following is not supported in Tenable FedRAMP Moderate environments. For more information, see the Tenable FedRAMP Product Offering.

GitHub Code Scanning detects security vulnerabilities and coding errors in your repositories using static analysis (primarily CodeQL), and Secret Scanning detects exposed credentials.

The following steps allow you to configure this connector for use with Tenable Exposure Management from start to finish.

Tip: For more information on how third-party integrations work, see Connectors.

Connector Details

Tenable Exposure Management ingests GitHub code repository assets and SAST vulnerability findings (Code Scanning and Secret Scanning) through the GitHub REST and GraphQL APIs.

Details Description

Supported products

GitHub.com (Cloud)

GitHub Enterprise Server

Code Scanning (GitHub Advanced Security) and Secret Scanning must be enabled on the repositories.

Category

Static Application Security Testing (SAST)
Ingested data Assets and Findings

Ingested Asset Classes

Code Repository

Integration type

UNI directional (data is transferred from the connector to Tenable Exposure Management in one direction)

Supported version and type

GitHub.com (latest)

GitHub Enterprise Server 3.0 or later for Code Scanning; 3.1 or later for Secret Scanning

Prerequisites and User Permissions

Before you begin configuring the connector, make sure to:

  1. Enable GitHub Advanced Security and Code Scanning on each repository that you want to scan. Repositories without Code Scanning enabled return no code scanning findings.

  2. To ingest Secret Scanning alerts, confirm that the token owner is an organization owner or has the Security Manager role. The token owner must be a member of the organization; external collaborators are not supported.

  3. Generate a GitHub personal access token.

Generate a GitHub personal access token

Generate a classic personal access token with, at minimum, the repo, read:org, and security_events scopes.

  1. In GitHub, go to Settings > Developer settings > Personal access tokens > Tokens (classic).

  2. Click Generate new token (classic).

  3. Type a descriptive name for the token, for example, Tenable Code Scanning.

  4. Set an expiry date.

  5. Select the following scopes:

    • repo

    • read:org

    • security_events

  6. Click Generate token.

  7. Copy the token value to a safe location. GitHub shows the token only once, and you need it to configure the connector.

Add a Connector

To add a new connector:

  1. In the left navigation menu, click Connectors.

    The Connectors page appears.

  2. In the upper-right corner, click Add new connector.

    The Connector Library page appears.

  3. In the search box, type the name of the connector.

  4. On the tile for the connector, click Connect.

    The connector configuration options appear.

Configure the Connector

To configure the connector:

  1. (Optional) In the Connector's Name text box, type a descriptive name for the connector.

  2. (Optional) To use a preconfigured on-prem connector to connect to this connector, from the Gateway drop-down, select the on-prem connector you want to use for the connector. Otherwise, select Don't use gateway.

    Note: For information about configuring a gateway, see Tenable On-Prem Connector.

  3. In the API Token text box, type the personal access token that you generated in GitHub.

  4. From the Organizations drop-down, select one or more organizations to sync.

  5. Data pulling configuration: This configuration has dynamic settings tailored to the specific connector and integration type. Below are the configurations relevant to this connector.

    • Select the Fetch personal repositories checkbox to fetch repositories owned by the token user that do not belong to an organization.

    • Select the Fetch Code Scanning checkbox to fetch Code Scanning (SAST) alerts for all repositories.

    • Select the Fetch Secret Scanning checkbox to fetch Secret Scanning alerts for all repositories.

    • Select the Include Warning and Note severity checkbox to include Warning and Note severity findings from Code Scanning in addition to Error-level findings.

    • Select the Map GitHub custom properties as asset external tags in Tenable Exposure Management checkbox to fetch GitHub custom properties and map them as asset tags.

    • In the Asset Retention text box, type the number of days after which you want assets to be removed from Tenable Exposure Management. If an asset has not been detected or updated within the specified number of days, it is automatically removed from the application, ensuring your asset inventory is current and relevant.

      Tip: For more information, see Asset Retention.

  6. In the Test connectivity section, click the Test Connectivity button to verify that Tenable Exposure Management can connect to your connector instance.

    • A successful connectivity test confirms that the platform can connect to the connector instance. It does not, however, guarantee that the synchronization process will succeed, as additional syncing or processing issues may arise.

    • If the connectivity test fails, an error message with details about the issue appears. Click Show tests for more information about the exact error.

  7. In the Connector scheduling section, configure the time and day(s) on which you want connector syncs to occur.

    Tip: For more information, see Connector Scheduling.

  8. Click Create. Tenable Exposure Management begins syncing the connector. The sync can take some time to complete.

  9. To confirm the sync is complete, do the following:

GitHub Code Scanning in Tenable Exposure Management

Locate Connector Assets in Tenable Exposure Management

As the connector discovers assets, Tenable Exposure Management ingests those devices for reporting.

To view assets by connector:

  1. In Tenable Exposure Management, navigate to the Assets page.

  2. In the Filters section, under 3rd Party Connectors, click the connector name for which you want to view assets.

    The asset list updates to show only assets from the selected connector.

  3. Click on any asset to view Asset Details.

Locate Connector Findings in Tenable Exposure Management

As the connector discovers individual findings, Tenable Exposure Management ingests those findings for reporting.

To view findings by connector:

  1. In Tenable Exposure Management, navigate to the Findings page.

  2. In the Filters section, under 3rd Party Connectors, click the connector name for which you want to view findings.

    The findings list updates to show only assets from the selected connector.

  3. Click on any asset to view Finding Details.

Data Mapping

Tenable Exposure Management integrates with the connector via API to retrieve relevant weakness and asset data, which is then mapped into the Tenable Exposure Management system. The following tables outline how fields and their values are mapped from the connector to Tenable Exposure Management.

Code Repository Mapping

Tenable Exposure Management UI Field

GitHub Code Scanning Field
Asset Id node.id
Asset Class CODE_REPOSITORY
Source github
Asset Name node.name
Code Repository URL node.url
Visibility node.isPrivate
Asset Status node.isArchived
Languages node.languages.nodes[].name
External Tags

organization name (if the repository belongs to an organization) or "Private Repository"

repository name

languages

GitHub topics

release tag names

custom properties (property:value)
Created Date node.createdAt
Last Commit Date node.pushedAt
First Seen node.createdAt
Last Seen node.updatedAt

Finding Mapping

Tenable Exposure Management UI Field

GitHub Code Scanning Field
Finding ID

rule.description (code scanning)

secret_display (secret scanning)
Vendor ID alert_number
Finding Type SOURCE_CODE
Finding Category SAST
Finding Name

rule.description (code scanning)

secret_display (secret scanning)
Description

rule.full_description (code scanning)

"Possibly active secret" (secret scanning)
CVEs rule.tags (/cve/)
CWEs rule.tags (/cwe/)
Severity rule.security_severity_level
CVSS v3 Score cvss_severities.cvss_v3.score
CVSS v3 Vector cvss_severities.cvss_v3.vector_string
CVSS v4 Score cvss_severities.cvss_v4.score
CVSS v4 Vector cvss_severities.cvss_v4.vector_string
Solution rule.help
File Path most_recent_instance.location.path
Line Number most_recent_instance.location.start_line
Branch most_recent_instance.ref
Origin Finding URL html_url
Published Date created_at
First Seen created_at
Last Seen updated_at
Last Fixed At

fixed_at

updated_at
State state
Finding Custom Attributes

scan_type

category

dismiss_reason

state

tool_name

Finding Status Mapping

Tenable Exposure Management Status

GitHub Code Scanning Status

Active

open

Fixed

fixed

resolved

dismissed

closed

Finding Severity Mapping

Tenable Exposure Management Severity

GitHub Code Scanning Severity

Critical

critical

High

high

Medium

medium

Low

low

None

Other or empty

Status Update Mechanisms

Every day, Tenable Exposure Management syncs with the vendor's platform to receive updates on existing findings and assets and to retrieve new ones (if any were added).

The table below describes how the status update mechanism works in the connector for findings and assets ingested into Tenable Exposure Management.

Update Type in Tenable Exposure Management

Mechanism (When?)

Archiving Assets

Change a Finding status from "Active" to "Fixed"

  • The alert state changes to fixed, resolved, dismissed, or closed on the vendor's side.
Note: Updates on the vendor side are reflected in Tenable Exposure Management only when the next scheduled connector sync time is complete (once a day).

Uniqueness Criteria

Tenable Exposure Management uses defined uniqueness criteria to determine whether an ingested asset or finding should be recognized as a distinct record. These criteria help define how assets and findings are identified and counted from each connector.

Tip: To learn more about data deduplication and uniqueness criteria, See Third-Party Data Deduplication in Tenable Exposure Management.

The uniqueness criteria for this connector are as follows:

Data

Uniqueness Criteria

Asset

node.id

Vulnerability

rule.description (code scanning)

secret_display (secret scanning)
Finding alert_number (uniquely identifies an alert instance on a repository)

API Endpoints in Use

API version: REST (GitHub API v3) and GraphQL (GitHub API v4).

API

Use in Tenable Exposure Management

Permissions required

POST {server_url}/graphql — viewer.organization.repositories

Fetches organization repositories as code repository assets.

repo

read:org

POST {server_url}/graphql — viewer.repositories

Fetches personal repositories as code repository assets.

repo

POST {server_url}/graphql — repository.refs

Fetches release tags to enrich asset labels.

repo

GET {server_url}/repos/{owner}/{repo}/properties/values

Fetches custom properties to map as asset tags.

repo

read:org

GET {server_url}/repos/{owner}/{repo}/code-scanning/alerts

Fetches Code Scanning alerts (SAST findings) for repositories.

repo

security_events

GET {server_url}/repos/{owner}/{repo}/code-scanning/alerts/{alert_number}

Fetches full alert detail, including remediation guidance, for Code Scanning findings.

repo

security_events

GET {server_url}/repos/{owner}/{repo}/secret-scanning/alerts

Fetches Secret Scanning alerts for repositories.

repo

security_events

GET {server_url}/repos/{owner}/{repo}/secret-scanning/alerts/{alert_number}/locations

Fetches per-location detail (file path, line, and commit) for Secret Scanning alerts.

repo

security_events

GET {server_url}/advisories?cve_id={cve_id}

Enriches findings with CVSS v3 and v4 scores from GitHub Security Advisories.

repo

POST {server_url}/graphql — viewer.organizations

Populates the organization multi-select in the connector configuration.

read:org

Data Validation

This section shows how to validate and compare data between Tenable Exposure Management and GitHub.

Asset Data Validation

Objective: Ensure the number of repositories visible to the token in GitHub aligns with the number of code repository assets displayed in Tenable Exposure Management.

In GitHub:

  1. Review the personal repositories and the repositories in each selected organization that the token can access.

    Note the number of repositories.

In Tenable Exposure Management:

  1. Locate your connector assets, filtered by Source = github.

  2. Compare the total number of assets between GitHub and Tenable Exposure Management.

Expected outcome: The total numbers returned in GitHub and Tenable Exposure Management should match. Archived repositories are included and have the ARCHIVED status.

If an asset is not visible in Tenable Exposure Management, check the following conditions:

  • The token has read access to the repository.

  • For organization repositories, the token owner is a member of the organization.

  • The Fetch personal repositories checkbox is selected if you expect personal repositories.

  • The asset was archived because it was not seen within the asset retention period.

    Tip: To learn more on how assets are archived and findings change status, see Status Update Mechanisms.

Finding Data Validation

Objective: Ensure the number of Code Scanning and Secret Scanning alerts in GitHub aligns with the number of findings in Tenable Exposure Management.

In GitHub:

  1. In the repository, go to Security > Code scanning alerts. For secret findings, go to Security > Secret scanning alerts.

    Note the number of open alerts.

In Tenable Exposure Management:

  1. Locate your connector findings, filtered by Source = github and State = Active.

  2. Compare the total number of findings between GitHub and Tenable Exposure Management.

Expected outcome: The total numbers returned in GitHub and Tenable Exposure Management should match. Differences are usually caused by repositories without Code Scanning or Secret Scanning enabled, by the Include Warning and Note severity checkbox filtering out lower-severity findings, or by alerts in a dismissed state that map to an inactive state.

If a finding is missing from Tenable Exposure Management or no longer active, check the following conditions:

  • Code Scanning or Secret Scanning is enabled on the repository.

  • The alert appears on the repository's Security tab.

  • The alert is in the open state, not dismissed, fixed, or closed.

  • For Code Scanning, the Include Warning and Note severity checkbox is selected if the finding is a Warning or Note.

  • For Secret Scanning, the token owner is an organization owner or has the Security Manager role.

  • The finding is marked as Fixed and appears under the Fixed state on the Findings screen.

    Tip: To learn more on how assets are archived and findings change status, see Status Update Mechanisms.