Developers keep accidentally committing cloud API keys and database passwords into the company's shared source code repository, and some of those keys were later abused. Which control most directly catches these credentials before they are exposed?
Select an answer to reveal the explanation.
Short Explanation
Think of secrets scanning as a metal detector at the repository's door: every commit walks through, and if there's a key or password in its pocket, the alarm goes off. Code signing and input validation are great tools, but they're guarding different doors. You want the one that looks for secrets in the code itself.
Full Explanation
Secrets scanning analyzes repository content, commits and history for patterns that match credentials such as API keys, tokens, private keys and passwords. Configured as a pre-commit check or a push-time hook, it can block the commit or alert the developer before the secret lands in the shared repository; scanning history also finds secrets that were committed earlier so they can be revoked and rotated. Code signing attaches a digital signature to released software so recipients can verify the publisher and detect tampering, but it says nothing about whether the source code contains embedded credentials. Input validation checks data that users or other systems send to a running application, defending against injection and malformed input; it does not inspect developers' commits to the repository. Secure cookie flags restrict how browsers send session cookies, for example only over encrypted connections, which protects session tokens in transit but is unrelated to credentials stored in source code. Exam caveat: once a secret has been pushed, deleting it from the latest version is not enough, because it remains in repository history and copies; it must be revoked and rotated. Operational check: commit a fake key that matches a known credential pattern to a test branch, confirm the scanner blocks or flags it, and confirm alerts reach the owning team.