New G602 rule: possible performance implications?

[tobias-kuendig]

Summary

Using v2.17.0 of gosec, I noticed that runs agains my code base suddenlty take minutes. I noticed this when using golangci-lint. With the help of @ldez I was able to narrow the culprit down to the new G602 rule (golangci/golangci-lint#4039).

I have a rather large generated Go file in my repo. It is a GraphQL server generated using the gqlgen package. It is about 80k lines of code.

Running gosec against that file takes 15 minutes:

$ time gosec --include=G602 -r graphql/gqlserver 
[gosec] 2023/08/25 08:24:28 Including rules: G602
[gosec] 2023/08/25 08:24:28 Excluding rules: default
[gosec] 2023/08/25 08:24:28 Import directory: /home/me/code/graphql/gqlserver
[gosec] 2023/08/25 08:24:28 Checking package: gqlserver
[gosec] 2023/08/25 08:24:28 Checking file: /home/me/code/graphql/gqlserver/gen_server.go
Results:


Summary:
  Gosec  : 2.17.0
  Files  : 1
  Lines  : 79371
  Nosec  : 0
  Issues : 0

gosec --include=G602 -r graphql/gqlserver  904.28s user 7.30s system 218% cpu 6:57.81 total

I am unfortunately unable to share the exact GraphQL file. I've tested the rule against some large files from the https://github.com/googleapis/google-api-go-client repo (up to 230k lines) and it did perform generally well no matter how large the file is. So I wonder how much sense it makes to invest in this issue. The solution for me is to skip the new G602 rule.

Let me know if you want to investigate this any further, otherwise feel free to close this issue. This is primarly meant as a data point in case any other users report performance issues.

gosec version

v2.17.0

Go version (output of 'go version')

go version go1.21.0 linux/amd64

Operating system / Environment

Distributor ID: Neon
Description:    KDE neon 5.27
Release:        22.04
Codename:       jammy

[ccojocar]

Thanks for reporting this issue. I was looking again at the source code and it might seem to have some performance impact when scanning very large files.

Anyhow, it seems to me that the performance is fine with decently large files. The file you are trying to scan is usually large. In this case, I would ignore this rule since the code is generated. Hopefully the code generator you are using, it doesn't introduce any slice bounds issues.

I'll close this issue for now. Please feel free to reach out again if you have some file with which we can reproduce the issue.