Task 1.3: Detect, manage, and respond to security alerts

• ARotate the key with its provider, then close the alert as revoked

  Correct

  Secret scanning doesn't close an alert when the secret leaves the code, and the key in history stays usable until it is rotated.

• BLeave the alert open; the next scan of the default branch closes it automatically

  Incorrect

  Secret scanning doesn't close alerts when the token is removed; they are closed by hand.

• CRewrite the Git history to purge the key, which resolves the alert

  Incorrect

  Purging history is slow and doesn't close the alert, and the key stays valid until it is rotated.

• DClose the alert as a false positive

  Incorrect

  The key was real, so a false positive close misrecords it and leaves a live credential behind.

Secret scanning does not close an alert when the secret is removed from the repository; someone has to close it. Deleting the key from the latest commit leaves it in history and in every clone, so the credential must be revoked or rotated with its provider first. After that, closing the alert as revoked records what happened. Rewriting history is time-consuming and often unnecessary once the credential is revoked.

• ADependabot only sends notifications for alerts of critical severity

  Incorrect

  Notifications aren't limited by severity; new alerts of any severity can notify.

• BDependabot doesn't notify about what it finds when first enabled

  Correct

  Notifications go out for vulnerable dependencies identified after Dependabot is enabled.

• CDependabot alert emails are sent only after an owner turns on email for the organization

  Incorrect

  Email follows each user's own notification settings; there is no organization switch.

• DDependabot notifications go only to the people who have admin permission on the repository

  Incorrect

  By default, watchers with write, maintain or admin permission receive them.

Whatever the notification settings, GitHub doesn't notify about all the vulnerable dependencies it finds when Dependabot is first enabled; it notifies about new vulnerable dependencies identified afterwards. By default, notifications go to people with write, maintain or admin permission who watch the repository with security alerts or all activity selected.

• ATo the repository's Security and quality tab only

  Incorrect

  Partner alerts aren't shown in the repository.

• BTo the organization's audit log

  Incorrect

  Partner alerts aren't audit log entries.

• CDirectly to the service provider

  Correct

  Partner alerts are reported directly to the provider.

• DTo the commit author's email only

  Incorrect

  The partner alert goes to the provider.

Partner alerts are reported directly to secret providers that are part of the secret scanning partner program, so the provider can act, for example by revoking the credential. They aren't shown in the repository's Security and quality tab.

• AIn all branches of the repository

  Correct

  Dismissing an alert dismisses it in all branches.

• BOnly on the branch where it was dismissed

  Incorrect

  Dismissal isn't per branch.

• COnly in the pull request where it was found

  Incorrect

  Dismissal applies to the alert everywhere.

• DOnly until the next scan, when it reopens

  Incorrect

  The same code won't generate the alert again.

When you dismiss a code scanning alert, it is dismissed in all branches, removed from the count of current alerts and moved to the Closed list with the reason recorded. The same code won't generate the alert at the next scan.

• AAlerts that were fixed by merging a security update

  Incorrect

  Fixed alerts can't be reopened.

• BNeither; a closed alert is final

  Incorrect

  Dismissed alerts can be reopened.

• CBoth fixed and dismissed alerts

  Incorrect

  Only dismissed alerts can be reopened.

• DAlerts that were dismissed

  Correct

  Dismissed alerts can be reopened.

You can reopen alerts that were previously dismissed. Closed alerts that have already been fixed can't be reopened.

• AA security manager must close it as fixed

  Incorrect

  Nobody has to close a fixed code scanning alert by hand.

• BNothing; the next analysis that no longer finds it closes it

  Correct

  After you fix the code that triggered the alert, GitHub closes the alert.

• CThe developer must dismiss it as won't fix

  Incorrect

  Won't fix records a decision not to fix the problem; this code was fixed.

• DA repository administrator must re-run all earlier analyses of the branch

  Incorrect

  Only a new analysis matters: once it no longer finds the problem, the alert closes.

When you fix the code that triggered a code scanning alert, GitHub closes the alert once the analysis no longer finds the problem. Dismissing is for alerts you decide don't need fixing, and the reason is recorded.