A parks CI pipeline token may have been exposed in a job log. What secrets action should the team take first?
Select an answer to reveal the explanation.
Short Explanation
If the spare key might be copied, change the locks now—do not wait for Monday. Revoke the exposed CI token, then replace it. Extending life or publishing it makes the breach worse.
Full Explanation
When a parks CI pipeline token may have been exposed in a job log, the first secrets action is to revoke the compromised pipeline token immediately and issue a replacement. Exposure means an attacker or unintended reader might already have the credential; leaving it valid extends the abuse window. Municipal incident response for leaked CI secrets is invalidate-first, then replace, update the pipeline’s secret reference, and review logs for unauthorized use during the exposure period.
Leaving the token active so weekend deploys are uninterrupted fails by concept: availability preference does not outrank a known credential compromise. Publishing the token in the parks newsletter fails catastrophically by widening disclosure. Extending the token lifetime fails because a longer lifetime increases, rather than decreases, risk for an already exposed secret.
Exam caveat: revocation without replacement can break pipelines—coordinate replace-and-update, but do not delay revoke while debating convenience. Also rotate any secondary secrets that appeared alongside the token in the same log scrape.
Operational check: revoke in the IdP/vault/CI secret store now, mint a new token with least privilege, update the parks pipeline configuration, purge or restrict access to the offending job logs, scan for use of the old token after exposure time, and add log-redaction rules so Authorization and token values cannot print again.