GitHub Dependabot Connector

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

GitHub Dependabot detects insecure dependencies in your repositories and generates alerts with remediation guidance for the affected packages.

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 dependency vulnerability findings (Software Composition Analysis) through the GitHub GraphQL and REST APIs.

Details	Description
Supported products	GitHub.com (Cloud) GitHub Enterprise Server Dependabot alerts must be enabled on the repositories that you want to scan.
Category	SCA
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 Cloud with data residency (ghe.com) GitHub Enterprise Server 3.0 or later Fine-grained personal access tokens require GitHub Enterprise Server 3.17 or later.

Prerequisites and User Permissions

Before you begin configuring the connector, make sure to:

Enable Dependabot alerts on each repository that you want to scan, in Settings > Code security and analysis > Dependabot alerts. Repositories without Dependabot alerts enabled return no findings.
Confirm that the token owner has at least read access to the repositories. For organization repositories, the token owner must be a member of the organization.
If you want to use a fine-grained personal access token, confirm that your organization allows fine-grained personal access tokens. Organization owners can disable them or require approval for each token.
Generate a GitHub personal access token.

Generate a GitHub personal access token

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

In GitHub, go to Settings > Developer settings > Personal access tokens > Tokens (classic).
Click Generate new token.
Type a descriptive name for the token and set an expiry date.
Select the following scopes:
- repo
- read:org
Click Generate token.
Copy the token value to a safe location. GitHub shows the token only once, and you need it to configure the connector.

Generate a fine-grained personal access token

As an alternative to a classic personal access token, you can use a fine-grained personal access token. When you configure the connector, type the token in the API Token text box and select Fine-Grained PAT from the Token Type drop-down.

Note: A fine-grained personal access token is limited to one resource owner, and the resource owner must be an organization. Tokens that a user account owns are not supported. If you want to sync several organizations, you need one token, and therefore one connector, for each organization.

In GitHub, go to Settings > Developer settings > Personal access tokens > Fine-grained tokens.
Click Generate new token.
Type a descriptive name for the token, set an expiry date, and select your organization as the resource owner.
Select the repositories that you want the connector to access.
Add the following permissions:
- Organization permissions > Members: Read (required)
- Repository permissions > Contents: Read (required)
- Repository permissions > Dependabot alerts: Read (optional)
If you omit an optional permission, the connector skips the affected repositories and reports a warning. GitHub applies the Metadata permission implicitly, so custom properties need no explicit permission.
Click Generate token.
Copy the token value to a safe location. GitHub shows the token only once, and you need it to configure the connector.
Ask an organization owner to approve the token for your organization. If you are an organization owner, you can approve the request yourself. Until the token is approved, the connector cannot discover the organization.

The connector can call every endpoint that it uses with a fine-grained personal access token. The following behavior differs from a classic personal access token:

The viewer.organizations query returns only the organizations that approved the token.
The connector skips repositories that are outside the scope of the token.
The connector reports permission denials, such as a 403 error or a GraphQL FORBIDDEN error, as one aggregated warning for each sync step.

Add a Connector

To add a new connector:

In the left navigation menu, click Connectors.

The Connectors page appears.
In the upper-right corner, click Add new connector.

The Connector Library page appears.
In the search box, type the name of the connector.
On the tile for the connector, click Connect.

The connector configuration options appear.

Configure the Connector

To configure the connector:

(Optional) In the Connector's Name text box, type a descriptive name for the connector.
(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.
In the Full API URL text box, type the API URL of your GitHub instance. The default is https://api.github.com. For GitHub Enterprise Cloud with data residency, type your ghe.com API URL. For example, https://api.acme.ghe.com.
In the API Token text box, type the personal access token that you generated in GitHub.
From the Token Type drop-down, select the type of token that you generated: Classic PAT or Fine-Grained PAT. The default is Classic PAT.
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 Pull personal repositories from Github for Dependabot checkbox to fetch repositories owned by the token user that do not belong to an organization.
- Under Organizations, select the Fetch all organizations checkbox to sync all organizations. Otherwise, from the Organizations drop-down, select one or more organizations to sync.
  
  If you use a fine-grained personal access token, the Organizations options do not appear. The connector syncs the organizations that approved the token.
- Select the Pull Github release tags checkbox to fetch git release tags and add them as labels on your assets.
- Select the Map GitHub custom properties as asset external tags in TenableOne 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.
If you use a fine-grained personal access token, the feature checkboxes do not appear. The connector runs every feature step, and the permissions of the token decide what the connector fetches. The connector skips repositories that the token cannot access and reports a warning in the sync log.
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.
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.
Click Create. Tenable Exposure Management begins syncing the connector. The sync can take some time to complete.
To confirm the sync is complete, do the following:
- Navigate to the Connectors page and monitor the connector's status. Sync is complete once the connector status is Connected.
- View the sync logs for the connector to monitor the logs for a successful connection.

GitHub Dependabot 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:

In Tenable Exposure Management, navigate to the Assets page.
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.
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:

In Tenable Exposure Management, navigate to the Findings page.
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.
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 Dependabot 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 repository topics release tag names custom properties (property:value)
Created Date	node.createdAt
First Seen	node.createdAt
Last Seen	node.updatedAt

Finding Mapping

Tenable Exposure Management UI Field	GitHub Dependabot Field
Advisory ID	node.securityVulnerability.advisory.ghsaId
Vendor ID	node.id
Finding Type	SOURCE_CODE
Finding Category	SCA
Finding Name	node.securityVulnerability.advisory.summary
Description	node.securityVulnerability.advisory.description
CVEs	advisory.identifiers (CVE)
CWEs	advisory.cwes.edges[].node.cweId
Advisory IDs	advisory.identifiers (GHSA)
Severity	node.securityVulnerability.severity
CVSS v3 Score	advisory.cvss.score
CVSS v3 Vector	advisory.cvss.vectorString
CVSS v4 Score	cvss_severities.cvss_v4.score
CVSS v4 Vector	cvss_severities.cvss_v4.vector_string
Solution	advisory upgrade guidance
Package Name	node.securityVulnerability.package.name
Package Version	node.vulnerableRequirements
Published Date	node.securityVulnerability.updatedAt
First Seen	node.createdAt
Last Fixed At	node.fixedAt node.dismissedAt
State	node.state
Finding Custom Attributes	dismiss_reason state

Finding Status Mapping

Tenable Exposure Management Status	GitHub Dependabot Status
Active	open
Fixed	fixed dismissed auto_dismissed

Tenable Exposure Management Status

GitHub Dependabot Status

Active

open

Fixed

fixed

dismissed

auto_dismissed

Finding Severity Mapping

Tenable Exposure Management Severity	GitHub Dependabot Severity
Critical	CRITICAL
High	HIGH
Medium	MODERATE
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	Asset not seen for X days according to "Last Seen". See Asset Retention
Change a Finding status from "Active" to "Fixed"	The alert state changes to fixed, dismissed, or auto_dismissed 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	node.securityVulnerability.advisory.summary + node.securityVulnerability.advisory.description (uniquely identifies the advisory)
Finding	node.node.securityVulnerability.package.name + node.vulnerableRequirements(uniquely identifies an alert instance on a repository)

API Endpoints in Use

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

For a fine-grained personal access token, the Permissions required column also lists the equivalent permissions that you add in GitHub.

API	Use in Tenable Exposure Management	Permissions required
`POST {server_url}/graphql` — `viewer.repositories`	Fetches personal repositories as code repository assets.	repo Contents: Read (fine-grained)
`POST {server_url}/graphql` — `viewer.organization.repositories`	Fetches organization repositories as code repository assets.	repo read:org Contents: Read (fine-grained) Members: Read (fine-grained)
`POST {server_url}/graphql` — `repository.vulnerabilityAlerts`	Fetches Dependabot vulnerability alerts for personal repositories.	repo Dependabot alerts: Read (fine-grained)
`POST {server_url}/graphql` — `viewer.organization.repository.vulnerabilityAlerts`	Fetches Dependabot vulnerability alerts for organization repositories.	repo read:org Dependabot alerts: Read (fine-grained)
`POST {server_url}/graphql` — `repository.refs`	Fetches release tags to enrich asset labels.	repo Contents: Read (fine-grained)
`GET {server_url}/advisories/{ghsa_id}`	Enriches findings with CVSS v3 and v4 scores from GitHub Security Advisories.	repo Fine-grained: no permission needed (public endpoint)
`GET {server_url}/repos/{owner}/{repo}/properties/values`	Fetches custom properties to map as asset tags.	repo read:org Fine-grained: no explicit permission (GitHub applies Metadata implicitly)

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:

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:

Locate your connector assets, filtered by Source = github.
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.
Personal repositories and organization repositories are fetched separately. An organization repository is not counted as a personal repository.
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 Dependabot alerts in GitHub aligns with the number of findings in Tenable Exposure Management.

In GitHub:

In the repository, go to Security > Dependabot alerts.

Note the number of open alerts.

In Tenable Exposure Management:

Locate your connector findings, filtered by Source = github and State = Active.
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 Dependabot enabled or by alerts in the dismissed state, which map to an inactive state.

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

Dependabot alerts are enabled on the repository.
The alert appears on the repository's Security tab.
The alert is in the open state, not dismissed or fixed.
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.