Complying with azurepipelines:S8263 when env vars aren't transmitted

Rules and Languages Report False-positive / False-negative...
1

Hi

I try to comply with the rule azurepipelines:S8263. Here is my task:

variables:
- name: system.debug
  value: $(SystemDebug)
- template: /.azuredevops/azure-pipelines/variables/deployment.yaml

- task: PowerShellOnTargetMachines@3
  displayName: 'Stop App scheduled task and process'
  inputs:
    Machines: 'MyMachineName'
    InlineScript: |
      $taskName = '${{ variables.scheduledTaskName }}'
      $processName = '${{ variables.deploymentProcessName }}'
      
      Stop-ScheduledTask -TaskName $taskName -ErrorAction SilentlyContinue | Out-Null
      
      $processes = Get-Process -Name $processName -ErrorAction SilentlyContinue     
      Write-Host "Stopping process '$processName'..."
      $processes | Stop-Process -Force
      
      Write-Host "Process stop completed."
    CommunicationProtocol: 'Http'

In a template file, I have my variables:

variables:
- name: deploymentProcessName
  value: 'MyProcess'
- name: scheduledTaskName
  value: 'MySchedTask'

According to the rule, I should use environment variables with env, but it doesn’t work. The environment variables do not seem to be transmitted on another machine with the PowerShellOnTargetMachines task.

What can I do to fix this ?

Version : SonarQube Server Developer Edition (2026.3.1)
Deployment : Docker

4

Hi!
Thank you for your feedback.
Indeed, for the PowerShellOnTargetMachines@3 task, the suggested env approach won’t work. The env block only affects the host agent starting the task, not the remote target machine where the PowerShell script actually executes.

For remote or non-shell tasks like this, we recommend using an allowlist of permitted values instead.

I will create a ticket to improve the rules description so that it is more clear that PowerShellOnTargetMachines@3 needs to be treated different than other shell tasks.

Thanks again for helping us improve!

6

One more follow up:
I only noticed now that in your template file you are actually using hard-coded values so in this case there is actually no risk and the issue raised is a false positive.

Currently we are not processing these template files correctly. I will create a separate ticket to prevent such false positives in the future.

Best,
Daniel

9

Thank you for your response, it confirms my suspicions.

Best,