I85PREP
⌘ K
ca-fdops study materials
ca-fdops study resources

The Secret in the Build Log

ca-fdops · Put your knowledge to work in context.

All case studies

The Secret in the Build Log

A team of 14 uses a hosted CI system. Build logs are visible to all engineers and retained for 90 days. A developer debugging a database connection issue adds echo $DATABASE_URL to a build script and commits it; the value includes a password. The log is viewed 40 times over two weeks before anyone notices. Separately, the team's container images are built from a base image pinned only to latest, and a scan last month found 3 critical CVEs in that base. The team has no secret scanning in CI, no image signing, and deploys images by tag. The database password has been unchanged for 18 months and is shared by three services.

1. Rank the issues by risk and justify the ordering. What is the immediate response to the leaked credential?

Read the worked answer

Ranking by likelihood times impact:

  1. Leaked database password (highest). It is already exposed, viewed 40 times, unchanged for 18 months, and shared by three services. Exposure is not hypothetical; blast radius is three services. Immediate response: rotate the password now, update all three services through the secret manager, invalidate old credentials, and review database access logs for the exposure window. Rotation is not optional and should not wait for a postmortem.
  2. Unpinned base image with 3 critical CVEs. Deploys by tag with no signing mean you cannot prove what is running, and a latest pull can silently change behavior. This is a supply-chain and reproducibility risk that is one bad pull from production impact.
  3. No secret scanning in CI. This is the control whose absence let issue 1 persist for two weeks and will let it recur.
  4. Shared, long-lived credential. An architectural weakness that magnifies any future leak.
  5. Log retention and visibility. 90 days of broadly visible logs is a standing exposure surface, but lower severity than the others.

The immediate response is rotate first, then investigate, then fix the process. Do not spend the first hour writing a policy.

2. Design the preventive controls you would add across CI, images, and secrets, and say how you would sequence them for a 14-person team.

Read the worked answer

Sequence by effort-to-impact, starting with controls that stop recurrence of the incident that just happened.

Phase 1 (days): stop the bleeding.

  • Enable secret scanning in CI and as a pre-commit hook; fail the build on detection.
  • Remove the echo and scrub the log if the platform allows; treat any credential ever printed as compromised.
  • Move the database password into a secret manager with per-service credentials, rotate on a schedule, and remove the shared credential.
  • Pin the base image to a digest, not latest.

Phase 2 (weeks): make it structural.

  • Build images from a minimal, maintained base; run vulnerability scanning on every build and block on critical CVEs with a documented exception path and expiry.
  • Sign images and verify signatures at deploy; deploy by digest rather than tag so what runs is exactly what was scanned.
  • Add a CI policy that fails on plaintext secrets and on log statements that print environment variables.

Phase 3 (ongoing): sustain.

  • Short-lived, automatically rotated credentials per service.
  • Reduce log retention and restrict access to build logs containing sensitive output.
  • Quarterly review of base images, CVE exceptions, and secret rotation status.

For 14 people, the key is to make the secure path the default path: pre-commit hooks and pipeline gates fail closed, so no one has to remember a policy. Publish a one-page 'what to do if you leak a secret' runbook so the next responder rotates first.