Soteri Scanning found a password. Now what?

Nobody installs Soteri’s Security for Bitbucket or Security for Confluence Cloud hoping to find a an improperly stored password or an accidentally committed API key. Yet our customers know that this is an all too common occurrence. It’s very possible that in the near future, you’ll run a Soteri Security Scan, and have a scan finding. Now what?

The best case scenario is it that the finding is a false positive. In Security for Bitbucket, you have several options to hide the result from the scan report:

• Mark the finding as reviewed.
• Use an allow-list pragma
• Use per-repository rules to ignore the file altogether

More often, Soteri Security Scans findings are not false positives. All found secrets should be considered to be completely compromised. Once a commit is committed to Bitbucket, or a page is published to Confluence, anyone who had access could have a copy. Scrubbing the secret from git or page history doesn’t sufficient remediate risk.

Soteri has a list of recommended actions when there’s a finding:

• Change the secret.
• If a password is found, change it.
• If an access token is found, generate a new access token, and update your services to use the new token. Once all your services have been updated, revoke the old token.
• Delete the secret from the confluence page or git repository. Revoked or not, users seeing previously improperly stored secrets might get the impression that this is an acceptable way to store passwords and other API keys.
• If you’re using Security for Bitbucket, enable the included pre-commit hook. This is the best way to ensure that secrets don’t end up in Bitbucket again.