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

Software Composition Analysis (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 Server 3.0 or later

Prerequisites and User Permissions

Before you begin configuring the connector, make sure to:

  1. 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.

  2. 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.

  3. 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.

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

  2. Click Generate new token.

  3. Type a descriptive name for the token and set an expiry date.

  4. Select the following scopes:

    • repo

    • read:org

  5. Click Generate token.

  6. 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 Server URL text box, type your GitHub API URL. For GitHub.com, use https://api.github.com. For GitHub Enterprise Server, type the URL of your instance.

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

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

  6. 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 checkbox to fetch repositories owned by the token user that do not belong to an organization.

    • Select the Pull 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 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.

  7. 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.

  8. 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.

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

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

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:

  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 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

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

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).

API

Use in Tenable Exposure Management

Permissions required

POST {server_url}/graphql — viewer.repositories

Fetches personal repositories as code repository assets.

repo

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

Fetches organization repositories as code repository assets.

repo

read:org

POST {server_url}/graphql — repository.vulnerabilityAlerts

Fetches Dependabot vulnerability alerts for personal repositories.

repo

POST {server_url}/graphql — viewer.organization.repository.vulnerabilityAlerts

Fetches Dependabot vulnerability alerts for organization repositories.

repo

read:org

POST {server_url}/graphql — repository.refs

Fetches release tags to enrich asset labels.

repo

GET {server_url}/advisories/{ghsa_id}

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

repo

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

Fetches custom properties to map as asset tags.

repo

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.

  • Personal repositories that belong to an organization are not counted twice.

  • 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:

  1. In the repository, go to Security > Dependabot 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 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.