Free GH-500 flashcards

Within GitHub Advanced Security, which product line owns code scanning with CodeQL?

Code Security. Code scanning with CodeQL is static application security testing of first-party source, looking for vulnerabilities such as injection flaws in your own code paths. That detection remit defines the Code Security product, keeping it separate from credential detection (Secret Protection) and dependency risk (Supply Chain Security).

On a public repository on GitHub Enterprise Cloud with no GitHub Advanced Security seats, which of code scanning, secret scanning with push protection, and Dependabot alerts can run?

All three. GitHub provides code scanning, secret scanning with push protection, and Dependabot alerts free of charge on public repositories to support open source, so no GitHub Advanced Security licence is needed. The paywall applies to private and internal repositories, not public ones.

Common misconceptionThat Advanced Security scanning always needs a paid licence. On public repositories code scanning and secret scanning run free, same as Dependabot.

How can an organisation owner make secret scanning turn on automatically for every repository created in future?

Apply a security configuration that enables secret scanning and set it to automatically apply to newly created repositories. A security configuration is a reusable named bundle of security feature settings, so each future repository inherits the enabled state without an administrator visiting it.

On GitHub.com, who pays for secret scanning on a public repository, and what does it detect?

Secret scanning is free for public repositories on GitHub.com, with no GitHub Advanced Security or Secret Protection licence required. It detects supported partner and provider credentials such as leaked cloud keys and can trigger partner notification. The paid Secret Protection entitlement only extends the same detection to private and internal repositories.

Common misconceptionThat secret scanning on a public repository needs a paid licence. It runs free automatically for public repos; a paid Secret Protection licence only covers private and internal ones.

What does the GitHub dependency graph need before it can resolve the full transitive dependency tree with pinned versions, beyond a manifest like package.json?

The dependency graph statically parses supported manifest and lock files. A manifest declares direct dependencies and version ranges only. The fully resolved transitive tree and exact pinned versions live in the committed lock file (such as package-lock.json), so without one the graph shows direct dependencies but cannot enumerate the pinned transitive set.

Where does Dependabot get the advisory data for its alerts, and how does it decide a repository is affected?

Dependabot matches curated advisories from the GitHub Advisory Database, which carry structured affected version ranges, against the package versions recorded in the repository's dependency graph. When a graph component falls inside an advisory's affected range, GitHub raises a Dependabot alert.

Common misconceptionThat Dependabot alerts come from CodeQL scanning your code for vulnerable calls. Alerts instead come from matching dependency versions against advisory data.

After a maintainer publishes a GitHub repository security advisory, what is the primary mechanism that alerts downstream consumers of the affected package?

Publishing reviews the advisory into the GitHub Advisory Database with the affected ecosystem and version ranges. Dependabot then matches those advisories against the resolved packages and versions in each repository's dependency graph, raising a Dependabot alert wherever a vulnerable version is in use.

In a GitHub Advisory Database entry, which identifier classifies the type of software weakness so you can hunt the same coding mistake elsewhere in your own code?

CWE (Common Weakness Enumeration) names the general class of weakness, such as improper input neutralisation or path traversal, that a specific flaw is an instance of. Because it abstracts the kind of mistake, engineers can search first-party code for recurrences of the same pattern. CVE names one specific disclosed vulnerability and CVSS rates severity, so neither classifies the weakness type.

Common misconceptionThat a CVE groups every vulnerability sharing a root cause across products. A CVE names one specific disclosed flaw; CWE is the weakness category.