What are the benefits of the Bitbucket integration?
Our Bitbucket integration automates compliance checks and evidence collection for five requirements:
- Production branches require new changes to undergo at least 1 independent approval prior to merge.
- Individual pull requests have at least 1 independent approval prior to merging into production branches.
- Individual pull requests undergo static application security testing (SAST) prior to merging into production branches.
- Individual pull requests undergo integration testing prior to merging into production branches.
- Individual pull requests undergo dependency checks prior to merging into production branches.
In order to take advantage of our Bitbucket integration, you must being using a pull request development model (rather than a direct commit to master model).
How do I enable the new Bitbucket functionality?
- Within "Company Monitoring" navigate to "Asset Inventory" > "Version Control"
- Click into each repository in audit scope and configure your testing settings accordingly to take advantage of our automated test and evidence collection functionality
- We ask you to provide the following values where applicable:
- Production branch names(s)
- Note: In order to add a production branch, the branch must have at least one pull request merged in
- Integration testing solution(s)
- SAST solution(s)
- Dependency checking solution(s)
- Production branch names(s)
- If you wish to apply these values to the fields in other repositories, check the respective "apply to" box and the fields will copy over to all other repositories in audit scope and specific to Bitbucket
- Note: If you do not fill out one of the fields, that associated test will not run, and it will fail with a note about a configuration issue
- We ask you to provide the following values where applicable:
- You can also set the testing starting date for Bitbucket by navigating to "Integrations" > "Bitbucket" > "Settings". This date defaults to the date that you connected Bitbucket in Secureframe. It can be useful to shift this date forward, especially if you do not have proper compliance configurations in place at the time of connecting Bitbucket. More information can be found here about how to configure the date. This date is tied to the pull request merge date.
What API permissions does this integration request?
Our integration uses OAuth to authenticate our app for REST API access to Bitbucket resources. Bitbucket's API applies a number of privilege scopes to endpoints. In order to access an endpoint, a request will need to have the necessary scopes. These scopes provides secureframe the permissions to access the resources on behalf of this authorization. You can see details for the available scopes from Bitbucket here.
The set of scopes/permissions we request from this integration are:
Scope | Permission Details |
Ability to see the user's primary email address. This should make it easier to use Bitbucket Cloud as a login provider to add-ons or external applications. | |
account | Ability to see all the user's account information. Note that this does not include any ability to mutate any of the data. + see all email addresses + language + location + website + full name + SSH keys + user groups |
repository | Gives the add-on read access to all the repositories the authorizing user has access to. Note that this scope does not give access to a repository's pull requests. + access to the repo's source code + clone over https + access the the file browsing API + download zip archives of the repo's contents the ability to view and use the issue tracker on any repo (created issues, comment, vote, etc) + the ability to view and use the wiki on any repo (create/edit pages) |
project | Read your workspace's project settings and read repositories contained within your workspace's projects. |
pullrequest | Gives the add-on read access to pull requests. This scope implies repository, giving read access to the pull request's destination repository. + see and list pull requests + create and resolve tasks |
snippet | Gives the add-on read access to all the snippets the authorizing user has access to. No distinction is made between public and private snippets (public snippets are accessible without any form of authentication). + view any snippet + create snippet comments |
issue | Ability to interact with issue trackers the way non-repo members can. This scope does not imply any other scopes and does not give implicit access to the repository the issue is attached to. + view, list and search issues + create new issues + comment on issues + watch issues + vote for issues |
pipeline | Gives read-only access to pipelines, steps, deployment environments and variables. |
These permissions will be set after successful integration with Secureframe.
You can view these from workspace settings > OAuth consumers > select Secureframe consumer and click edit.
What API fields does this integration pull?
Why are Checks (pipeline steps) I can see in Bitbucket Pipelines not showing up in Secureframe?
We look for step names from bitbucket pipeline steps API. If step names are not defined, bitbucket shows default step names e.g. "Step 1" but does not return that in the API response. Its only available when its defined in your `bitbucket-pipelines.yml` like this.
You should see these checks populated in dropdowns of the respective repository settings page in secureframe.
Comments
0 comments
Article is closed for comments.