Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure

Product workflow guide

Follow one credential from finding to follow-up

Follow a key through validity checks, ownership assignment, issuer-side action and a follow-up check. The actual product interface illustrates each step with one fictional AWS key.

Open the interactive tourReal product, sample data. No sign-up.
  1. 01Find in connected sources
  2. 02Check supported validity
  3. 03Review AWS and GCP access
  4. 04Assign, act, and recheck

What happens after you find a key?

Follow one fictional AWS key found in GitHub. See the evidence at each step and the next action for its owner.

Actual product components with fictional records. Verification and ownership states illustrate the workflow; they are not customer results or a live scan.

  1. 1 / 4

    Start with the key and its location.

    This key was found at line 12 of config/example.env in the example-app repository. Its validity is initially unknown. The author is a lead for finding the responsible person.

    Next: inspect the finding location and check verification results for supported credential types.

    AWS Access Key
    AWSUnverifiedNot in a connected vault
    aws_access_key_id: EXAMPLE••••••••••••
    aws_secret_access_key: ••••••••••••••••

  2. 2 / 4

    Distinguish a working key.

    In this example, an AWS issuer check returned an active result. It establishes that authentication worked at the time of the check. Actual use still needs issuer activity logs.

    Next: review the exposure and identify the person who can act at the issuer.

    AWS Access Key
    AWSValidNot in a connected vault
    aws_access_key_id: EXAMPLE••••••••••••
    aws_secret_access_key: ••••••••••••••••

  3. 3 / 4

    Confirm who will respond.

    An author candidate is not automatically the owner. Once your team confirms and assigns a person, responsibility is visible alongside the credential.

    Next: the owner checks dependent services, then replaces or revokes the key at its issuer.

    AWS Access Key
    AWSValidNot in a connected vault
    aws_access_key_id: EXAMPLE••••••••••••
    aws_secret_access_key: ••••••••••••••••
    Owner
    Example owner
    security@example.com
    Assigned

  4. 4 / 4

    Check removal and revocation separately.

    The final example shows a failed authentication check after the owner revoked the key at its issuer. Removing the string from code alone does not revoke a credential.

    Close out: review source cleanup, issuer-side action, recheck results and activity logs together.

    AWS Access Key
    AWSInvalidNot in a connected vault
    aws_access_key_id: EXAMPLE••••••••••••
    aws_secret_access_key: ••••••••••••••••

Unsupported credential types and checks with missing inputs require manual review. The responsible person replaces or revokes credentials at the issuer.

Review permissions and data handlingBuild an investigation record

The five editorial diagrams below explain each feature’s data flow. They supplement the product interface examples above.

01

Secret scanning

Find exposed credentials and their locations in connected sources.

  • Scan connected GitHub, GitLab, Bitbucket, S3, Google Drive, Slack, and other supported sources.
  • Use detection rules for 1,000+ credential types.
  • A pattern match is separate from validity; some types require manual review.
Explore Secret scanning

Workflow diagram

Discovery and verification are separate decisions

01 / 05
  1. 01

    Input

    Connected scan sources

    The scan reads only the repositories and tools connected by the organization.

  2. 02

    Finding

    Credential pattern and location

    A matching string alone does not prove the key still works.

  3. 03

    Check

    Validity for supported types

    Unsupported types remain for manual confirmation at the issuer.

A completed scan does not prove that unconnected systems contain no secrets.
02

External scanning

Find public assets from a registered seed, monitor supported discoveries, and review each check’s coverage.

  • Register a domain, website, IP, mobile app, or GitHub organization.
  • Use public certificates, DNS, and related links as evidence for candidate assets.
  • Eligible discoveries can enter monitoring automatically; exclude out-of-scope assets. Content checks have separate settings.
Explore External scanning

Workflow diagram

From registered seed to monitored scope

02 / 05
  1. 01

    Seed

    Asset registered by the organization

    A domain or GitHub organization can start discovery.

  2. 02

    Discovery

    Related asset and attribution evidence

    Public information helps the owner judge each candidate.

  3. 03

    Monitoring

    Eligible discoveries enter monitoring

    Exclusions and organization settings determine which checks run.

External scanning depends on organization settings and asset type. A clean result covers only inspected material.
03

Identity inventory

Review locations, verification status, ownership, and access one credential at a time.

  • Group credentials and locations discovered in connected sources.
  • Distinguish a suggested owner from confirmed ownership and flag unassigned keys.
  • Review permission analysis for supported AWS access keys and GCP API keys.
Explore Identity inventory

Workflow diagram

One credential, several clues

03 / 05
  1. 01

    Location

    Where was it found?

    Review findings in connected sources.

  2. 02

    Owner

    Who is responsible?

    A suggested owner is distinct from a confirmed assignment.

  3. 03

    Access

    What can it reach?

    Review supported AWS and GCP key permission analysis.

Permission analysis depends on credential type and integration state. It does not establish misuse.
04

Response tracking

Route findings through alerts and incidents and record the follow-up.

  • Recheck supported live credentials on a schedule and review changed status.
  • Record an owner and progress through alerts and incidents.
  • The owner rotates or revokes the key at its issuer; a status update alone does not revoke it.
Explore Response tracking

Workflow diagram

The issuer is where the key changes

04 / 05
  1. 01

    Alert

    Discovery and status changes

    Review configured channels and incident records.

  2. 02

    Owner

    Check service dependencies

    Plan the order of replacement and old-key revocation.

  3. 03

    Recheck

    Issuer state and rescan

    Compare supported validity checks with connected-source rescans.

Cremit does not rotate, revoke, or delete a customer key on their behalf.
05

Risk signal review

Consider validity, public exposure, permissions, and owner state separately.

  • Look at supported validity checks together with discovery locations.
  • Review access scope for AWS and GCP keys where analysis is available.
  • Confirm the owner and continued need of keys linked to departed or inactive accounts.
Explore Risk signal review

Workflow diagram

Risk needs more than one badge

05 / 05
  1. 01

    Validity

    Does the key still work?

    Review supported verification results and their time.

  2. 02

    Exposure

    Where is it visible?

    Distinguish public locations from connected internal sources.

  3. 03

    Impact

    What access and owner are known?

    Review supported permission analysis and ownership status.

Finding a live key does not prove that it was used or compromised.

See the actual product

Try it with your own sources. Start with 2 GB of free scanning per month, or review your integration scope and response process in a demo.

Open the interactive tourStart for freeBook a demo