Integration Benefits

Our Azure DevOps integration automates compliance checks and evidence collection for five requirements:

1. Production branches require new changes to undergo at least 1 independent approval prior to merge
2. Individual pull requests have at least 1 independent approval prior to merging into production branches
3. Individual pull requests undergo static application security testing (SAST) prior to merging into production branches
4. Individual pull requests undergo integration testing prior to merging into production branches
5. Individual pull requests undergo dependency checks prior to merging into production branches

In order to take advantage of our Azure DevOps integration, you must being using a pull request development model (rather than a direct commit to master model).

Connecting the integration

Navigate to the Integration

1. Go to the Integrations page in Secureframe.
2. Search for Azure DevOps in the "Available Integrations" list. (If you have the Custom Integration feature, click on Add native connection). 
3. Click Connect.

Select Secureframe OAuth App or Your Own App Registration

How to connect 

When setting up your integration, you’ll be prompted to choose between two connection methods:

Option 1: Secureframe OAuth App

Use this option for the fastest and most streamlined setup.

• Click Connect via Secureframe OAuth App
   
• Sign in with an admin account that has the necessary permissions
• Review and approve the requested permissions to complete the setup

Option 2: Your Own App Registration

Secureframe now supports an alternate workflow for connecting Azure DevOps. This option is designed for organizations that prefer to limit Secureframe’s access more narrowly when establishing connections.

Use this option if your organization prefers greater control over permissions and access scopes, or if you use Privileged Identity Management (PIM) tools.

• Click Connect via your own App Registration
   
• Follow the guided steps in Secureframe to register your own app within your identity provider or cloud platform
• Enter the app credentials (Client ID, Secret, and Tenant/Directory ID, if applicable) to finalize the connection

Enabling Azure DevOps

1. Within "Company Monitoring," navigate to "Asset Inventory" > "Repositories"
2. 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
     • Emergency label
       • Note: Secureframe will not apply checks to pull requests with this label
     • Integration testing solution(s)
     • SAST solution(s)
     • Dependency checking solution(s)
   • 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
     
3. You can also set the testing starting date for Azure DevOps by navigating to "Integrations" > "Azure DevOps" > "Settings". This date defaults to the date that you connected Azure DevOps 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 Azure DevOps. More information can be found here about how to configure the date. This date is tied to the pull request merge date.
   
4. You can set default configurations for new repositories that are added. 
5. A build validation policy is required for all in scope repos. See below for instructions on how to set it up.

Setting up a build validation policy

Build validation policy is needed to extract detailed information for pull requests and the pipeline runs.
To setup a build validation policy, follow these steps:

1. Goto to the selected Azure DevOps repository after login.
2. Goto "Branches" from the left sidebar menu.
3. Click on "Branch Policies" under the 3 dots dropdown menu against the main branch.
4. Click on the (+) icon to add a new Build Policy under Build Validation Section.
5. Fill and save the Build Policy form.

See more details on build validation policy here.

API permissions request

Our integration uses OAuth to authenticate our app for REST API access to Azure DevOps resources. This authorization request uses scopes that determines permissions for resources that will be accessed in this integration. See more.

The set of scopes we require for read permissions for this integration:

Once the connection is configured, you will be able to see our app with required permissions from the settings page in your profile: https://app.vssps.visualstudio.com/profile/view

Under Authorizations section, click Manage Authorizations and you will see an authorization similar to this example:

By default, a user with administrator role who has authorized for this connection will have all the required permissions needed for this sync. Just make sure at least all the read permissions are enabled for the groups in "[Your Project]" > "Settings" > "Repositories" > "Security" tab.

While logged in to https://dev.azure.com/ make sure "Third-party application access via OAuth" is turned on by navigating to "Organization Settings" > "Policies"

Reference

API fields used

Frequently Asked Questions (FAQ)

We have already specified that main is the only branch with production code in the Azure Devops integration settings. How does a branch get designated as production code?

• In Secureframe there are two locations where the system is informed about the production branch to monitor.
  1. The first is at the integration level, located on the far right side of the screen by clicking on the Settings button.
  2. The second is at the repository level within the asset inventory. Configuring the branch in the integration settings negates the necessity to configure it at the repository level; however, it is possible to configure a different branch at the repository level, which will then be taken into account.

What if I want to narrow the access granted to Secureframe to enable this integration? 

• For organizations with limited audit scopes or who use PIM (Privileged Identity Management) tools, we offer an alternate way to connect the Azure DevOps integration via an application registration. Please connect with success@secureframe.com to have this enabled for your instance. 

Why aren’t my code testing checks appearing in Secureframe?

• Secureframe only ingests test results at the pipeline level.
  If your pipelines contain multiple jobs or stages, Secureframe will not map those individual steps.

Why does the “Static Code Analysis Test Names” field accept freeform text, but the repository field only shows fixed options?

• The project-level integration accepts freeform input, but the repository configuration shows a pipeline picker because Secureframe only supports pipeline names. Stage/job names are not supported.

Can Secureframe detect SonarCloud or other scanners when each repo has unique pipelines or monorepo paths?

Not automatically. When pipelines differ per repo or per path:

• Pipeline-level validation may not be feasible
• Evidence upload is the correct workaround
• This method is fully acceptable for SOC 2 Type 1 & Type 2

Azure DevOps shows passing checks on our PRs, but Secureframe does not match them to our tests. We named jobs in one place but only see pipeline names in another. What is going on?

• Secureframe needs configuration that matches how it reads Azure DevOps (often pipeline-level naming in repository settings), which may not match how your team names individual jobs or steps inside a pipeline. Global integration settings and per-repository settings can also differ. If those do not align with what the product expects, checks can look “missing” even when Azure DevOps is healthy. Align naming and settings with the product’s expectations, or use alternate evidence (such as uploads) if your branching model cannot be expressed in the standard way.

We see failing code or security test results for Azure DevOps even when the PR pipeline succeeded. Is the integration broken?

• Not always. Azure DevOps drops older builds based on retention. If Secureframe tries to read a build that is no longer there, you can see failures that do not match the current green state of a new PR. Check whether the failures line up with older PRs or builds that may have aged out of retention before assuming a live sync error.