check govuln logs on CI

[marcello33]

When running this on the my pipeline, I get the total number of vulnerabilities but not detailed logs, which makes impossible for me to understand which vulnerability I should fix

Run docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=false -e PACKAGE=./... -e SKIP_UPLOAD=false -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=false -e PACKAGE=./... -e SKIP_UPLOAD=false -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
5:50PM INF GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3
5:50PM INF Running govulncheck for package ./... in dir /github/workspace
5:51PM INF Successfully scanned project
5:51PM INF Conversion yielded following stats Call Sites=0 Vulnerabilities=1
5:51PM INF Preparing Report for upload to Github Commit=*** Ref=***
5:51PM INF Report was uploaded to GitHub sarif_id=***
5:51PM INF Successfully uploaded Sarif Report to Github, it will be available after processing 

Is there a way to get the govuln output at pipeline runtime, such as (for example)

Scanning for dependencies with known vulnerabilities...
Found 1 known vulnerabilities.

Vulnerability #1: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
  maliciously set environment variables on Windows. In
  syscall.StartProcess and os/exec.Cmd, invalid environment
  [...]

[marcello33]

For me, the serif report is always empty
Also by giving the following permission to my job

    permissions:
      security-events: write

what I get in the Code scanning result is always something like

Category | Base branch | Pull request
-- | -- | --
  | ❓  Not found | ✔️  Found for ***

GitHub Code Scanning / govulncheck
succeeded 11 minutes ago in 1s
No new or fixed alerts
Warning: The base analysis for some categories could not be found. All their alerts have been reported as new.

No new or fixed alerts

Analyses
Code scanning compared refs/heads/devel with refs/pull/***/merge (commit ***)

Category	Base branch	Pull request
❓  Not found	✔️  Found for ***

Maybe I am doing something wrong here, but do you have an example of GH workflow producing meaningful reports?
Where I can find the original govuln output in GitHub?

[marcello33]

Here my setup

        - name: Running govulncheck
          uses: Templum/[email protected]
          with:
            go-version: 1.19
            vulncheck-version: latest
            package: ./...
            github-token: ${{ secrets.GITHUB_TOKEN }}
            fail-on-vuln: false

[Templum]

The issue here might be that the vulnerability only shows up on Windows, at least that's what I suggest on your first message.

But if not other specified default runners of GitHub actions are Linux devices. And as stated in the Readme as limitation, govulncheck only considers vulnerabilities for the current OS and not for all possible OS

[Templum]

Is that the only thing returned by vulncheck for your repository? Or are there any other results being returned that are not linked to direct code usage but imports ?

Scanning for dependencies with known vulnerabilities...
Found 1 known vulnerabilities.

Vulnerability #1: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
  maliciously set environment variables on Windows. In
  syscall.StartProcess and os/exec.Cmd, invalid environment
  [...]

[marcello33]

I have Mac and govuln alone works smoothly on my machine when running it locally, as you can see in the following output logs

marcell033 🐹 v1.19 on 🐳 v20.10.20 
govulncheck  ./...  

govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 4 known vulnerabilities.

Vulnerability #1: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
  maliciously set environment variables on Windows. In
  syscall.StartProcess and os/exec.Cmd, invalid environment
  variable values containing NUL values are not properly checked
  for. A malicious environment variable value can exploit this
  behavior to set a value for a different environment variable.
  For example, the environment variable string "A=B\x00C=D" sets
  the variables "A=B" and "C=D".

Vulnerability #2: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
  maliciously set environment variables on Windows. In
  syscall.StartProcess and os/exec.Cmd, invalid environment
  variable values containing NUL values are not properly checked
  for. A malicious environment variable value can exploit this
  behavior to set a value for a different environment variable.
  For example, the environment variable string "A=B\x00C=D" sets
  the variables "A=B" and "C=D".

Vulnerability #3: GO-2022-1039
  Programs which compile regular expressions from untrusted
  sources may be vulnerable to memory exhaustion or denial of
  service. The parsed regexp representation is linear in the size
  of the input, but in some cases the constant factor can be as
  high as 40,000, making relatively small regexps consume much
  larger amounts of memory. After fix, each regexp being parsed is
  limited to a 256 MB memory footprint. Regular expressions whose
  representation would use more space than that are rejected.
  Normal use of regular expressions is unaffected.

Vulnerability #4: GO-2022-1037
  Reader.Read does not set a limit on the maximum size of file
  headers. A maliciously crafted archive could cause Read to
  allocate unbounded amounts of memory, potentially causing
  resource exhaustion or panics. After fix, Reader.Read limits the
  maximum size of header blocks to 1 MiB.

Vulnerability #5: GO-2022-0969
  HTTP/2 server connections can hang forever waiting for a clean
  shutdown that was preempted by a fatal error. This condition can
  be exploited by a malicious client to cause a denial of service.

The problem is when using govulncheck-action in my GitHub CI pipeline, where output (for the exact same code) is only

Run Templum/[email protected]
Run docker build --build-arg GOLANG_VERSION=1.19 --build-arg VULNCHECK_VERSION=latest -q -f $GITHUB_ACTION_PATH/Dockerfile -t templum/govulncheck-action:local $GITHUB_ACTION_PATH
sha256:***
Run docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=false -e PACKAGE=./... -e SKIP_UPLOAD=false -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
5:50PM INF GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3
5:50PM INF Running govulncheck for package ./... in dir /github/workspace
5:51PM INF Successfully scanned project
5:51PM INF Conversion yielded following stats Call Sites=0 Vulnerabilities=1
5:51PM INF Preparing Report for upload to Github Commit=*** Ref=***
5:51PM INF Report was uploaded to GitHub sarif_id=*** 
5:51PM INF Successfully uploaded Sarif Report to Github, it will be available after processing

Here not only I can't see the output of govuln, but no serif report is created.

[marcello33]

So basically the action wrapper around it makes it unusable for me, and that's a pity since the tool has potential

[Templum]

Probably would need to work with you on debugging, what exactly is going on here.

My point with the Windows warning was referring to this issue. It's still listed as a limitation in the original docs. But seems like it was fixed

[Templum]

You can set an ENV DEBUG=true this should allow us to see a bit more verbose what's going on. But probably would need the generated output from govulncheck (-json-flag) or at least a small demo project that I could use to debug on.

[Templum]

@marcello33 actually you don't need to do the above steps. I found out that they drastically changed the JSON Report format. Which breaks my action. I will be working on a fix for that, which considers the new report format

[marcello33]

Thanks @Templum, that'd be very much appreciated. If it works well, I'm planning to integrate it in all our organization's repos. It'd also makes sense to use a fixed govuln version instead of 'latest' then.
Please, let me know if I can help somehow

[Templum]

Thanks @Templum, that'd be very much appreciated. If it works well, I'm planning to integrate it in all our organization's repos. It'd also makes sense then to use a fixed govuln version instead of 'latest' then.
Please, let me know if I can help somehow

I will ping you if there is a version available for testing, well after all the cli itself is still experimental hence it is kind of expected that some like that can happen. In the new version parsing will be adjusted to ensure error handling is telling people that maybe this version broke something. Ideally they won't flip around the report structure on that scale anymore and just resort to adding fields or removing them

[marcello33]

Also, is there a way to use the -v flag into your action?
It prints a full call stack for each vulnerability and I find it very useful, especially when identifying the portion of code affected by the issues.

[Templum]

Could you give Templum/govulncheck-action@fix/investigate a go?

Initial tests on my playground look promising

[marcello33]

Sure, let me try

[marcello33]

@Templum, same results.

Local govuln finds 3 vulnerabilities and displays them:

govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 3 known vulnerabilities.

Vulnerability #1: GO-2022-1095
  Due to unsanitized NUL values, attackers may be able to
...

Action output only reports 2 vulnerabilities, does not display them, and no serif report is present

1m 46s
Run Templum/govulncheck-action@fix/investigate
  with:
    go-version: 1.18
    vulncheck-version: latest
    package: ./...
    github-token: ***
    fail-on-vuln: false
    skip-upload: false
Run docker build --build-arg GOLANG_VERSION=1.18 --build-arg VULNCHECK_VERSION=latest -q -f $GITHUB_ACTION_PATH/Dockerfile -t templum/govulncheck-action:local $GITHUB_ACTION_PATH
sha*** 
Run docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=false -e PACKAGE=./... -e SKIP_UPLOAD=false -e DEBUG=${DEBUG} -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
1:35PM INF GoEnvironment Details: Go-Arch=amd Go-Os=linux Go-Version=go1.19.3
1:35PM INF Running govulncheck for package ./... in dir /github/workspace
1:36PM INF Successfully scanned project
1:36PM INF Conversion yielded following stats Call Sites=0 Vulnerabilities=2
1:36PM INF Preparing Report for upload to Github Commit=*** Ref=***
1:36PM INF Report was uploaded to GitHub sarif_id=***
1:36PM INF Successfully uploaded Sarif Report to Github, it will be available after processing

[Templum]

Actually I'm working on that behaviour, the important note for me here would be the :

=== Informational ===

The vulnerabilities below are in packages that you import, but your code
doesn't appear to call any vulnerable functions. You may not need to take any
action. See https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck
for details.

Vulnerability #1: GO-2022-1095

As up to know this action only created results for active call sites. But if you never call, there is nothing. I'm working right now on a small addition that also honors those hits.

[Templum]

That aside many thanks for testing it out and getting back to me so fast. Highly appreciated.

[marcello33]

Not quite sure if I got your point, sorry

But - just to be clear - for me the action still does not work, as

• number of vulnerabilities is different from what govuln detects locally for the same code
• I can't see the output from govuln in the github action, which makes it impossible to understand where/which are the vulnerabilities

[Templum]

Could you please give the version from above another shot, just finished pushing the changes. That should cover your use-case.

What I was referring to previously was that the action would only create scanning actions for direct calling code. Meaning your code calls a vulnerability, it did not consider imports. Which it now does

[marcello33]

Thanks, running it again!

[marcello33]

Hey @Templum , same again

Run Templum/govulncheck-action@fix/investigate
  with:
    go-version: 1.18
    vulncheck-version: latest
    package: ./...
    github-token: ***
    fail-on-vuln: false
    skip-upload: false
Run docker build --build-arg GOLANG_VERSION=1.18 --build-arg VULNCHECK_VERSION=latest -q -f $GITHUB_ACTION_PATH/Dockerfile -t templum/govulncheck-action:local $GITHUB_ACTION_PATH
sha***
Run docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=false -e PACKAGE=./... -e SKIP_UPLOAD=false -e DEBUG=${DEBUG} -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
2:18PM INF GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3
2:18PM INF Running govulncheck for package ./... in dir /github/workspace
2:18PM INF Successfully scanned project
2:18PM INF Conversion yielded following stats Call Sites=2 Vulnerabilities=2
2:18PM INF Preparing Report for upload to Github Commit=*** Ref=***
2:18PM INF Report was uploaded to GitHub sarif_id=***
2:18PM INF Successfully uploaded Sarif Report to Github, it will be available after processing

[Templum]

Could you please also share the output over at the Security Tab?

You can also skip upload and have a look at the raw sarif report. This time it shows in the log something should be uploaded.

[marcello33]

[Templum]

Okay, but that suggests that 2 Alerts were raised. Meaning you should see them under the Code Scanning menu:

[marcello33]

Ok, thanks
If the upload happens at the end of thw whole pipeline execution (not only this task), then I'd need to wait a bit to confirm that
Also, locally govuln says it finds 3 vulnerabilities but the action only reports 2 :/

  govulncheck ./...                                                                                    
govulncheck is an experimental tool. Share feedback at https://go.dev/s/govulncheck-feedback.

Scanning for dependencies with known vulnerabilities...
Found 3 known vulnerabilities.

[Templum]

@marcello33 well sorry, seems like this was not clear to you. I thought my Readme makes it clear that data is reported to the security tab. The idea here is that govulncheck does not support the silencing of findings. Meaning it could block flows unjustified. Hence I went with this path, if you want to fail on the spot you can use fail-on-vuln. In that case it will fail on any found vulnerability and still will upload the report.

Regarding your second point, this seems to be related to environment differences. Data is taken raw from govulncheck. Your action runs 1.18, locally you run 1.19.

[Templum]

@marcello33 I adjusted the Readme to have a short section under Usage. That shows where to locate the results. If there is nothing from your side that speaks against closing this, I would probably go ahead and merge the changes and release a new version

[marcello33]

So I am using the following now:

      - name: Running govulncheck
        uses: Templum/govulncheck-action@fix/investigate
        with:
          go-version: 1.18
          vulncheck-version: latest
          package: ./...
          github-token: ${{ secrets.GITHUB_TOKEN }}
          fail-on-vuln: true

Output of action:

1m 49s
Run Templum/govulncheck-action@fix/investigate
Run docker build --build-arg GOLANG_VERSION=1.18 --build-arg VULNCHECK_VERSION=latest -q -f $GITHUB_ACTION_PATH/Dockerfile -t templum/govulncheck-action:local $GITHUB_ACTION_PATH
sha256:***
Run docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace -e GITHUB_TOKEN=*** -e STRICT=true -e PACKAGE=./... -e SKIP_UPLOAD=false -e DEBUG=${DEBUG} -e GITHUB_REPOSITORY=*** -e GITHUB_REF=*** -e GITHUB_SHA=*** templum/govulncheck-action:local
2:48PM INF GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3
2:48PM INF Running govulncheck for package ./... in dir /github/workspace
2:48PM INF Successfully scanned project
2:48PM INF Conversion yielded following stats Call Sites=2 Vulnerabilities=2
2:48PM INF Preparing Report for upload to Github Commit=*** Ref=***
2:48PM INF Report was uploaded to GitHub sarif_id=***
2:48PM INF Successfully uploaded Sarif Report to Github, it will be available after processing
2:48PM INF Encountered at least one vulnerability while running in strict mode, will mark outcome as failed
Error: Process completed with exit code 2.

"Code scanning" under "Security" tab is empty for me

But "Code scanning results" within the PR tab reports two alerts (Warnings)

Does it all looks correct to you?

On a side note, two points:

• I see a difference in the golang versions: GOLANG_VERSION=1.18 and GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3.
  Are those two different things, so my setup is correct, right?
• I tried to upgrade to go 1.19 to replicate my local setup in the pipeline.
  The outputs are completely different (locally 3 vulns + 3 warning, remotely 2 vulns - which do not appear in the security tab - and 2 warnings - which appear in the code scanning results)

[Templum]

As I was referring to the main branch and you refer to a PR/Branch, they seem to be located in different locations. But overall the data looks correct.

Regarding your side notes:

1. I will look into this issue, clearly something is off. It can be just a display error, as the action code itself is statically compiled against 1.19.
2. This is something you can cross-check by taking the original report and see if the numbers add up, can be achieved by:

      - name: Scan for Vulnerabilities in Code
        uses: Templum/govulncheck-action@fix/investigate
        env:
          DEBUG: "true"
      - name: Upload Report
        uses: actions/upload-artifact@v3
        with:
          name: raw-report
          path: raw-report.json

[marcello33]

Hey @Templum I'm closing it as with the full report I have all the means for double checking
Thanks for the support
Please, merge the PR and release a new version, I'll use that one ;)

[Templum]

Many thanks for your feedback and efforts in working on this, we can take the other things individually in case you notice issues.

[marcello33]

@Templum thank you for your support and effort

Btw, I'd only really check carefully the golang version differences between GOLANG_VERSION=1.18 and INF GoEnvironment Details: Go-Arch=amd64 Go-Os=linux Go-Version=go1.19.3
The more I test it, the more I think that's the source of "vulnerabilities count mismatch" issue

The govuln you run within the docker image should always run the version specified in ci action param go-version and apparently it does not.

If you want, I can open a separate issue for that and help you debug/test it ;)

[Templum]

@marcello33 feel free to open an Issue. We can then work on it.