Skip to content
All posts

Security for Bitbucket config is now loaded from the default branch

Soteri’s Security for Bitbucket offers an option to customize the configuration of scans on a per-repository basis using a YAML file placed at the root of the repository. This flexibility can provide a lot of benefits for repositories which have a lot of binary data, or require custom rules to detect potentially sensitive content.

Starting with Security for Bitbucket 3.10.0, we’re making a behavior change which loads the per-repository config file, soteri-security.yml, from the latest commit of the default branch of the repository. In prior versions, the file was loaded from the commit being scanned.

We’re making this change to make it significantly easier to use per-repository configuration — updates can be made to one file, and that change applies to all branches, even if those branches predate adoption of Security for Bitbucket. This means that every scan is done with the most up to date configuration.

An important side effect of this change is that scans can now become out of date even if that commit hasn’t changed, either if soteri-security.yml changes, or per-repository rules are enabled/disabled in global settings. Security for Bitbucket detects these change, will now display those scans as outdated in the global dashboard. These out of date branches can then be scanned as you normally would.

Making a change to soteri-security.yml in the default branch when per-repository rules are turned on makes all scans in that repository out of date.

When Security for Bitbucket 3.10.0 is first installed, no scans will be considered out of date. If you want to kick-start this new behavior in repositories where you’re using per-repository configuration, hit the “re-scan” button for that repository. Otherwise, as new commits roll in and get scanned, they’ll get scanned with the most up to date per-repository configuration.

As always, reach out with questions, bug reports, and suggestions in our support portal.