ITPEC FE Subject B October 2025 Question 20

The scenario describes a company whose developer accidentally hard-coded an API key and pushed it to a public repository, allowing unauthorized access to external services.

Blank A — "to detect any secrets that might have been missed by this rule before committing code to a publicly accessible repository":
- This is a preventive control at the pre-commit stage
- Automated secret scanning tools (e.g., git-secrets, TruffleHog, GitHub secret scanning) check code for hard-coded credentials before they reach the repository
- Checking API logs is reactive (detects misuse after leakage, not before)
- Antivirus scans detect malware, not secrets in source code

Blank B — "to minimize damage in case any secrets still evade detection":
- This is a damage limitation control assuming secrets have already leaked
- Regular rotation of secrets ensures leaked keys become invalid quickly, limiting the window of exploitation
- MFA for repository access prevents unauthorized commits but does not reduce damage from an already-exposed secret

Why not others:
- (a) A = checking logs (reactive, not preventive); B = rotation (correct B, but A is wrong)
- (b) A = checking logs (reactive); B = MFA (prevents repo access, doesn't minimize leaked-secret damage)
- (d) A = secret scanning (correct A); B = MFA (wrong — doesn't address already-leaked secrets)
- (e) A = antivirus (irrelevant to secret detection in code); B = rotation (correct B, but A is wrong)
- (f) A = antivirus (irrelevant); B = MFA (wrong)

Key rule: preventive secret detection → automated scanning tools; damage minimization for leaked secrets → regular secret rotation.

AI-generated — may contain errors