Skip to main content

이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-07-09. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

비밀 검사에서 경고 관리

리포지토리에 체크 인된 비밀에 대한 경고를 보고 평가하고 해결할 수 있습니다.

누가 이 기능을 사용할 수 있는 있나요?

People with admin access to a repository can view and dismiss secret scanning alerts for the repository.

엔터프라이즈에 GitHub Advanced Security에 대한 라이선스가 있는 경우 GitHub Enterprise Server의 조직 소유 리포지토리의 베타에서 Secret scanning를 사용할 수 있습니다. 자세한 내용은 "비밀 검사 정보" 및 "GitHub Advanced Security 정보"을 참조하세요.

About the secret scanning alerts page

When you enable secret scanning for a repository or push commits to a repository with secret scanning enabled, GitHub scans the contents for secrets that match patterns defined by service providers and any custom patterns defined in your enterprise, organization, or repository.

When secret scanning detects a secret, GitHub generates an alert. GitHub displays an alert in the Security tab of the repository.

Viewing alerts

  1. On your GitHub Enterprise Server instance, navigate to the main page of the repository.
  2. Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
    Screenshot of a repository header showing the tabs. The "Security" tab is highlighted by a dark orange outline.
  3. In the left sidebar, under "Vulnerability alerts", click Secret scanning.
  4. Under "Secret scanning", click the alert you want to view.

Filtering alerts

You can apply various filters to the alerts list to help you find the alerts you're interested in. You can use the dropdown menus above the alerts list, or input the qualifiers listed in the table into the search bar.

QualifierDescription
is:openDisplays open alerts.
is:closedDisplays closed alerts.
validity:activeDisplays alerts for secrets that are still active. For more information about validity statuses, see "Checking a secret's validity."
validity:inactiveDisplays alerts for secrets that are no longer active.
validity:unknownDisplays alerts for secrets where the validity status of the secret is unknown.
secret-type:SECRET-NAMEDisplays alerts for a specific secret type, for example, secret-type:github_personal_access_token. For a list of supported secret types, see "Secret scanning patterns."
provider:PROVIDER-NAMEDisplays alerts for a specific provider, for example, provider:github. For a list of supported partners, see "Secret scanning patterns."

Evaluating alerts

You can check the validity of a secret, to see if the secret is still active. Applies to GitHub tokens only. For more information, see "Checking a secret's validity."

Checking a secret's validity

Validity checks help you prioritize alerts by telling you which secrets are active or inactive. An active secret is one that could still be exploited, so these alerts should be reviewed and remediated as a priority.

By default, GitHub checks the validity of GitHub tokens and displays the validitation status of the token in the alert view.

ValidityStatusResult
Active secretactiveGitHub checked with this secret's provider and found that the secret is active
Possibly active secretunknownGitHub does not support validation checks for this token type yet
Possibly active secretunknownGitHub could not verify this secret
Secret inactiveinactiveYou should make sure no unauthorized access has already occurred

You can use the REST API to retrieve a list of the most recent validation status for each of your tokens. For more information, see "REST API endpoints for secret scanning" in the REST API documentation. You can also use webhooks to be notified of activity relating to a secret scanning alert. For more information, see the secret_scanning_alert event in "Webhook events and payloads."

Fixing alerts

Once a secret has been committed to a repository, you should consider the secret compromised. GitHub recommends the following actions for compromised secrets:

  • For a compromised GitHub personal access token, delete the compromised token, create a new token, and update any services that use the old token. For more information, see "Managing your personal access tokens."
  • For all other secrets, first verify that the secret committed to GitHub Enterprise Server is valid. If so, create a new secret, update any services that use the old secret, and then delete the old secret.

Closing alerts

Note

Secret scanning doesn't automatically close alerts when the corresponding token has been removed from the repository. You must manually close these alerts in the alert list on GitHub.

  1. On your GitHub Enterprise Server instance, navigate to the main page of the repository.

  2. Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.

    Screenshot of a repository header showing the tabs. The "Security" tab is highlighted by a dark orange outline.

  3. In the left sidebar, under "Vulnerability alerts", click Secret scanning.

  4. Under "Secret scanning", click the alert you want to view.

  5. To dismiss an alert, select the "Close as" dropdown menu and click a reason for resolving an alert.

    Screenshot of a secret scanning alert. A dropdown menu, titled "Close as", is expanded and highlighted in a dark orange outline.

  6. Optionally, in the "Comment" field, add a dismissal comment. The dismissal comment will be added to the alert timeline and can be used as justification during auditing and reporting. You can view the history of all dismissed alerts and dismissal comments in the alert timeline. You can also retrieve or set a comment by using the Secret scanning API. The comment is contained in the resolution_comment field. For more information, see "REST API endpoints for secret scanning" in the REST API documentation.

  7. Click Close alert.

Configuring notifications for secret scanning alerts

Notifications are different for incremental scans and historical scans.

Incremental scans

When a new secret is detected, GitHub Enterprise Server notifies all users with access to security alerts for the repository according to their notification preferences. These users include:

  • Repository administrators
  • Security managers
  • Users with custom roles with read/write access
  • Organization owners and enterprise owners, if they are administrators of repositories where secrets were leaked

Note

Commit authors who've accidentally committed secrets will be notified, regardless of their notification preferences.

You will receive an email notification if:

  • You are watching the repository.
  • You have enabled notifications for "All Activity", or for custom "Security alerts" on the repository.
  • In your notification settings, under "Subscriptions", then under "Watching", you have selected to receive notifications by email.
  1. On your GitHub Enterprise Server instance, navigate to the main page of the repository.

  2. To start watching the repository, select Watch.

    Screenshot of the repository's main page. A dropdown menu, titled "Watch", is highlighted with an orange outline.

  3. In the dropdown menu, click All Activity. Alternatively, to only subscribe to security alerts, click Custom, then click Security alerts.

  4. Navigate to the notification settings for your personal account. These are available at https://github.com/settings/notifications.

  5. On your notification settings page, under "Subscriptions", then under "Watching", select the Notify me dropdown.

  6. Select "Email" as a notification option, then click Save.

    Screenshot of the notification settings for a user account. An element header, titled "Subscriptions", and a sub-header, titled "Watching", are shown. A checkbox, titled "Email", is highlighted with an orange outline.

For more information about setting up notification preferences, see "Managing security and analysis settings for your repository" and "Configuring your watch settings for an individual repository."

Historical scans

For historical scans, GitHub Enterprise Server notifies the following users:

  • Organization owners, enterprise owners, and security managers—whenever a historical scan is complete, even if no secrets are found.
  • Repository administrators, security managers, and users with custom roles with read/write access—whenever a historical scan detects a secret, and according to their notification preferences.

We do not notify commit authors.

For more information about setting up notification preferences, see "Managing security and analysis settings for your repository" and "Configuring your watch settings for an individual repository."

Auditing responses to secret scanning alerts

You can audit the actions taken in response to secret scanning alerts using GitHub tools. For more information, see "Auditing security alerts."