An open-source maintainer hosts a popular public repository on GitHub.com and has never purchased any paid security product for it. They want to confirm whether secret scanning will detect leaked tokens such as a published cloud provider key in that public repository at no extra cost. What is the correct position for a public repository under GitHub.com?
- ASecret scanning runs on the public repository only after the maintainer buys a "GitHub Advanced Security" or "Secret Protection" licence and assigns a seat.
- BSecret scanning is available free of charge for the public repository, so it can detect supported leaked credentials without any paid product. Correct
- CSecret scanning only ever runs on public repositories that belong to a paid organisation account, not on personal public repositories.
- DSecret scanning is unavailable for public repositories because exposed secrets there are treated as already public and beyond remediation.
Why A is wrong: This is tempting because private and internal repositories do require a paid "Secret Protection" licence, but public repositories on GitHub.com receive secret scanning free of charge, so no purchase or seat assignment is needed.
Why B is correct: GitHub provides "secret scanning" for public repositories at no cost as part of the platform, so the maintainer can detect supported partner and provider secrets without buying "Secret Protection". This matches the free public-repository entitlement.
Why C is wrong: Account type is not the gate here. Free public-repository secret scanning applies regardless of whether the repository is owned by a personal account or an organisation, so restricting it to paid organisations is incorrect.
Why D is wrong: Public exposure makes detection more urgent, not pointless, and GitHub still scans and alerts on it. The premise that public secrets are beyond remediation is wrong, so this option misstates the behaviour.