A leaked credential report is ready to close when you can explain what stopped the exposure, what invalidated the old secret, what prevents a repeat, and what you checked for misuse. Record the evidence and any remaining work separately. A private download page or a successful deployment answers only part of that question.

You do not need a huge incident-response department to do this. You need a report owner who can distinguish a completed action from a verified result, and a closure note the next person can understand without piecing together five conversations.

## What does the Baseten disclosure teach about closure?

Removing public access and invalidating a credential are separate actions. A recent Hacker News discussion offers a concrete example, even though the incident itself happened earlier.

In a September 1 account, Strix described finding a working GitHub token in a Baseten container image during July. Its timeline says the report arrived on July 13. Baseten restricted the registry project the following morning, but Strix reported that the token still worked. Later that afternoon, Baseten's security team confirmed rotation. The account praises the team's response and records the remaining findings closing on July 17. It does not describe an independent post-rotation token test. [Read Strix's account](https://www.strix.ai/blog/baseten-harbor-github-pat-takeover).

The [HN discussion](https://news.ycombinator.com/item?id=49716476) brought that account back into view. This is a lesson from a disclosed July incident, not a claim of a new breach.

The useful management question is simple: **what exactly does “fixed” mean in your report?** Your infrastructure owner may mean the download is blocked. Your identity owner may mean the credential is dead. Your incident lead may still be reviewing what happened before either change.

## Give each closure question an owner

Use four separate checks for a leaked credential report. This is our recommended working practice, not a formal standard or a promise that every incident fits the same sequence.

Containment and investigation can run together. Do not wait for a polished report before taking urgent action. The table is a way to account for work as you go, rather than a queue that makes one person wait for another.

| Closure question | Suggested owner | Evidence to record | What it does not establish |
|---|---|---|---|
| Can someone still obtain the exposed material through the reported route? | Artifact or service owner | A scoped access check, affected artifact references, time of change | Whether someone already copied it |
| Can the old credential still grant access? | Credential or identity owner | Provider revocation record and appropriate owner-controlled validation | Whether access occurred before revocation |
| Can the same process publish another secret? | Build or application owner | Changed secret handling and inspection of a new output | Whether every historical copy disappeared |
| What do we know about prior use? | Incident lead | Reviewed systems, time window, findings, evidence gaps | A guarantee that nothing happened outside that coverage |

In a small startup, one engineer may hold several roles. Name that person beside each answer anyway. It makes handoffs possible when the incident crosses a shift, a holiday, or a contractor's last day.

Agree on who makes the final closure decision. A report owner should collect the answers, not silently substitute their judgment for a credential administrator who has not yet confirmed the change.

## Remove the exposure without confusing cleanup with revocation

Treat exposure removal as a scoped result: a particular file, image, log, or endpoint is no longer available to the audience that could previously obtain it. Record which route you checked and which artifact it served.

For a container image, use a stable artifact identifier alongside any friendly tag. For a published log, identify the run and access path. This is our suggested recordkeeping discipline: “the registry is private” gives the next reviewer less to work with than an identified artifact and a described access check.

GitHub's sensitive-data guidance puts revoking or rotating the secret ahead of repository-history cleanup. It also explains that rewriting history has costs and may not be necessary once the access risk is removed. That guidance concerns Git repositories; the broader distinction between invalidating a credential and removing copies also helps you reason about other artifacts. [GitHub's removal guidance](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository).

Do not set an impossible closure condition that requires proving every copy on the internet has disappeared. Instead, record the cleanup decision. Can a remaining copy still reveal source code, customer information, or a different secret? If so, revoking this credential does not resolve those separate exposures.

Keep required investigation evidence in a restricted location while you remove unnecessary copies. The public report, researcher thread, and internal incident record do not need identical contents. Refer to the credential by an internal identifier; do not paste its full value into every update.

Your validation should stay within your authorization. A report about your service does not automatically permit testing a supplier's systems. Our [guide to security scanning scope](/blog/security-scanning-asset-scope-authorization) covers how to establish that boundary before checks begin.

## Prove that the old credential is invalid

For closure, ask about the credential that leaked. “We created a new token” and “the old token no longer authenticates” are different statements.

GitHub documents that revoked or expired tokens can no longer authenticate Git and API requests. It also says an authorization-destroy event may appear in the security log. That makes the provider's record useful evidence, but the documentation does not promise that every situation produces the same visible event. [GitHub token expiration and revocation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation).

Ask the credential owner to record the provider, credential identifier, revocation time, and confirmation method. Where appropriate, an authorized owner can perform a bounded check through an approved workflow. The important point is to distinguish provider confirmation, an observed authentication result, and a teammate's assumption.

Do not invent an external retest requirement. A researcher may be unavailable or may lack permission to make further requests. Your team remains responsible for obtaining adequate evidence through its own administrators and systems.

OWASP's secrets-management guidance treats revocation, replacement, and deletion as separate incident-response actions. It calls for rapid containment and the ability to determine revocation status. Keep those actions separate when planning the change: restoring a dependent service is operational work; neutralizing the leaked credential is the security result. [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html#92-remediation).

Be explicit about any transition period when both credentials work. Give it an owner and an end condition. Do not let a successful application health check stand in for confirmation that the previous credential has been invalidated.

## Change the process that produced the leak

A replacement credential needs a safer path into the application or build. Otherwise, the next successful release may recreate the same report with a new secret.

Docker warns against passing build secrets through Dockerfile arguments or environment variables because they can persist in the final image. Its recommended secret mounts make credentials temporarily available to a build instruction. [Docker build-secret guidance](https://docs.docker.com/build/building/secrets/).

Its `SecretsUsedInArgOrEnv` build check also calls out persistence in image metadata. That is a useful reason to inspect the produced artifact, rather than reviewing only the changed source line. [Docker's build-check reference](https://docs.docker.com/reference/build-checks/secrets-used-in-arg-or-env/).

Our recommended acceptance note has two parts: what changed in secret handling, and what was checked in the replacement output. A code review can establish that a change looks right. Reviewing a newly produced artifact checks whether that output contains the problem you meant to remove.

Make the check specific to the leak. If a build wrote authenticated URLs into configuration, examine that output. If a publishing job exposed its environment, examine the resulting log and its audience. Avoid a generic “scanner passed” note without the scanner's scope or the artifact it examined.

Also reconsider the access the replacement needs. GitHub recommends GitHub Apps for access on behalf of an organization or for long-lived integrations. Where you still use a personal access token, choose its permissions and lifetime deliberately; changing credential type alone does not prove that access is appropriate. [GitHub's personal access token guidance](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

You may have broader hardening work after the immediate defect is corrected. Separate that work from the closure claim. “The affected build is repaired; a review of other build pipelines belongs to Maya and is due Friday” is a useful decision. “All secret handling is now secure” is not supported by that work.

## Review impact and name the limits

A revoked credential answers whether that credential can keep granting access. It does not tell you what happened while it was valid.

GitHub's incident investigation guidance recommends examining audit-log activity associated with the compromised token, unexpected actors, and relevant exposure findings. It also warns that an incident can move between attack vectors, so a credential finding may lead to further investigation. [GitHub's investigation areas](https://docs.github.com/en/code-security/reference/security-incident-response/investigation-areas).

For your closure record, we recommend a short coverage statement. Name the systems reviewed, the available time range, the person who reviewed them, and the result. Add what you could not establish. A reader should not have to infer whether “nothing suspicious” means a week of complete records or a few hours of partial logs.

Keep observation and conclusion separate. You may find no unexpected activity in the records available to you and still lack coverage for the full exposure period. Write both sentences. An honest limit gives the incident owner a basis for deciding whether further work is needed.

Consider the permissions the credential had when deciding where to look. Access to deployment configuration creates different questions from access to one read-only package. Record the reasoning behind the investigation scope so a later reviewer can challenge it without repeating the whole exercise.

If investigation finds a new problem, give it its own owner and reference. Closing the original exposure report should not erase an incident that remains open elsewhere. Likewise, do not keep a narrowly resolved researcher report open indefinitely without explaining which separate decision you are waiting on.

## Write a closure note someone else can review

A good closure note states the result, the evidence, and the unfinished work. It should be short enough to read during a handoff and specific enough to question.

GitHub makes this distinction visible in its own alert workflow: removing a token from a repository does not automatically close the secret-scanning alert. Its guidance also provides for a closure comment that becomes part of the alert timeline. [Resolving secret-scanning alerts](https://docs.github.com/en/code-security/how-tos/manage-security-alerts/manage-secret-scanning-alerts/resolving-alerts).

Here is a **fictional example**. The organization, identifiers, timestamps, and findings are invented to demonstrate the format; they describe neither Baseten nor a Kit customer.

> **Report:** Exposed build credential in artifact `release-184`.
>
> **Exposure:** Lena restricted the affected artifact at 10:15 UTC. An authorized access check confirmed the reported public route no longer served it. Other artifacts were reviewed under the linked inventory task.
>
> **Old credential:** Arun revoked credential `build-reader-previous` at 10:18 UTC. The provider record and approved validation result are stored in the restricted incident folder. Dependent services now use the replacement.
>
> **Recurrence:** Lena changed the build's secret handling. The replacement artifact and its metadata were inspected against the reported leak pattern. The evidence identifies the new artifact and review time.
>
> **Impact:** Jo reviewed the available identity and repository records for the stated exposure window. No unexpected use was found in those records. Earlier registry download records were unavailable, so we cannot establish who obtained older copies.
>
> **Decision:** Jo approved closure of this report. The linked logging-improvement task remains assigned to Arun. Researcher communication describes the completed remediation and the investigation limit without including credentials.

Notice what the note does not say. It does not claim that all copies vanished, that the researcher personally confirmed every action, or that a clean log search proves nobody accessed the system.

You can use the same headings as a blank template. Let “not applicable” be an answer only when the owner explains why. If a reported credential was already invalid, for example, record how you established that and whether the exposed artifact contains anything else requiring attention.

Before approving closure, have a second person read the note if your team can support it. Ask them to identify one sentence whose evidence is unclear. That small review is our practical suggestion for catching ambiguous handoffs, not a mandatory certification step.

## Keep the closure decision and conversation together in Kit

Keep the evidence summary beside the report so the status is explained. A future teammate should be able to find who decided the fix was verified and what that decision covered.

Kit's report lifecycle records status transitions with an actor, timestamp, and optional comment. An authorized team member can mark a fix verified and add a note. The [triage documentation](/docs/triaging-reports) explains the workflow.

That action records a human decision. **Kit does not revoke the leaked credential, require the four checks above, or require researcher confirmation before that transition.** Your team must establish the evidence and decide what is sufficient. Use the note to summarize it and reference restricted records where the details belong.

The report conversation supports internal discussion and researcher-facing messages. Keep technical investigation details in the appropriate channel, then tell the researcher which remediation is complete and whether any requested follow-up remains within scope. The [researcher communication guide](/docs/communicating-with-researchers) covers those visibility choices.

For your next leaked credential report, start with four headings: exposure, old credential, recurrence, impact. Assign the owners while the response is underway. By the time you close the report, the note should explain what you know without making anyone guess what “fixed” meant.

> [!CTA]
> **Try the closure note on one report.** Keep the owners, decision, and researcher conversation together, then check whether a teammate can understand the outcome from that record.
>
> [Start your free trial](/users/sign_up)