GitHub Advanced Security common mistakes
GitHub Advanced Security · Understand the traps and how to avoid them.
Treating Dependabot alerts, Dependabot security updates, and Dependabot version updates as one feature, then answering questions about which one opens pull requests or which one requires a config file as if the settings were interchangeable.
The GitHub UI groups all three under a single 'Dependabot' settings area, and many candidates have only used one of them day to day, so they assume enabling alerts also remediates dependencies automatically.
What to do instead
Learn the three as separate mechanisms: alerts are notifications from the dependency graph with no remediation; security updates are automatic PRs for known vulnerable dependencies and are toggled per repository with no config file; version updates are scheduled PRs for routine upgrades and require a .github/dependabot.yml with package-ecosystem, directory, schedule, and optionally groups and ignore rules. Be able to state which artifact (alert, PR, config file) belongs to each.
Assuming every Dependabot alert produces an automatic fix PR, and failing to explain why some alerts stay open with no remediation available.
Candidates conflate 'alert exists' with 'patch exists', and forget that security updates only fire when a patched version is available in the registry and the manifest range permits the upgrade.
What to do instead
Memorize the conditions: an advisory must map to a patched version the ecosystem can resolve, the manifest/lockfile must be present and parseable, and security updates must be enabled (or the alert dismissed with a reason). Practice explaining cases where the fix requires a major-version bump outside the declared range, which Dependabot will not do without configuration changes.
Writing code scanning workflow questions around the wrong default: assuming CodeQL runs automatically on every repo or that a workflow file is always required, instead of knowing the difference between default setup and advanced setup.
Default setup is a UI toggle with no committed workflow, while advanced setup commits a codeql-analysis.yml; candidates who only used one mode mis-attribute scheduling, language matrix, and customization capabilities to the wrong mode.
What to do instead
Map capabilities to setup type: default setup covers supported languages with GitHub-managed configuration and no workflow file; advanced setup gives control over triggers, build steps, query packs, and paths via a committed workflow. Know that compiled languages and custom build commands generally require advanced setup, and that switching modes changes whether a workflow file exists in the repo.
Confusing secret scanning alerts with push protection, and answering as if enabling secret scanning automatically blocks pushes containing secrets.
Both live on the same settings page and both concern secrets, so candidates assume one toggle covers detection and prevention, and they miss that push protection is a distinct control with its own bypass flow.
What to do instead
Separate detection from prevention: secret scanning scans existing and new commits and raises alerts (with validity checks where supported); push protection blocks the push at the git layer before the secret lands, and bypasses are recorded and auditable. Be ready to explain custom patterns, who can bypass, and that push protection must be enabled separately for repositories and organizations.
Answering CodeQL query and analysis questions by guessing at query suite behavior, for example assuming the default suite catches all security queries or that a custom query pack replaces the standard suite automatically.
Query suites (default, security-extended, security-and-quality) and query packs are configuration details that candidates skim, and the naming suggests the default is comprehensive.
What to do instead
Know the three built-in suites and their tradeoffs: default is balanced for CI speed; security-extended adds lower-severity security queries at the cost of runtime and noise; security-and-quality adds maintainability queries. For custom packs, remember they are referenced explicitly in the workflow (packs/uses) and that adding a pack does not remove the default suite unless you configure queries to do so.
Treating code scanning alert dismissal and secret scanning alert dismissal as equivalent, including who can dismiss, required reasons, and whether dismissal comments or reopen flows exist.
The workflows look similar in the UI, but the permission models and available dismissal reasons differ, and candidates generalize from whichever one they used.
What to do instead
Study each dismissal model: code scanning dismissals require a reason (false positive, won't fix, used in tests) and write access, with comment support and reopen; secret scanning dismissal reasons include false positive, won't fix, and used in tests, and reopening is possible. Also note that dismissed alerts remain visible in filtered views and audit logs, which matters for compliance questions.
Misconfiguring or misreading CODEOWNERS and branch protection rulesets when asked how to enforce security review, for example placing CODEOWNERS in the repository root or assuming it blocks merges by itself.
CODEOWNERS is a text file with strict location precedence (.github/, root, docs/) and it only takes effect as a merge gate when combined with required review settings; candidates treat it as a standalone enforcement mechanism.
What to do instead
Remember that CODEOWNERS assigns reviewers and only blocks merges when branch protection or rulesets require code owner review. Know the accepted file locations and precedence, that later matching patterns win, and that rulesets (with bypass lists and target branches/tags) are the current mechanism alongside classic branch protection.
Answering organization-versus-repository scope questions incorrectly, such as assuming an organization-level setting automatically overrides repository settings or that repository admins can disable organization-mandated features.
GitHub Advanced Security is licensed and enabled at the organization level but configured per repository, and the inheritance direction differs by feature, so candidates apply a single mental model everywhere.
What to do instead
Build a scope table: GHAS licensing and policy (which repositories may enable features) are organization-level; enabling code scanning, secret scanning, and Dependabot is per repository, though organizations can enforce defaults and policies. Note that organization policies can restrict repository-level choices, and that enterprise-level settings sit above both.
Confusing security advisories, private vulnerability reporting, and the GitHub Advisory Database, for example stating that a repository security advisory is publicly visible immediately or that private vulnerability reporting requires a public issue.
These three features all involve vulnerability disclosure and share vocabulary, so candidates collapse them into one concept and get publication state and access control wrong.
What to do instead
Distinguish them clearly: the GitHub Advisory Database is GitHub's curated set of public advisories (including reviewed and unreviewed entries) that feeds Dependabot; repository security advisories are private drafts that maintainers publish and can request a CVE for; private vulnerability reporting gives external researchers a private channel to submit reports without opening public issues. Know the states (draft, published, closed) and who can see each.
Ignoring the security overview and audit-log questions, answering from memory about dashboards rather than knowing what the security overview filters, what risk signals it shows, and which events appear in the audit log.
These are visibility features that candidates rarely use hands-on, so they skip them and lose easy recall points on monitoring, alert trends, and evidence for compliance.
What to do instead
Learn the security overview at organization and enterprise level: it aggregates alert counts by repository, severity, and alert type, supports filtering by team and risk, and surfaces coverage gaps such as repositories without code scanning. Pair that with audit log knowledge (alert dismissals, secret scanning bypasses, policy changes) and remember that exports and API access exist for reporting.