A Secret is a programmatic access key that provides systems with access to information, services, or assets. Developers use secrets such as API keys, encryption keys, OAuth tokens, certificates, PEM files, passwords, and passphrases to empower their applications to securely communicate with other cloud services. These keys are often explicitly stored in local or feature branches before being pushed to a main branch.
Git-based Version Control Systems (like GitHub, GitLab) cannot store secrets securely, possibly creating vulnerabilities that can be exploited. Typically this happens when developers leave their secrets in the source code. Once a secret is committed into a Git repo, it is saved in its history forever and any user can easily see and use those keys. This is especially dangerous if a repository and its contents are made public, making that resource easily found and utilized by threat actors.
Bridgecrew is able to detect secrets in IDEs, Git-based VCS, and CI/CD executions.
Scanning for Secrets
Bridgecrew supports 100+ domain-specific secret detectors (policies), clustered under the Secrets category and scanned against all source code files in your repositories. These can detect specific types of secrets (e.g., AWS access keys), in addition to other scanning algorithms. Our detectors rely on open source contributions as well as in-house tweaks introduced by Bridgecrew Security Engineering.
Non-compliant policies found in the scan can be manually fixed (by pointing to where the error was detected) or suppressed.
Secrets errors are associated with code files can be viewed and analyzed in the following pages:
- Supply Chain - as part of exploring file nodes
- Resource Explorer - file area
Whenever the scan detects secrets within a file, an error box appears in the file level. Each line in the table represents a secret policy which is non-compliant with the scanned file.
To view secrets errors, in the Projects page, filter the search in your selected repository by Errors (Status) and Secrets (Category).
Each policy includes the following data:
- Secret type - policy name
- Policy severity
- Code line - where in the code the secret was detected
- Risk factors - including three parameters:
- The last Git user who modified the file and triggered a secret error detection
- Error date
- Whether the repository storing the file is public or private
Error properties can search using the Search function.
You can manually fix or suppress each policy.
To manually fix a policy:
- Select the policy error box.
- In the Resource Explorer pane, under the Errors tab, click Manual Fix.
The relevant commit opens in the VCS screen (e.g., GitHub), allowing you to fix the error immediately.
To suppress a secret error:
- Under the relevant file, select one or more policies.
Note that if you want to create a separate suppression rule for each policy, you need to select them one-by-one.
- Click Suppress.
A Suppression Rule box opens.
- Enter a justification for the rule and an expiration date (optional).
- Click SAVE.
The suppression rules you created are now detailed in the file box.
To delete a suppression rule, hover over the required rule and select Delete.
For a faster access to suppressed errors, in the left menu, filter by Suppressed, under Status.
Another way to suppress secret policies is to disable them entirely through the Policies page.
The Supply Chain page contains source code file nodes. Select a node to explore its Resource Explorer pane and review the open errors displayed under the Errors tab (see below).
The count of errors for a source code file is the sum of the errors in its children nodes and its own secret errors.
The Resource Explorer for source code files includes the following tabs:
a. Repository - repository name of the selected source code file
b. Path - file path
c. Last modified by - the last Git user who modified the file and triggered a secret error detection
- Errors - a dropdown menu of the policies in the selected source code file. The data for each non-compliant policy includes:
a. Recommendation - "Revoking the secret is the only way to ensure no attacker will access the involved service. If you leaked corporate credentials or credentials you cannot revoke by yourself, we highly recommend you get in touch with your security team."
b. Risk factors:
- Repo access - whether the repository storing the file is public or private
- Created by - the last Git user who modified the file and triggered a secret error detection
- Created on - error date
c. A Hidden code snippet where the error was detected
d. Manual fix - see above.
Secret Pull Request Comments
Users can spot potentially leaked secrets as part of their pull request scans, performed by Bridgecrew.
We highly recommend removing such a secret from your pull request.
Pull requests comments on secrets are not supported currently in BitBucket and BitBucket Server integrations.
You can manage your secret findings using Enforcement capabilities. With Enforcement, you can configure rules for Soft Fail or Hard Fail for code reviews or Pull request comments, based on severity level thresholds.
Updated 8 months ago