Task 3.1: Understand and manage dependency and supply chain risks

• ADependabot creates alerts only for advisories with a critical CVSS score

  Incorrect

  Severity doesn't decide whether an alert is created.

• BDependabot doesn't create alerts for unreviewed advisories

  Correct

  Only GitHub-reviewed advisories trigger Dependabot alerts.

• CAdvisories from the NVD reach repositories only after the next weekly scheduled scan of the default branch

  Incorrect

  Alerts follow new reviewed advisories or graph changes; there is no weekly wait.

• DDependabot alerts need the repository's dependency graph to be exported as an SBOM first

  Incorrect

  The SBOM is an export; it isn't an input to alerts.

Unreviewed advisories are published automatically from the National Vulnerability Database feed. Dependabot doesn't create alerts for them, because they aren't checked for validity or completeness. When GitHub reviews an advisory and maps it to packages in supported ecosystems, Dependabot alerts affected repositories.

• AAdd the vulnerable library to the manifest as a direct dependency

  Incorrect

  That changes what the project depends on just to get an alert, and other indirect libraries stay uncovered.

• BTurn on Dependabot version updates for the manifest's directory

  Incorrect

  Version updates keep packages current; they don't add indirect dependencies to the graph.

• CExport an SBOM from the dependency graph, and upload it to each release as an asset

  Incorrect

  An SBOM export doesn't feed the graph or the alerts.

• DCommit a lock file that pins the exact indirect versions

  Correct

  Indirect dependencies inferred from manifests are excluded from vulnerability checks; lock files define them exactly.

Static analysis of the dependency graph finds indirect dependencies only if they are defined in a manifest or lock file. Indirect dependencies inferred from manifests rather than lock files are excluded from vulnerability checks, so lock files give the most reliable graph and Dependabot coverage. For ecosystems that resolve dependencies at build time, dependency submission is the other option.

• AAutomatic dependency submission runs a GitHub Actions workflow that counts toward Actions minutes

  Correct

  It resolves the tree in a workflow on GitHub-hosted runners by default.

• BDependabot graph jobs support every ecosystem the dependency graph supports

  Incorrect

  Graph jobs currently support Go and Python only.

• CStatic analysis of manifests already captures dependencies resolved at build time

  Incorrect

  Static analysis can't see dependencies resolved during the build.

• DAutomatic dependency submission can run only on self-hosted runners

  Incorrect

  It runs on GitHub-hosted runners by default; self-hosted or larger runners are optional.

• EFor Python, Dependabot graph jobs take precedence over automatic dependency submission

  Correct

  Once graph jobs are active, automatic submission no longer runs for that ecosystem.

Some ecosystems resolve indirect dependencies at build time. Automatic dependency submission runs a GitHub Actions workflow that builds the full tree and uploads it with the dependency submission API, using Actions minutes. Dependabot graph jobs do the same for Go and Python without Actions minutes, can use organization private registry configurations, and take precedence over automatic submission.

• ASecret scanning alerts

  Incorrect

  Secret scanning is about credentials.

• BThe repository's code scanning results for the default branch

  Incorrect

  Code scanning results aren't dependency data.

• CManifest and lock files, plus submitted dependencies

  Correct

  It summarizes manifests, lock files and submitted dependencies.

• DThe organization's audit log

  Incorrect

  The audit log records events.

The dependency graph is a summary of the manifest and lock files stored in a repository and any dependencies submitted for it with the dependency submission API.

• ACritical, high, medium and low

  Incorrect

  Those are severities.

• BDraft and published

  Incorrect

  Those are states of repository advisories.

• CPublic and private

  Incorrect

  Global advisories are public.

• DGitHub-reviewed, unreviewed and malware

  Correct

  Global advisories fall into these three categories.

Global advisories in the GitHub Advisory Database are grouped into GitHub-reviewed advisories, unreviewed advisories imported from the National Vulnerability Database, and malware advisories.

• APrivate repositories only

  Incorrect

  Dependents aren't reported for private repositories.

• BPublic repositories

  Correct

  Dependents are listed for public repositories.

• CAny repository with Dependabot alerts enabled

  Incorrect

  Alerts aren't the condition.

• DRepositories with an exported SBOM

  Incorrect

  SBOMs don't affect dependents.

For public repositories, the dependency graph lists dependents: other public repositories that depend on the repository or on packages it publishes. This information isn't reported for private repositories.

• AFrom the npm security team and OpenSSF

  Correct

  These are the documented sources.

• BFrom code scanning alerts

  Incorrect

  Code scanning doesn't publish advisories.

• CFrom Dependabot version updates

  Incorrect

  Version updates don't create advisories.

• DFrom private vulnerability reports sent to maintainers

  Incorrect

  Those become repository advisories.

Malware advisories cover malicious open source packages. GitHub publishes them automatically into the GitHub Advisory Database from the npm security team and the OpenSSF Malicious Packages repository; most are about substitution attacks.