fortify/gha-setup-scancentral-client

ScanCentral for Windows Runners not able to find MSBuild

Closed this issue · 3 comments

Deleted user commented

After some research, I was able to translate and run the example provided as a workflow for Fortify on Demand on a Windows runner.
Starting some tests with GitHub-hosted runners and using "windows-latest" runners we were facing an issue with the scan central tool, after adding a task to be able to see the output log. I was getting the following:

#scancentral.log
#first error detected:
2021-11-26 11:42:32,427 [WARN] com.fortify.cloud.cli.util.ArgHelper - C:\hostedtoolcache\windows\scancentral\21.1.2\x64\Core\config\scancentral.properties 
(The system cannot find the file specified)

#second error:
2021-11-26 11:42:47,353 [ERROR] com.fortify.cloud.cli.util.ProcessRunner - 
java.io.IOException: Cannot run program "msbuild.exe": CreateProcess error=2, The system cannot find the file specified

#third:
2021-11-26 11:42:47,372 [ERROR] com.fortify.cloud.cli.Main - Error generating scan specification
com.fortify.cloud.cli.exceptions.CommandException: Error generating scan specification

#and finally:
2021-11-26 11:42:47,373 [INFO] com.fortify.cloud.cli.Main - Shutting down with errors.

First I was reviewing this full log, to check if all files used were in place, all temp and static files used by MSBuild or scan central were looking good.

The next step was to simulate what the agent is doing, download the tool, run some commands and expect some answers.
The good thing was, that I was able to recreate the issue, running the scan central tool just with some PS scripts I was getting the same errors. cool!

So here started to realize what was the issue. After installing VS 2019 and VS Tools 2022 I just saw that it doesn't matter which tool you install, it seems you cannot run directly MSBuild.exe commands even with this previous software installed. If you want to run MSBuild.exe commands you have the "VS Developer Command Prompt" included, but if you really want to run any MSBuild command you should add directly on your PATH env var in Windows, the bin folder where the exe is placed.

The last try was to add my local computer as a runner (sorry cyber-sec it was just for test purposes). This gave me the opportunity to play a lot with it and to add into my PATH environment variable the value "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin" which contains my local VS Tools 2022's MSBuild version. This made me possible to run a scan successfully for this FoD workflow PoC using a net core 3.1 project.

It's curious, the jar running this process is not able to find the MSBuild in the environment but the task output is showing correctly the version installed in the agent/runner.

Log files will be stored in "C:\Users\<user>\AppData\Local\Fortify\scancentral-21.1.2\log" directory.
Gathering project information...
MSBuild auto-detection: using msbuild version '17.0.0.52104' from 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin'.

And talking about agents too because with the Azure DevOps pipelines the same issue is happening.
With the official tasks provided from the Marketplace for Fortify on Demand, the same errors are appearing in the output file(scancentral.log) in Azure Pipelines hosted agents using windows-latest versions.

Is there anything to make the ScanCentral tool aware of where the MSBuild.exe executable is placed? It would be great to have some action for that. BTW tried with the "microsoft/setup-msbuild" action but without success.

Thanks for your time

rsenden commented

Hi, thanks for the extensive information on this issue. The missing scancentral.properties file is just a warning and can be safely ignored; I see this in all ScanCentral Client invocations. As for the second error, MSBuild.exe must be on the PATH as you have already experienced, I'm not aware of any other way to make the ScanCentral command aware of the location of MSBuild.exe.

According to our engineering team, the MSBuild auto-detection message is actually coming from NuGet which is invoked by ScanCentral Client, so this doesn't necessarily mean that the ScanCentral tool itself can find MSBuild.exe (I guess these tools use different mechanisms for locating MSBuild.exe).

For Azure DevOps, you can add a Batch Script task in the pipeline that runs before the ScanCentral task:

  1. Configure the Batch Script task to apply modified environment variables to further pipeline tasks (using the checkbox or modifyEnvironment argument)
  2. Invoke <hardcoded path to VS>\Tools\VSDevCmd.bat in this Batch Script task to set up the environment variables (in case of Azure hosted machine it is possible to find out where Visual Studio is installed by VM type)
  3. The ScanCentral task should now run properly based on the environment variables configured in the Batch Script task

For GitHub, I can successfully run the packaging step in this Windows-based workflow; did you try a similar setup with the vs-version argument on the microsoft/setup-msbuild action? Other users have also reported success if they add the vswhere-path argument; see the documentation for setup-msbuild for details.

Some other remarks & suggestions:

Please let us know in a new comment if any of these suggestions help to fix the issue.

Deleted user commented

Thanks a lot, the example provided made my day.
This step you provided using the "vs-version: 10.0" worked perfectly:

  - name: Setup MSBuild
    uses: microsoft/setup-msbuild@v1
    with:
      vs-version: 10.0

Sorry, didn't have time to check into the Azure DevOps case. But I'm sure your suggestions and explanations will fix this too.

Thanks for the "remarks & suggestions", I'm sure these will provide help in the future.

Please feel free to close this issue since your solution provided helped me with it, a lot!

rsenden commented

@FerranGarriga Thanks for confirming that the vs-version: 10.0 works for you, I'll close this issue then.