From exposed credentials to Cremit Platform: the workflow we support

Updated October 3, 2026. The earlier version of this article described automatic owner inference, behavior monitoring, and product development history that we could not substantiate against the current implementation. Here is the problem Cremit Platform addresses and the work it actually supports today.

The problem starts before an incident

An API key can end up in a repository, a chat message, a shared document, or a storage bucket. Removing the visible copy is not enough if the key still works. The team needs to know where it appeared, whether it is valid, who owns the service, and who can rotate it without breaking production.

Our NHI Kill Chain series discusses several ways credentials become difficult to manage: forgotten keys, keys copied across systems, long-lived access, and secrets in public code. Those labels are editorial ways to examine risk. They are not automatic classification modes in Cremit Platform.

The current product workflow

First, connect the sources you want to inspect. Cremit Platform supports GitHub, GitLab, Bitbucket, GitHub Packages images, AWS S3, Google Drive, Jira, Confluence, Notion, and Slack. The GitHub App can check new pull requests when they arrive. Other connected sources are scanned on a schedule. The platform can also inspect supported external exposure surfaces approved by the organization.

Second, review the credential finding. Detection rules cover more than 1,000 types. A string that matches a pattern is not automatically a working key. For supported types, Cremit checks validity with the issuing service and re-verifies live findings on a schedule. Other types remain available for manual review. AWS and GCP permission analysis can add context for supported cloud keys.

Third, route the work. A finding records its source and can be assigned an owner, given a priority and status, and sent through configured Slack, webhook, Telegram, or email alerts. The owner rotates or revokes the credential at its issuing service and checks relevant activity. For a supported type, a later verification can show that the old key no longer authenticates. The platform does not perform the rotation itself.

What the workflow does not establish

The current product does not infer every owner from commit history, HR records, or CI/CD configuration. It does not watch all API calls or learn a behavioral baseline for every identity. It does not trace the full path a secret took through systems or certify that every copy has been removed. Those questions require the identity provider, source history, logs, and the team that runs the service.

A useful first trial is a source you control and a test credential that can be safely rotated. Check the connector permissions, scan timing, finding detail, owner assignment, alert, and final verification. That small exercise shows whether the workflow fits your incident process without claiming more coverage than the connected sources provide.