Azure DevOps

What are the benefits of the Azure DevOps integration?

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).

How do I enable the new Azure DevOps functionality?

  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
      Screenshot 2024-10-04 at 3.11.51 PM.png
  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.
    Screenshot 2024-10-04 at 3.08.24 PM.png
  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.

How to set 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.

What API permissions does this integration 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:

Scope Name Description
vso.code Code (read) Grants the ability to read source code and metadata about commits, changesets, branches, and other version control artifacts. Also grants the ability to search code and get notified about version control events via service hooks.
vso.project Project and team (read) Grants the ability to read projects and teams.
vso.graph Graph (read) Grants the ability to read user, group, scope, and group membership information.
user_impersonation Part of .default scope https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#the-default-scope
offline_access MS OpenID Connect Gives your app access to resources on behalf of the user for an extended time. App can receive refresh tokens from the Microsoft identity platform token endpoint.
vso.profile User profile (read) Grants the ability to read your profile, accounts, collections, projects, teams, and other top-level organizational artifacts.

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:

Screenshot_from_2022-03-22_22-01-28.png

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

What API fields does this integration pull?

Resources Scope/Permission Reference URL & Fields
Users
mailAddress
displayName
domain
descriptor
vso.graph https://docs.microsoft.com/en-us/rest/api/azure/devops/graph/users/list?view=azure-devops-rest-6.0
Repositories
id
name
url
project.id
project.visibility
vso.code https://docs.microsoft.com/en-us/rest/api/azure/devops/git/repositories/list?view=azure-devops-rest-6.0
Branches (Refs)
name
vso.code https://docs.microsoft.com/en-us/rest/api/azure/devops/git/refs/list?view=azure-devops-rest-6.0
Branch Policies (Policy Configuration)
id
type.displayName
isEnabled
isBlocking
isDeleted
settings.minimumApproverCount
settings.statusName
overCount
vso.code https://docs.microsoft.com/en-us/rest/api/azure/devops/git/policy-configurations/get?view=azure-devops-rest-6.0
Pipelines
name
id
accessToken https://docs.microsoft.com/en-us/rest/api/azure/devops/pipelines/pipelines/list?view=azure-devops-rest-6.0
Pipeline Runs
variables
name
system.pullRequest.sourceBranch
system.pullRequest.sourceBranch.value
accessToken https://docs.microsoft.com/en-us/rest/api/azure/devops/pipelines/runs/list?view=azure-devops-rest-6.0
Repository Pull Requests
title
pullRequestId
createdBy.uniqueName
reviewers
reviewers.vote
reviewers.uniqueName
labels
labels.name
status
mergeStatus
creationDate
closedDate
sourceRefName
targetRefName
vso.code https://docs.microsoft.com/en-us/rest/api/azure/devops/git/pull-requests/get-pull-requests?view=azure-devops-rest-6.0
Pull Request Statuses
state
context
context.name
vso.code https://docs.microsoft.com/en-us/rest/api/azure/devops/git/pull-request-statuses/list?view=azure-devops-rest-6.0
Accounts
value
value.accountName
vso.profile https://docs.microsoft.com/en-us/rest/api/azure/devops/account/accounts/list?view=azure-devops-rest-6.0
Profiles
id
displayName
emailAddress
coreRevision
timeStamp
revision
vso.profile https://docs.microsoft.com/en-us/rest/api/azure/devops/profile/profiles/get?view=azure-devops-rest-6.0

 

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.

 

Was this article helpful?

Have more questions? Submit a request

Comments

0 comments

Article is closed for comments.