A team wants to lower the chance that GitHub Copilot inline completions introduce insecure patterns such as missing input validation, while keeping completions on for daily work. They ask which practice does the most to operate the tool responsibly alongside the suggestions themselves. Which practice fits best?
- ARun automated security scanning and code review on changes that include accepted suggestions, so insecure patterns are caught regardless of how confident the completion looked. Correct
- BSwitch from inline completions to GitHub Copilot CLI, since command suggestions are reviewed before they run and carry less security risk than editor completions.
- CAdd content exclusions for the repository's source directories so insecure code is filtered out of completions before it ever reaches the editor.
- DEnable the duplication detection policy for the organisation so that completions reproducing insecure public code are blocked at the proxy.
Why A is correct: Pairing suggestions with security scanning and review catches insecure patterns that compile and read well, directly addressing the harm without disabling completions.
Why B is wrong: The CLI is a different surface for shell commands and is tempting as a safer-sounding option, but it does not generate the application code in question and so does not address the validation gap.
Why C is wrong: Content exclusions stop named files being used as context; they do not screen returned suggestions for security, so this misunderstands what exclusions do.
Why D is wrong: Duplication detection blocks verbatim public matches and is plausible-sounding, but insecure code that is not a public match passes straight through, so it does not cover the risk.