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

CodeQL belongs to Secret Protection because it scans source files for sensitive strings before they are committed.

Wrong. Secret Protection covers secret scanning and push protection for credentials. CodeQL performs static analysis of code logic for vulnerabilities; it does not hunt for committed credentials, so it sits in Code Security, not Secret Protection.

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.

Secret scanning runs on a public repository only after the maintainer buys a Secret Protection or GitHub Advanced Security licence and assigns a seat.

A paid licence and seat are required only for private and internal repositories. Public repositories on GitHub.com receive secret scanning free of charge, so no purchase or seat assignment is needed for them.

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.

The dependency graph only reads lock files and ignores manifests, so a repository with no committed lock file has an empty dependency graph.

The graph does parse supported manifests such as package.json, which is why direct dependencies still appear without a lock file. A missing lock file only prevents resolving the exact pinned transitive versions; it does not leave the graph empty.

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.

A CVE identifier groups together every vulnerability sharing the same root cause across all affected products.

A CVE names one specific publicly disclosed vulnerability in a particular product, not a reusable category of weakness shared across products. The framework that groups flaws by shared root cause or type is CWE, not CVE.