External actions and tasks used in CI/CD pipelines should be pinned to a specific, reviewed version to prevent supply chain compromise.
Using a third-party action, workflow, or task without pinning it to a specific, reviewed version means your pipeline could silently start running code that you have not reviewed. The upstream repository owner — or an attacker who gains write access — can change the action or task at any time, and your pipeline will automatically execute those changes.
Azure Pipelines can leverage tasks created by others from the Microsoft Marketplace. Tasks provided out of the box by Azure Pipelines, maintained by Microsoft in the azure-pipelines-tasks repository, are excluded from this rule. Although pinning those to a specific version would still benefit build reproducibility, they are generally considered trusted and are omitted here to reduce noise.
Since some third-party tasks come from parties you trust, for example your own organization, this rule can be configured to accept trusted task name prefixes so that they are not flagged.
If an attacker gains control of a third-party action or task, they can modify it to run malicious code inside your pipeline. This can result in the exposure of pipeline secrets, the modification of build artifacts, or the compromise of your deployment environment.
Pin third-party tasks to a specific, reviewed version number. To find the exact version number for a custom task, navigate to its page on the Visual Studio Marketplace and look for the version listed under the More Info section on the right side of the page.
You can use the trustedPrefixes parameter to configure which task name prefixes (for example, a prefix shared by your own
organization’s custom tasks) are trusted.
The following example pins only the major version of the task, allowing minor and patch updates to be pulled in automatically.
pool: vmImage: 'ubuntu-latest' steps: - task: SomeExampleTask@0 # Noncompliant
pool: vmImage: 'ubuntu-latest' steps: - task: SomeExampleTask@0.1.2