Fortify SSC export failed with "exit code 3221225781"

[kalyanreddy1992]

I am trying to use fortify/github-action/ssc-export@v1 task to download Fortify latest scan results and publish the same on to GitHub advanced Security Dashboard.

Error: Action failed with error: Error: The process 'C:\Users\sonatype\actions-runner_work_temp/fortify/tools/fcli/aHR0cHM6Ly9naXRodWIuY29tL2ZvcnRpZnkvZmNsaS9yZWxlYXNlcy9kb3dubG9hZC92Mi4yLjAvZmNsaS13aW5kb3dzLnppcA==/bin/fcli.exe' failed with exit code 3221225781

Kindly help me resolve this issue.

[rsenden]

@kalyanreddy1992, thanks for reporting this. Quick Google search shows that this exist code may be caused by missing DLL files. Can you share what type of runner you're using (self-hosted or GitHub-hosted runner, what Windows version, ...)?

We build the Windows executable from Java code using GraalVM, so I'd need to figure out what DLL files are required exactly by the executable; maybe some extra steps are required in the GitHub Action to install any necessary dependencies.

[MikeTheSnowman]

@kalyanreddy1992 I'm noticing in your error message that C:\Users\sonatype\... is mentioned in the full path to fcli. May I ask if you're using a self-hosted runner or a GitHub-hosted runner? Also, if you know, what version of windows is your runner using? The runs-on attribute in your GH workflow might give a clue. For example:

jobs:
  build:
    runs-on: <runner-type>

The answers to my questions will help me to decide how to best address your issue.

[kalyanreddy1992]

@wtfacoconut @rsenden , Thanks for your quick response. I am using self hosted runner and the below are my windows VM specifications.

Edition Windows Server 2022 Datacenter Azure Edition Version 21H2 Installed on ‎3/‎4/‎2024 OS build 20348.2277

Earlier faced an issue with some limitation of powershell 5 w.r.t handling zip files , so have installed powershell 7 and also enabled windows subsystem for Linux.

[rsenden]

@kalyanreddy1992, the screenshot below shows the direct dependencies for fcli.exe (generated using Dependency Walker). I guess this may not show dynamically loaded DLLs (if any).

Looks like these are mostly standard Windows DLLs, apart from VCRUNTIME*.DLL. You may want to check that you have the Visual C++ redistributable installed on your runner: https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist.

If that doesn't help, we'll need to dive deeper into this.

[kalyanreddy1992]

@rsenden , I have installed VC++ and gave a try but facing a different issue this time

_C:\Users\sonatype\actions-runner_work_temp/fortify/tools/fcli/aHR0cHM6Ly9naXRodWIuY29tL2ZvcnRpZnkvZmNsaS9yZWxlYXNlcy9kb3dubG9hZC92Mi4zLjAvZmNsaS13aW5kb3dzLnppcA==/bin/fcli.exe tool vuln-exporter install -y -v 2.0.4 -b C:\Users\sonatype\actions-runner_work_temp/fortify/tools --no-global-bin --progress none -o expr={installDir}\n INFO: Add the following directory to PATH for easy tool invocation: C:\Users\sonatype\actions-runner_work_temp\fortify\tools\vuln-exporter\2.0.4\bin

C:\Users\sonatype\actions-runner_work_temp\fortify\tools\vuln-exporter\2.0.4_

Run case ${SSC_APPVERSION} in /bin/bash: C:Userssonatypeactions-runner_work_temp3ba8d806-aa17-40f1-ad8e-1429f4f0f8bb.sh: No such file or directory Error: Process completed with exit code 1.

Please do let me know if I am missing something here. I have the following installed on my agent machine

PS C:\Users\sonatype> wsl --list DEBUG: 1+ >>>> wsl --list DEBUG: ! CALL function '' Windows Subsystem for Linux Distributions: Ubuntu-20.04 (Default) Ubuntu PS C:\Users\sonatype>

[MikeTheSnowman]

Not sure what that file is, but it looks like all the path characters are getting removed in C:Userssonatypeactions-runner_work_temp3ba8d806-aa17-40f1-ad8e-1429f4f0f8bb.sh 🤨

[kalyanreddy1992]

Using FortifyVulnerabilityExporter.jar, I was able to get the SARIF file generated and uploaded it using same fortify/github-action/ssc-export@v1 task. Although it failed this time as well, still uploaded the SARIF file to GHA security as I made the manually generated file available in the repository directly.

But I don't see the vulnerabilities reflected in dashboard, did i miss something here?

[rsenden]

@kalyanreddy1992, to start with the original issue, all of our actions were developed with the standard GitHub-hosted runners in mind, and assume standard bash shell features to be available, even on Windows runners. For Windows Server 2022, this list shows bash 5.2.26 to be available on GitHub-hosted runners.

What I think is happening, is that you don't have a Windows-version of bash installed on your runner. As you do have WSL installed, any run steps with shell: bash will execute in WSL rather than on Windows. Obviously this will cause a weird situation, with most workflow steps running on Windows but each bash-based run step executing in a new WSL shell.

This would also explain the missing path separators, as workflows running on Windows would be using \ as the path separator, but WSL expects / as the path separator and interprets \ as escape character instead of path separator. So, to successfully run the ssc-export action (and most of our other actions), you'd need to install a Windows version of bash on your runner, and make sure that it's being used by the GitHub Runner to execute bash-based run steps (i.e., likely the Windows bash must be on the PATH before the WSL-provided bash.exe).

Looking at GitHub-hosted runners in more detail, it looks like they actually have 3 different bash.exe files installed, provided by MSYS2, Windows Git, and WSL: https://github.com/actions/runner-images/blob/main/images/windows/scripts/build/Configure-Shell.ps1. I assume bash-based run steps use the MSYS2-provided bash.exe.

[rsenden]

As for the second question about uploading manually generated SARIF file, I very much doubt that the ssc-export action will attempt to upload this file if one of the earlier steps in this action is failing (unless the situation described in the previous comment somehow 'fools' the runner in thinking that those steps succeeded).

So, for manually generated SARIF files, I'd suggest using the GitHub-provided action for uploading the SARIF file directly, example can be seen in the GitHub documentation or in our action: https://github.com/fortify/github-action/blob/b802d70c7683b55168d6873f6d05be7df4307e6a/ssc-export/action.yml#L24

If the SARIF file contains any vulnerabilities and the upload is successful, the vulnerabilities should show up under Security->Code Scanning in the GitHub web interface. Note however the following restriction as listed at https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning:

[kalyanreddy1992]

@rsenden , thanks for your inputs.

• uses: github/codeql-action/upload-sarif@v2 , this action has been deprecated https://github.com/fortify/gha-ssc-generate-sarif?tab=readme-ov-file.

Since there is no other way, have tried to make the SARIF file available in the repo/same folder for the task fortify/github-action/ssc-export@v1 to upload it to GHA security.

[rsenden]

@kalyanreddy1992, not sure why you're referring to the fortify/gha-ssc-generate-sarif action, and how this is related to github/codeql-action/upload-sarif?

The fortify/github-action/ssc-export basically performs the following steps:

1. Install FortifyVulnerabilityExporter
2. Run FortifyVulnerabilityExporter to generate SARIF file
3. Publish this SARIF file to GitHub, using the GitHub-provided github/codeql-action/upload-sarif action

The deprecated fortify/gha-ssc-generate-sarif basically did the same as steps 1 and 2 above, and required you to have your workflow do step 3.

If you manually generated a SARIF file (for example using FortifyVulnerabilityExporter), you'll still need to do step 3, i.e., call the GitHub-provided github/codeql-action/upload-sarif action from your workflow to publish the SARIF file to GitHub.

Of course, although useful for testing, manually generating the SARIF file and putting it into your repository isn't a proper long-term solution. So, ideally you should try to get the fortify/github-action/ssc-export action working properly on your self-hosted runner.

Alternatively, you can manually perform the 3 steps above in your workflow, either using the fortify/github-action/setup action to install FortifyVulnerabilityExporter and then run it, or by using the FortifyVulnerabilityExporter Docker image (basically doing the same as the fortify/gha-ssc-generate-sarif action).

[rsenden]

@kalyanreddy1992 Do you have any further questions/input on this topic? If not, we'll go ahead and close this issue.