For GitHub Advanced Security, do not recite menus. Trace pull request -> CodeQL analysis -> secret scanning -> dependency review -> alert triage -> fix PR, prove it with security alert with commit, path, rule, status, dismissal reason or merged fix PR, then explain the production-safe fix.
Fundamentals and interview framing (5)
Define the platform, scope and mental model clearly.
L11. How would you explain GitHub Advanced Security in an AppSec interview?
Direct answer: GitHub Advanced Security brings code scanning, secret scanning and dependency review into the developer workflow so issues can be found, owned and fixed in pull requests.
Why it matters in production: It moves security evidence closer to the code owner instead of waiting for a late external scan.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: A weak answer calls it only a scanner and misses PR workflow and ownership.
Strong answer framing: Explain the PR path: CodeQL, secrets, dependency review, alert triage and fix evidence.
L12. Which GHAS evidence objects should you mention first?
Direct answer: Mention CodeQL alerts, secret scanning alerts, dependency review comments, security overview, branch protection checks and fix PRs.
Why it matters in production: Those objects show what was found, where it lives, who owns it and whether the merge was blocked or fixed.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Listing product features without alert evidence sounds shallow.
Strong answer framing: Name each alert type and the field that proves status, owner or fix.
L23. How is GHAS different from running a standalone SAST tool once a month?
Direct answer: GHAS is embedded in repositories and pull requests, while a monthly scan is usually external, delayed and disconnected from developer merge decisions.
Why it matters in production: Developers fix faster when the evidence appears in the PR and can be tied to branch policy.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Do not claim GHAS replaces all manual AppSec review.
Strong answer framing: Frame it as continuous code-security signal plus human triage for risk and context.
L24. What is the one-minute GHAS architecture flow?
Direct answer: Draw repository, pull request, GitHub Actions workflow, CodeQL database, secret scanning detector, dependency review and security alert triage.
Why it matters in production: The interviewer wants to hear how the signal is produced and where the developer sees it.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: A weak diagram says 'scan code' with no PR gate or alert lifecycle.
Strong answer framing: End with the fix PR or documented dismissal reason.
L35. What is the senior interview answer for GHAS?
Direct answer: A senior answer explains how code, secret and dependency findings enter PR workflow, how owners triage them, and how policy proves fix or accepted risk.
Why it matters in production: It shows you can run AppSec as an engineering workflow, not just scan code.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Tool-name dropping without merge and evidence details is weak.
Strong answer framing: Close with one alert example from finding to owner, fix PR, workflow rerun and status closure.
Architecture, components and evidence flow (5)
Name objects and trace one alert, request, secret or data event end to end.
L26. How does CodeQL find a vulnerability?
Direct answer: CodeQL builds a database from code, runs semantic queries and raises code scanning alerts with rule, location, data flow and severity context.
Why it matters in production: This matters because the alert is more than a regex match; it can reason about paths through code.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Do not overstate it as perfect proof of exploitability.
Strong answer framing: Say CodeQL finds candidates, then AppSec validates reachability, context and remediation.
L27. How should secret scanning be handled after a token leak?
Direct answer: Treat it as credential incident response: identify the secret, revoke it, rotate replacement, check exposure, update storage and close the alert with evidence.
Why it matters in production: Removing the string from code is not enough if the token is still valid.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: The common trap is marking the alert fixed after a commit only.
Strong answer framing: Mention revocation proof, history review and prevention controls.
L28. Where does dependency review fit in the PR process?
Direct answer: Dependency review checks package changes in a pull request and highlights vulnerable or risky dependencies before merge.
Why it matters in production: It helps stop supply-chain risk before it reaches the default branch.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Do not treat it as the same thing as a full SBOM program.
Strong answer framing: Use it as a PR gate and connect it to package owner remediation.
L39. How would you integrate GHAS into a wider DevSecOps workflow?
Direct answer: Feed GHAS alerts into developer ownership, ticketing, security overview, branch protection and exception governance.
Why it matters in production: The signal only creates value when developers know whether to fix, accept or escalate.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Exporting alerts to every tool without ownership creates duplicate queues.
Strong answer framing: Map repository owner, severity rule, SLA, exception approver and merge policy.
L310. Which GHAS metrics show the program is healthy?
Direct answer: Track enabled repository coverage, alert age, fix rate, reopened alerts, secret revocation time, workflow failure rate and exception age.
Why it matters in production: Metrics must show both risk reduction and developer workflow health.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Counting only total alerts can reward noisy onboarding.
Strong answer framing: Pair coverage metrics with remediation and exception quality.
Policy, rollout and operations (4)
Explain how rules are scoped, piloted, tuned and governed.
L211. How do you roll out CodeQL across many repositories?
Direct answer: Start with high-risk languages and repos, use default setup where it fits, validate build coverage, tune query suites and phase branch protection.
Why it matters in production: A rushed rollout can create noisy alerts or failed builds that developers bypass.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Turning on strict gates for every repo on day one is risky.
Strong answer framing: Pilot, measure alert quality, fix build gaps, then enforce by risk tier.
L212. How do you decide whether to dismiss a code scanning alert?
Direct answer: Dismiss only with a reason such as false positive, acceptable risk or used in tests, and attach evidence from code context or compensating control.
Why it matters in production: Dismissal is an audit decision, not a cleanup shortcut.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Mass dismissing old alerts hides technical debt and creates audit risk.
Strong answer framing: Explain who can dismiss, what reason is allowed and when it must be revisited.
L313. What branch protection evidence matters for GHAS?
Direct answer: Required code scanning checks, required reviews, status checks, protected branch settings and bypass permissions matter.
Why it matters in production: These controls decide whether security findings can block unsafe merges.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Only showing an alert list does not prove enforcement.
Strong answer framing: Show the policy and a PR example where the check passed, failed or required approval.
L314. How do you prevent alert fatigue in GHAS?
Direct answer: Tune query suites, prioritize reachable or exploitable findings, assign code owners, define SLAs and clean up stale dismissed alerts.
Why it matters in production: Too many low-value findings make developers ignore the whole program.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Suppressing entire rules globally without review can remove useful coverage.
Strong answer framing: Tune by repository risk and track fix rate, reopen rate and exception age.
Troubleshooting and L3 scenarios (6)
Show the evidence-backed RCA sequence interviewers expect.
L215. A CodeQL workflow suddenly stopped reporting. What do you check?
Direct answer: Check workflow status, language detection, build step, CodeQL initialization, permissions, branch scope and whether the repo is still enabled for code security.
Why it matters in production: Missing scan evidence can make leaders think risk dropped when coverage actually broke.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Do not start by editing queries before checking workflow health.
Strong answer framing: Find the last successful run and compare workflow, permissions and branch changes.
L216. A secret alert is closed but the credential still works. What happened?
Direct answer: The alert lifecycle was closed without completing revocation or rotation in the credential provider.
Why it matters in production: GitHub can flag the secret, but the external service must invalidate it.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: A weak answer assumes closing the alert disables the token.
Strong answer framing: Prove revocation at the provider and then update alert evidence.
L317. How do you validate a CodeQL false positive?
Direct answer: Trace source, sink, sanitizer and execution context, then compare the finding with real application flow or tests.
Why it matters in production: Validation prevents both noisy alerts and unsafe dismissals.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: A developer saying 'not exploitable' is not enough.
Strong answer framing: Document the code path, compensating control and owner decision.
L318. How do you prove a GHAS remediation worked?
Direct answer: Confirm the vulnerable line or secret is removed, rerun the workflow, verify alert status and link the merged fix PR.
Why it matters in production: The proof must tie the technical fix to the platform status.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: A local code change without a green workflow is incomplete.
Strong answer framing: Use PR, workflow run and alert status as the evidence chain.
L119. What should a junior DevSecOps engineer never do first?
Direct answer: They should not disable branch protection, dismiss alerts in bulk or publish secrets while trying to test scanning.
Why it matters in production: Those actions can create real exposure or remove audit evidence.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: Treating GHAS as a nuisance instead of a control weakens the program.
Strong answer framing: Collect alert IDs, workflow runs and repo settings before proposing changes.
L220. What should be in a GHAS escalation?
Direct answer: Include repository, branch, workflow run, alert URL, rule ID, affected path, owner, severity, current status and requested decision.
Why it matters in production: This lets AppSec, developers and platform teams act without guessing.
Evidence to mention:
- CodeQL rule, query suite and affected path
- secret scanning alert status and token revocation proof
- dependency review finding and package manifest diff
- branch protection or required workflow status
- fix PR, dismissal reason and owner approval
Weak answer / common trap: An escalation that says 'CodeQL failed' wastes triage time.
Strong answer framing: Make the escalation reproducible and evidence-led.
20-minute drill: Answer one question from each section, then rehearse this failure: a leaked token was rotated but the alert remains open and the secret still exists in git history. Your answer should name the likely cause, evidence, fix and retest.