SaaS credential ownership
A key’s author has left. Who owns it now?
A name on a commit or document tells you where to start. It does not show who uses the key today. Cremit separates source evidence, an owner candidate and a person explicitly assigned to follow up.
Three different signals
Do not turn a source clue into a confirmed owner without review.
- 01
Observed author
A commit author or document editor is attached to a finding location. That person may not operate the service now.
- 02
Owner candidate
Cremit can suggest a person from available finding evidence. A linked inactive directory account is a reason to review, not proof that the key is unused.
- 03
Assigned owner
A person confirms responsibility and assigns the finding. This explicit assignment takes priority over a suggested candidate.
This is an explanatory evidence ladder, not a product screenshot. Available signals depend on the connected source and directory data.
Why the name can mislead
The source tells you who touched a file. The issuer and running service tell you what depends on the credential.
An old commit
The commit author may have left while a deployment still uses the key. Check the issuer account, deployment owner and supported validity result.
A shared document
The last editor of a file might have copied a credential for someone else. Ask the service owner before treating the editor as responsible for rotation.
A bot or shared account
An automation account may write the commit while a different person maintains the integration. Record a responsible human or team explicitly.
Move from clue to action
If a sensitive key is clearly exposed, containment at its issuer should not wait for a perfect ownership history.
- 01
Find the dependency
Identify the source, issuing service and workload that uses the credential. Check whether the observed author, suggested candidate and current operator are different people.
- 02
Assign and contain
Assign a current responder. For a clearly exposed key, arrange rotation or revocation at its issuer without waiting for a complete ownership history, and update dependent services.
- 03
Check and record the result
Use issuer-side validity results where Cremit supports them. For AWS access keys and GCP API keys, inspect available permission context with the required integration; review issuer logs for use. Record the action and recheck supported key status.
What the signals do not prove
A review is only as complete as the sources and account status available to it.
- A commit author, document editor or suggested owner is not automatically the person who controls the credential today. Explicit assignment resolves responsibility for follow-up.
- An inactive directory-linked account shows that account state when a match and sync exist. It does not show whether the key is still working or was misused.
- Validity checks apply to supported credential types. AWS/GCP permission analysis needs the relevant integration; other issuers require their own permission and log review.
- Rotation-age reporting covers synced AWS Secrets Manager secrets under a configured policy. Cremit does not rotate or revoke issuer credentials for you.