Secret scanning remediation workflow
rotate, revoke, verify, and prove it on one record
A leaked secret is not a code-quality finding. It is a live credential an attacker can use until the rotation completes, the old value is revoked, and the verification proves the leak is closed. Run secret scanning remediation as a governed workflow on the engagement record so every detection routes to a named owner, the rotation and revocation are deliberate state events, and the audit trail proves which secrets were exposed, when, for how long, and how the closure was verified.
No credit card required. Free plan available forever.
Run secret scanning remediation as a governed workflow on the engagement record
A leaked secret is not a code-quality finding. It is a live credential an attacker can use until the rotation completes, the old value is revoked, and the verification scan proves the leak is closed. Programmes that treat secret-scanning detections as ordinary SAST findings ship cleanup commits while the credential is still live, close findings on plan rather than on evidence, and discover months later that the value still authenticates because the rotation produced a new credential rather than killing the old one. The cost of the wrong remediation order is not a process gap; it is the live attacker advantage that survives the closure note.
This is the credential-leakage remediation lifecycle. For the upstream code-review work that prevents secrets from reaching the repository in the first place, read the code review workflow. For the integration of SAST and SCA into the development pipeline that produces the scanner output, read the DevSecOps scanning workflow. For the upstream validation step that decides whether a finding is real before it enters the queue, read the scanner result triage workflow. For the cross-stage routing layer that moves findings between SDLC gates, read the SDLC vulnerability handoff workflow. For the per-finding lifecycle from open to verified closed, read the remediation tracking workflow. The vulnerability reference for the underlying class is the hardcoded secrets explainer.
Six lifecycle stages and how the remediation plays out at each one
Every secret-scanning remediation has a healthy posture and a default failure mode. The six stages below are the ones where most programmes accumulate the gap between intended process and operational reality. Each one starts as a routing convenience and ends as an audit-reconciliation problem.
| Lifecycle stage | Healthy posture | Default failure |
|---|---|---|
| Detection | A code scan against the connected repository surfaces the leaked secret with the file path, line number, secret category, and a confidence score on the engagement record. The detection is the start of a remediation clock that does not stop until the closure is verified. Programmes that operate this way know the moment the leak entered version control because the activity log carries the timestamp of the first scan that found it. | The leaked secret is detected by a scanner running outside the engagement record. The finding lands in a scanner UI nobody reads daily. The remediation clock starts when somebody happens to glance at the dashboard rather than at detection time. The audit lookback cannot answer how long the credential was live because the detection event was never recorded against a tracked finding. |
| Triage | Each detection is classified as a live secret that needs rotation, a documentation sample that needs annotation, or a false positive that needs a suppression rule. The classification lands on the finding with the named triager, the rationale, and the timestamp. The next quarter does not re-litigate the same call; the next match against the same pattern in a fixture file inherits the prior decision automatically. | Every Semgrep match is treated as a real leak. The team rotates credentials that were never live, opens incident bridges for documentation samples, and burns the on-call rotation chasing strings that were never credentials. Within two weeks, the team mutes the scanner and the next real leak surfaces as a customer report rather than as a tracked finding. |
| Rotation | For confirmed live secrets, the very first remediation step is rotation at the issuing system (the cloud provider IAM console, the database admin panel, the third-party API dashboard, the OAuth application, the signing key vault). The new credential identifier (never the value itself) is recorded on the finding with the named operator and the issuing-system reference. Rotation is the step that removes the attacker advantage from the leaked value. | The team removes the secret from the working tree and commits the cleanup before rotating at the issuing system. The leaked credential remains live in production for hours or days while the cleanup commit propagates and the developer gets around to logging into the issuing system. An attacker who already had the value continues to authenticate. |
| Revocation | After rotation, the previous credential is explicitly revoked at the issuing system. A verification check confirms the old value no longer authenticates: an authentication request that should fail returns the expected denial, the audit log shows the credential as revoked, the cloud provider returns it as deactivated. Revocation is what turns the leaked value from a live attack tool into an inert string. | The rotation creates a new credential, but the old one is left active because the issuing system supports overlapping credentials and nobody scheduled the revocation. Months later, an attacker uses the original leaked value because the rotation produced a new credential rather than killing the old one. |
| History cleanup | The committed secret is removed from the working tree and the repository history is treated explicitly: a documented decision either rewrites history with git filter-repo or BFG Repo-Cleaner, leaves the history untouched because the credential is already revoked and the repository is private, or scopes a partial cleanup with the rationale recorded on the finding. The decision is reproducible from the engagement record rather than implied from the closure note. | The developer removes the secret from the working tree and pushes the cleanup commit. The leaked value remains in the git history, the previous pull request diff, the cached forks, and the CI build artefacts. Anyone with read access to the repository (or anyone scraping mirrors and forks) can still recover the credential from history. The closure note implies a complete cleanup that did not happen. |
| Closure verification | A follow-up code scan against the cleaned branch confirms Semgrep no longer reports the secret. The verification scan attaches to the same finding as a state event, the closure moves to verified closed, and the activity log captures the chain of detect, triage, rotate, revoke, cleanup, and verify with timestamp and user attribution at each step. The audit committee can reconstruct the incident from one record. | The finding is moved to closed because the developer reported they fixed it. No follow-up scan ran. The next scheduled scan (days or weeks later) re-detects the same secret because the cleanup commit was reverted, applied to the wrong branch, or never landed. The reopen rate climbs and the closure-on-evidence discipline never takes hold. |
Six failure modes that quietly break secret-scanning remediation
Secret-scanning remediation failures rarely look like failures at the moment they happen. They look like convenience: a faster cleanup commit, a simpler triage flow, a quicker closure. The cost arrives at the next compromise investigation, the next audit lookback, or the next scan that resurfaces a credential the previous cycle thought it had closed.
Cleanup happens before rotation
The team removes the secret from the code first and rotates the credential later. The leaked value is live in production until the rotation completes. Attackers who already harvested the value continue to authenticate. The remediation order is the difference between a closed finding and a closed loophole.
Rotation without revocation
The rotation produces a new credential but the old one is left active because the issuing system supports overlapping credentials. The leaked value continues to authenticate until somebody schedules the revocation. The closure note says rotated; the live credential says still working.
History is left in the repository
The cleanup removes the secret from the working tree and the closure event is recorded. The value remains in the git history, in the previous pull request diff, in cached forks, and in CI build artefacts. The cleanup looks complete on the file view and remains accessible to anyone willing to read the log.
Triage treats every match as an incident
Every Semgrep match against the p/secrets ruleset triggers an incident bridge. Test fixtures, documentation samples, and high-entropy strings burn the on-call queue. Within weeks the team mutes the scanner and the next real leak surfaces as a customer report rather than as a tracked finding.
Closure is recorded on plan rather than evidence
The finding is closed because the developer reported they fixed it. No follow-up scan ran. The next scheduled scan re-detects the same secret because the cleanup commit was reverted, applied to the wrong branch, or never landed. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures.
No accountability for downstream propagation
The leaked value reached cached forks, sample CI logs, container image layers, internal wikis, and partner integrations. Rotation closes the credential but the propagation trail is never enumerated. Months later the same credential pattern re-emerges because nobody owned the question of where else the value had spread before the leak was caught.
Six fields every secret-scanning remediation policy has to record
A defensible remediation policy is six concrete fields on the engagement record, not an abstract paragraph in a security handbook. Anything missing from the list below is a known gap in the remediation discipline rather than a detail that surfaces later.
Detection-to-triage SLA
The maximum time between a code scan landing a secret-scanning finding and a named triager classifying it as live secret, fixture, or false positive. Without an SLA, detections accumulate in a backlog the on-call rotation never owns. The SLA lives on the engagement so the next finding inherits it rather than waiting for an operator to set the deadline per match.
Triage classification rule
How each detection is classified into live secret, documentation sample, or false positive. The rule names the inputs (the file path, the secret category, the confidence score, the surrounding code context, the deployment posture of the file) so the triage decision is reproducible across triagers and across cycles. The rationale lands on the finding so the next quarter does not re-litigate the same call.
Rotation-before-cleanup contract
The contract that says rotation at the issuing system always precedes any code change that removes the secret from the working tree. The contract closes the window where a developer pushes a cleanup commit before the leaked credential is rotated. The contract lives on the engagement so every finding inherits the order rather than relying on triage memory.
Revocation verification check
The explicit check that the old credential no longer authenticates after revocation: an authentication request that should fail returns the expected denial, the audit log shows the credential as revoked, the cloud provider returns it as deactivated. The check lands on the finding as evidence of revocation rather than as a closure note that implies the work happened.
History-cleanup decision rule
The documented decision on whether the leaked value is removed from version control history with git filter-repo or BFG Repo-Cleaner, left in history because the credential is revoked and the repository is private, or partially cleaned with the rationale recorded on the finding. Without the decision rule, history cleanup is ad hoc and the residual exposure is implied rather than disclosed.
Verification scan as the closure event
A follow-up code scan against the cleaned branch confirms Semgrep no longer reports the secret. The scan result attaches to the same finding as a state event and the closure moves to verified closed. Closure on plan does not satisfy the rule; only closure on a verification scan that ran after the cleanup commit landed on the target branch.
Secret scanning remediation checklist
For every confirmed leaked credential, the AppSec lead and the engineering owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- Every code scan against the connected repository runs Semgrep with the p/secrets ruleset and lands findings on the engagement record.
- Detections include file path, line number, secret category, and confidence score so triage has the context the decision needs.
- Each detection is classified as a live secret, documentation sample, or false positive with the named triager, the rationale, and the timestamp.
- For confirmed live secrets, rotation at the issuing system happens before any code change removes the value from the working tree.
- The new credential identifier (never the value) is recorded on the finding with the named operator and the issuing-system reference.
- The previous credential is explicitly revoked at the issuing system after rotation completes.
- A verification check confirms the old credential no longer authenticates and the result lands on the finding as evidence of revocation.
- A documented decision determines whether the secret is removed from version control history and the decision rationale is recorded on the finding.
- A follow-up code scan against the cleaned branch confirms Semgrep no longer reports the secret before the finding moves to verified closed.
- The activity log captures detect, triage, rotate, revoke, cleanup, and verify with timestamp and user attribution at each step.
- AI-generated reports derive the secret-incident narrative from the same engagement record so leadership reads the closure verification rather than a hand-built status update.
- Recurring patterns trigger a developer-education event and an upstream control review (pre-commit hook, secret manager rollout, repository template hardening) so the same root cause does not produce another leak next month.
How the secret-scanning remediation looks in SecPortal
Secret-scanning remediation runs on the same feature surfaces the rest of the product security programme already uses: the engagement record, the findings record, the activity log, code scanning, and AI reporting. The discipline is keeping the security record canonical across detection, rotation, revocation, cleanup, and verification rather than letting each step create its own parallel record.
Semgrep p/secrets in code scanning
Code scanning connects to GitHub, GitLab, and Bitbucket via OAuth and runs Semgrep with the community p/secrets ruleset. Findings land on the engagement record with the file path, line number, secret category, and confidence score. The repository is cloned into an isolated container with no persistent storage, the scan runs, and the container is destroyed.
One canonical finding across stages
Findings management holds severity, evidence, owner, and closure on the security record. Detection, triage, rotation, revocation, cleanup, and verification all attach to the same record. The journey from leak to closure is one record with a state history rather than six parallel records.
Triage decision on the finding
Every detection is classified as live secret, documentation sample, or false positive with the named triager, the rationale, and the timestamp on the finding. The decision is reproducible across triagers and inherited by the next match against the same pattern, so the next quarter does not re-litigate the same call from scratch.
Rotation evidence on the finding
The new credential identifier (never the value), the issuing-system reference, and the named operator all land on the finding as state events. SecPortal does not store the leaked value itself. The encrypted credential storage feature handles credentials SecPortal needs for authenticated scans, with AES-256-GCM encryption at rest.
Verification scan as the closure event
A follow-up code scan against the cleaned branch confirms Semgrep no longer reports the secret. The result attaches to the finding as a state event and the closure moves to verified closed. Closure on plan does not satisfy the rule; only closure on a verification scan that ran after the cleanup commit landed on the target branch.
Audit trail in the activity log
Every detection, triage, rotation, revocation, cleanup, and verification event lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail SSDF, ISO 27001, SOC 2, PCI DSS, and OWASP ASVS assessors expect to see when they ask for the response history behind a credential exposure.
Five views the secret-scanning remediation cycle actually drives
The reports that drive secret-scanning remediation are not the static summary that lands at the end of a quarter. They are the live views AppSec leads, security engineering owners, and incident responders use between scans. The five below are the ones every meaningful product security programme settles on, and they all derive from the live engagement record rather than a parallel scanner-tool extract.
Detection backlog by category
Open secret-scanning findings broken down by secret category (cloud key, database password, API token, OAuth client secret, signing key, generic high-entropy string). The view that shows which credential classes recur and which root causes are still producing leaks.
Time from detection to rotation
For each closed finding, the time between the first detection event and the rotation event recorded on the finding. The view that shows whether the response window is shrinking and which categories of credentials are rotated quickly versus stuck in triage.
Verification scan coverage
Closures that are paired with a verification scan against the cleaned branch and closures that are not. The view that distinguishes durable closure from administrative closure and surfaces silent reopens before the next scheduled scan does it for you.
Reopen rate by repository
Findings that closed and reopened within a defined lookback window, broken out by repository. The view that surfaces the repositories where the upstream control gap (no pre-commit hook, no secret manager rollout, no template hardening) keeps producing the same pattern of leaks.
Activity log export
Every detection, triage, rotation, revocation, cleanup, and verification event with timestamp and user attribution. The CSV export is the evidence trail behind the headline secret-scanning numbers, ready for SSDF, ISO 27001, SOC 2, PCI DSS, and OWASP ASVS audit reads.
What auditors expect from secret-scanning remediation
Secret-scanning evidence shows up in audit reads whenever an external assessor reviews the product security programme or investigates a credential-related incident. The frameworks below all expect the programme to show that secrets are protected, that exposures are detected, that rotation and revocation happen, and that closure is verified. A documented policy without enforcement evidence reads as a process gap.
| Framework | What the audit expects |
|---|---|
| NIST SP 800-218 SSDF | PS.1 (Protect All Forms of Code from Unauthorized Access and Tampering), PS.2 (Provide a Mechanism for Verifying Software Release Integrity), PW.6 (Configure the Compilation, Interpreter, and Build Processes), and RV.1 (Identify and Confirm Vulnerabilities on an Ongoing Basis) all expect documented evidence that secrets are protected, that exposures are detected, and that remediation is verified. A canonical record covering detect, rotate, revoke, cleanup, and verify satisfies the SSDF evidence ask without a parallel attestation per leak. |
| ISO 27001:2022 | Annex A 5.17 (authentication information) expects credentials to be protected and rotated when compromise is suspected. Annex A 8.24 (use of cryptography) expects key management discipline. Annex A 8.28 (secure coding) expects secrets to be kept out of source code. Annex A 8.29 (security testing in development) expects evidence that the testing actually finds the secrets and that closure is verified. |
| SOC 2 | Common Criteria CC6.1 expects logical access controls including credential management. CC7.1 and CC7.2 expect the entity to detect and respond to security events. A canonical engagement record covering detection, rotation, revocation, cleanup, and verification produces the audit trail SOC 2 reviewers expect to see when they ask for the response history behind a leaked credential incident. |
| PCI DSS 4.0 | Requirement 3.3.2 requires sensitive authentication data to be protected. Requirement 6.3.1 requires vulnerabilities to be identified and ranked. Requirement 8.3 requires authentication factors to be properly managed including rotation when compromised. The activity log of detect, rotate, revoke, cleanup, and verify is the evidence trail an assessor expects when reviewing a credential exposure. |
| OWASP ASVS | V2 Authentication and V6 Cryptography requirements expect credentials to be managed outside of source code, rotated under defined conditions, and revoked when exposure is suspected. The verification expectation is that secret-scanning controls run regularly and that exposures are remediated with evidence rather than with a checkbox. |
Where secret-scanning remediation sits in the wider security programme
Secret-scanning remediation composes with the rest of the security programme on the same engagement record so the credential-leakage workflow stays connected to the SDLC, the code-review process, and the incident-response cycle that follows when a leak becomes a confirmed compromise.
Upstream and adjacent
Secret-scanning remediation depends on DevSecOps scanning integrating SAST into the pipeline, code review producing the upstream review that should catch secrets before commit, scanner result triage promoting validated findings before they become incident bridges, and the SDLC vulnerability handoff workflow when the credential-leakage finding crosses stage gates.
Downstream and reporting
Secret-scanning evidence rolls into remediation tracking for the per-finding lifecycle from open to verified closed, incident response when a leak becomes a confirmed compromise that needs broader containment, vulnerability prioritisation for queueing the credential class against the rest of the backlog, and security leadership reporting for the leadership cadence that reads time-to-rotation as a leading indicator of programme health.
Pair the workflow with the long-form guides and the framework references
Secret-scanning remediation is operational; the surrounding guides explain the secure-SDLC practice expectations the workflow has to satisfy. Pair this workflow with the NIST SSDF implementation guide for the federal reference model that includes secrets-protection practices, the secure code review checklist for the manual review step that should catch secrets before they reach the repository, the SAST vs SCA explainer for where secret detection sits in the code-scanning toolchain, and the findings deduplication guide for the deduplication discipline that keeps the same leaked secret from creating parallel findings across scans. The vulnerability reference for the underlying class is the hardcoded secrets explainer. The framework references that mandate credential-protection and verified remediation evidence include NIST SP 800-218 SSDF for the four practice groups, ISO 27001 for Annex A 5.17, 8.24, 8.28, and 8.29, OWASP ASVS for the V2 and V6 verification requirements, PCI DSS for requirements 3.3.2, 6.3.1, and 8.3, and SOC 2 for CC6.1, CC7.1, and CC7.2.
Buyer and operator pairing
Secret-scanning remediation is the workflow AppSec teams run as the front line for credential-leak detection, product security teams run as the owner of the secrets-protection control, DevSecOps teams run when scanner output flows into the pipeline at the SAST gate, security engineering teams run as the platform-side owners who coordinate rotation and revocation across systems, and internal security teams run alongside the broader vulnerability management programme. CISOs read time-to-rotation, verification-scan coverage, and reopen rate by repository as the leading indicators of whether the secrets-protection programme is reducing the class of credential leaks reaching production.
What good secret-scanning remediation feels like
One canonical record across the lifecycle
Detection, triage, rotation, revocation, cleanup, and verification all live on the same security record. Each step adds state events; nothing dissolves at the seams. Audit lookback queries hit one record rather than reconstructing the journey from chat logs and commit messages.
Rotation precedes cleanup, always
The rotation-before-cleanup contract is enforced as a workflow rule rather than a handbook paragraph. The leaked credential is rotated at the issuing system before any code change removes the value, so the cleanup commit never lands while the leaked value is still live.
Closure is verified, not asserted
A finding moves to closed only when a follow-up scan against the cleaned branch confirms Semgrep no longer reports the secret. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures that survive the next scheduled scan.
Evidence is derivative of the work
Detection events, triage decisions, rotation history, revocation verification, cleanup scope, and verification-scan results all derive from the live engagement record. The activity log export is the trail, and the AI report is the narrative. Nobody assembles the secret-scanning evidence the week before the audit.
Secret-scanning remediation is the workflow that turns a leaked-credential detection into a verified closure. Run it on the engagement record so the security finding stays canonical across detect, triage, rotate, revoke, cleanup, and verify, the receiving owner records each step as a deliberate event, the closure is paired with a follow-up scan, and the audit lookback resolves from one record rather than from a multi-system reconciliation sprint.
Frequently asked questions about secret scanning remediation
What is a secret scanning remediation workflow?
A secret scanning remediation workflow is the operating discipline that turns a leaked-credential detection into a verified closure. It covers the detection event from a code scan, the triage decision into live secret, fixture, or false positive, the rotation at the issuing system, the revocation of the old value, the optional history cleanup in version control, and the verification scan that confirms the closure. SecPortal runs the workflow on the engagement record so each leaked secret is one record with a state history rather than a chain of chat messages and ad hoc commits.
How does SecPortal detect leaked secrets in code?
SecPortal runs Semgrep with the p/secrets community ruleset against the connected repository on every code scan. The scan clones the repository into an isolated container with no persistent storage, runs the rules over the working tree, and lands every match on the engagement record with the file path, line number, secret category (cloud key, database password, API token, OAuth client secret, signing key, generic high-entropy string), and a confidence score. The container is destroyed after the scan; no source code is retained on disk.
Why does rotation always come before code cleanup?
The leaked credential is live until it is rotated at the issuing system. If the team removes the secret from the working tree and pushes the cleanup commit before rotating, the leaked value continues to authenticate in production while the cleanup propagates. Attackers who harvested the value before the cleanup commit (or who scrape repository mirrors and forks) continue to use it. Rotating first removes the attacker advantage; cleanup after rotation removes the source of future re-leaks. Reversing the order leaves a window where the closure note implies safety the live credential does not provide.
When should we rewrite git history to remove a leaked secret?
History rewrite is a deliberate decision recorded on the finding, not a default. If the credential is rotated and revoked, the value in history is inert and the rewrite is optional. If the repository is public, the value was exposed for an extended period, or the credential cannot be revoked (a long-lived token issued by a third party with no revocation API), a rewrite using git filter-repo or BFG Repo-Cleaner reduces residual exposure. Coordinate the rewrite with downstream forks because a force-push without coordination breaks every clone. Recording the decision on the finding keeps the closure honest about how complete the cleanup actually was.
How is the closure verified?
A follow-up code scan against the cleaned branch is the closure event. SecPortal re-runs Semgrep with the p/secrets ruleset against the post-cleanup commit and the result attaches to the same finding as a state event. If Semgrep no longer reports the secret, the finding moves to verified closed. If Semgrep still reports it (the cleanup landed on the wrong branch, the cleanup commit was reverted, the secret is now in a different file), the finding stays open and the next remediation cycle starts from the same record. Closure on plan does not satisfy the rule; only closure on a verification scan.
How do we handle false positives without muting the scanner?
Test fixtures, documentation samples, and high-entropy strings that are not credentials all surface alongside real leaks. The triage step classifies them as documentation sample (annotated in the source) or false positive (recorded with a suppression rule the next scan honours). The decision lands on the finding so the next match against the same pattern inherits the prior call automatically. Programmes that mute the scanner outright lose the next real leak; programmes that record the triage decision absorb the next match without re-deciding from scratch.
Where do leaked-credential detections fit alongside other AppSec findings?
Secret-scanning detections sit on the same engagement record as SAST, SCA, DAST, and authenticated-scanning findings. The rotation-and-revocation discipline is specific to credentials, but the lifecycle layer (detect, triage, route, remediate, verify, close) reads against the same record the rest of the AppSec programme already uses. The handoff between code-scanning detection and the engineering owner is a routing event on the security record rather than a parallel comment in a scanner UI.
How does AI report generation handle secret-incident narratives?
AI-generated reports derive the secret-incident narrative from the live engagement record. The detection event, triage decision, rotation history, revocation verification, history-cleanup scope, and verification scan land in the report draft as derived narrative rather than reauthored prose. The release owner edits the draft instead of writing from a blank page, and the headline numbers always reconcile to the underlying record because the report is generated from the same record the events live on.
Does SecPortal store the leaked credential value itself?
No. The finding records the file path, line number, secret category, and confidence score from Semgrep, plus the operator-entered fields like the new credential identifier and the issuing-system reference. The leaked value itself is not extracted into the finding record. The repository is cloned into an isolated container for the scan and the container is destroyed after the scan completes; no source code is retained on disk after the scan.
How it works in SecPortal
A streamlined workflow from start to finish.
Detect leaked secrets in source code with SAST
SecPortal runs Semgrep with the p/secrets ruleset against the connected repository on every code scan. The scan clones the repository into an isolated container, runs the rules over the working tree, and lands every match on the engagement record with the file path, line number, secret category (cloud key, database password, API token, OAuth client secret, signing key, generic high-entropy string), and a confidence score. The detection is the start of a clock that does not stop until the secret is rotated, the old value is revoked, and the verification scan confirms the leak is closed.
Triage detections into real leaks, test fixtures, and false positives
Not every Semgrep match is a live credential. Test fixtures, sample values in documentation, and high-entropy strings that are not credentials all surface alongside real leaks. The triage step decides which findings are live secrets that need rotation, which are documentation samples that need a comment annotation, and which are false positives that need a suppression rule the next scan honours. The decision lands on the finding with the named triager, the rationale, and the timestamp so the next quarter does not re-litigate the same call from scratch.
Rotate the live credential at the issuing system before any code change
Once a finding is confirmed as a live secret, the very first remediation step is rotation at the issuing system (the cloud provider IAM console, the database admin panel, the third-party API dashboard, the OAuth application, the signing key vault). Rotation produces the new value the application will use; revocation of the old value is a separate step. The rotation event lands on the finding with the named operator, the issuing-system ticket reference, the new credential identifier (never the value itself), and the timestamp so the rotation history reads as a state event rather than as a chat message lost to history.
Revoke the old value and verify it no longer authenticates
Revocation is the step that turns the leaked credential from a live attack tool into an inert string. After rotation, the previous value is explicitly revoked at the issuing system and a verification check confirms it no longer authenticates (an authentication request that should fail returns the expected denial, an audit log shows the credential as revoked, the cloud provider returns it as deactivated). Revocation without verification leaves the programme uncertain about whether the closure is real; verification without revocation closes the finding while the live credential still works.
Remove the secret from the code and from version control history
The committed secret is removed from the working tree and the developer pushes the cleanup commit. Removing the secret from the working tree alone is not enough; the value remains in the version control history, the pull request diff, the cached forks, and the build artefacts. The cleanup step decides whether a history rewrite (git filter-repo, BFG Repo-Cleaner, or the equivalent provider tool) is in scope, whether the repository needs to be force-pushed, whether developers and downstream forks need a coordinated re-clone, and whether the build artefact registry needs a purge. The decision lands on the finding so the remediation record reflects the chosen scope rather than implying a more complete cleanup than actually happened.
Re-scan the repository and verify the closure on the engagement record
A follow-up code scan against the cleaned branch confirms Semgrep no longer reports the secret. The verification scan attaches to the same finding as a state event, the closure moves to verified closed, and the activity log captures the chain of detect, triage, rotate, revoke, cleanup, and verify with timestamp and user attribution at each step. AI-generated reports derive the secret-incident narrative from the same record so leadership reads the closure verification rather than a hand-built status update.
Features that power this workflow
Run secret scanning remediation on the engagement record
Detect leaked credentials with Semgrep, route the finding to the named owner, rotate at the issuing system, revoke the old value, clean the repository, and verify the closure with a follow-up scan. One record, one trail, one proof. Start free.
No credit card required. Free plan available forever.