“One Ring to rule all of them, One Ring to seek out them, One Ring to deliver all of them, and within the darkness bind them.”
– J.R.R. Tolkien, The Lord of the Rings
On this planet of code scanning and dependency scanning, your pipeline is the One Ring—a single definition that may orchestrate scans throughout a number of repositories. Nevertheless, very similar to the One Ring, if misused, it may result in chaos: publishing outcomes to the unintended repository.
Worry not, courageous developer! This information will present you how you can wield your pipeline correctly in order that CodeQL scanning outcomes and Dependency Scanning outcomes are at all times revealed to the meant repository.
The Downside: Outcomes NOT Going to the Supposed Repository
Think about this: your Azure DevOps pipeline resides in a single repository (let’s name it the PipelineRepo, the place the pipeline definition lives), whereas the supply code you need to scan lives in one other repository (let’s name it the SourceRepo, which incorporates the code to investigate).
With out correct configuration, your scan outcomes would possibly find yourself being revealed to the PipelineRepo as a substitute of the SourceRepo. This conduct happens as a result of the AdvancedSecurity-Dependency-Scanning, AdvancedSecurity-Codeql-Analyze, and AdvancedSecurity-Publish (collectively known as Superior Safety Construct Duties hereafter) publish the SARIF file with scan outcomes to the repository that triggered the pipeline run (which may be the repository containing the pipeline definition).
To make sure your outcomes at all times go to the meant repository, let’s dive into how you can configure your pipeline correctly.
The Resolution: Use Inferred Publishing (Most well-liked Methodology)
The advisable means to make sure that CodeQL scanning and dependency scanning outcomes are revealed to the meant repository is to make use of inferred publishing. By setting the advancedsecurity.publish.repository.infer pipeline variable to true, the Superior Safety Construct Duties will robotically detect the repository based mostly on the present working listing throughout the pipeline run.
Instance of Inferred Publishing
Right here’s how you can configure your pipeline for inferred publishing:
set off:
- predominant
sources:
repositories:
# PipelineRepo: The repository containing the pipeline definition.
# That is elective and solely wanted should you plan to reference information or scripts from this repo.
- repository: PipelineRepo
sort: git
title: DevOpsPipelineRepo
ref: refs/heads/predominant
set off:
- predominant
# SourceRepo: The repository the place scanning and publishing will happen.
- repository: SourceRepo
sort: git
title: code-to-analyze-repo
ref: refs/heads/predominant
set off:
- predominant
jobs:
- job: "CodeQLScan"
displayName: "CodeQL Scanning with Inferred Publishing"
variables:
# Allow repository inference
advancedsecurity.publish.repository.infer: true
steps:
# Checkout the SourceRepo
- checkout: SourceRepo
# Initialize CodeQL
- job: AdvancedSecurity-Codeql-Init@1
displayName: "Initialize CodeQL"
inputs:
languages: "python,javascript" # Regulate based mostly on repository languages
# Carry out CodeQL evaluation
- job: AdvancedSecurity-Codeql-Analyze@1
displayName: "Analyze Code with CodeQL"
Dealing with Errors with Inferred Publishing
In some circumstances, inferred publishing would possibly throw an error if the pipeline can not decide a sound Git repository within the present working listing. This sometimes occurs in multi-repo situations, the place a number of repositories are checked out.
Right here’s how you can deal with it:
Error Message
You would possibly encounter an error like:
“No legitimate Git repository discovered within the working listing.”
This error happens as a result of the Superior Safety Construct Duties can not decide which repository to affiliate the outcomes with.
Resolution: Use workspaceRepo: true
By default, CodeQL makes use of the present working listing to find out the repository for publishing outcomes. Nevertheless, in situations the place a number of repositories are checked out, this may result in ambiguity. Setting workspaceRepo: true explicitly identifies the repository you need to analyze and publish outcomes for.
Instance: Multi-Repo Checkout with workspaceRepo: true
set off:
- predominant
sources:
repositories:
# PipelineRepo: The repository containing the pipeline definition.
# That is elective and solely wanted should you plan to reference information or scripts from this repo.
- repository: PipelineRepo
sort: git
title: DevOpsPipelineRepo
ref: refs/heads/predominant
# SourceRepo1: The repository the place scanning and publishing will happen.
- repository: SourceRepo1
sort: git
title: code-to-analyze-repo
ref: refs/heads/grasp
# SourceRepo2: The repository the place scanning and publishing will happen.
- repository: SourceRepo2
sort: git
title: code-to-analyze-repo
ref: refs/heads/grasp
jobs:
# Job 1: CodeQL Scanning for SourceRepo1 with workspaceRepo set to true
- job: "CodeQLScanSourceRepo1"
displayName: "CodeQL Scanning for Juice Store"
variables:
advancedsecurity.publish.repository.infer: true
steps:
- checkout: SourceRepo1
workspaceRepo: true
- job: AdvancedSecurity-Codeql-Init@1
inputs:
languages: "javascript" # Regulate based mostly on SourceRepo1 languages
enableAutomaticCodeQLInstall: true
- job: AdvancedSecurity-Codeql-Analyze@1
displayName: "Analyze Code with CodeQL"
# Job 2: CodeQL Scanning for SourceRepo2 with workspaceRepo set to true
- job: "CodeQLScanSourceRepo2"
displayName: "CodeQL Scanning for Benchmark (No Construct Mode)"
variables:
advancedsecurity.publish.repository.infer: true
steps:
- checkout: SourceRepo2
workspaceRepo: true
- job: AdvancedSecurity-Codeql-Init@1
displayName: Initialize CodeQL
inputs:
languages: "java" # Regulate based mostly on SourceRepo2 languages
buildtype: "none"
- job: AdvancedSecurity-Codeql-Analyze@1
displayName: Carry out CodeQL Evaluation
This configuration ensures that the repository designated with workspaceRepo: true is analyzed and that outcomes are revealed to the right repository. For extra particulars, seek advice from the Azure DevOps multi-repo checkout documentation and the checkout step documentation.
This Additionally Applies to Pipeline Dependency Scanning
Whereas this information focuses on CodeQL static evaluation, you can even use inferred publishing for Dependency Scanning, which identifies vulnerabilities in your undertaking’s dependencies.
Right here’s how you can configure your pipeline:
set off:
- predominant
sources:
repositories:
# PipelineRepo: The repository containing the pipeline definition.
# That is elective and solely wanted should you plan to reference information or scripts from this repo.
- repository: PipelineRepo
sort: git
title: DevOpsPipelineRepo
ref: refs/heads/predominant
set off:
- predominant
# SourceRepo: The repository the place scanning and publishing will happen.
- repository: SourceRepo
sort: git
title: code-to-analyze-repo
ref: refs/heads/predominant
set off:
- predominant
jobs:
- job: "DependencyScan"
displayName: "Dependency Scanning with Inferred Publishing"
variables:
# Allow repository inference
advancedsecurity.publish.repository.infer: true
steps:
# Checkout the SourceRepo
- checkout: SourceRepo
# Carry out Dependency Scanning
- job: AdvancedSecurity-Dependency-Scanning@1
displayName: "Analyze Dependencies for Vulnerabilities"
With dependency scanning, If you wish to scope your scan to a particular folder, you may set a pipeline variable DependencyScanning.SourcePath to any listing file path within the construct agent that you just need to analyze.
For extra info, see Adjusting your scanning listing with Dependency scanning.
One Pipeline to Rule Them All
Inferred publishing is the go-to alternative, providing a streamlined configuration that minimizes errors and offers clear steering when challenges come up. By adopting these finest practices, you may be sure that CodeQL and Dependency Scanning outcomes are at all times directed to the meant repository. The flexibility to seamlessly handle your code scanning workflows is now inside your grasp.
Extra Sources
“Even the smallest individual can change the course of the long run.”
Begin small by configuring your pipeline appropriately, and also you’ll see a big effect in your crew’s safety workflows.
To be taught extra about different upcoming Azure DevOps investments in safety and past, see Azure DevOps Roadmap.
