Description
Summary
I'm relatively new to Go and have been learning as I go along. I noticed a potential issue with gosec and wanted to bring it to your attention. Please let me know if there's any additional information I can provide or if there's anything specific I should check.
When gosec is run on C-Go projects, it makes references to artifacts in the ~/.cache/go-build and sometimes the findings are not accurate.
Steps to reproduce the behavior
git clone https://github.com/mattn/go-sqlite3.git
cd go-sqlite3
gosec -exclude=G101,G104,G107,G114,G304,G404,G501,G502,G503,G504,G505,G601,G602 ./...
gosec version
2.21.4
Go version (output of 'go version')
go version go1.23.2 linux/amd64
Operating system / Environment
RHEL8
Expected behavior
NA
Actual behavior
When you run it on go-sqlite3 there are a lot of findings pointing to ~/.cache/go-build. But many a times the line references are to comments or braces. For e.g.:
[~/.cache/go-build/fe/fe5d4b0d45b1c7d7e90813bd136209c8ea66e28daa56236f90c38976bf4e5ef7-d:47] - G115 (CWE-190): integer overflow conversion int -> int32 (Confidence: MEDIUM, Severity: HIGH)
46: // function. This function returns a boolean indicating if the backup is done
> 47: // and an error signalling any other error. Done is returned if the underlying
48: // C function returns SQLITE_DONE (Code 101)
Autofix:
[~/.cache/go-build/e9/e926f4820d9c9913d899103476f766ac6f5335ca76748aeab67e9a40060a6ee3-d:102] - G115 (CWE-190): integer overflow conversion int -> int32 (Confidence: MEDIUM, Severity: HIGH)
101:
> 102: // ResultZeroblob sets the result of an SQL function.
103: // See: sqlite3_result_zeroblob, http://sqlite.org/c3ref/result_blob.html
Autofix:
[~/.cache/go-build/e9/e926f4820d9c9913d899103476f766ac6f5335ca76748aeab67e9a40060a6ee3-d:95] - G115 (CWE-190): integer overflow conversion int -> int32 (Confidence: MEDIUM, Severity: HIGH)
94: // ResultText sets the result of an SQL function.
> 95: // See: sqlite3_result_text, http://sqlite.org/c3ref/result_blob.html
96: func (c *SQLiteContext) ResultText(s string) {
Autofix:
[~/.cache/go-build/c0/c0d7ddc99355f1d56e73aae651991927f6892b66e109e4f27ffeb06c330f9d8b-d:44] - G115 (CWE-190): integer overflow conversion int -> int32 (Confidence: MEDIUM, Severity: HIGH)
43:
> 44: // ColumnTypeScanType implement RowsColumnTypeScanType.
45: func (rc *SQLiteRows) ColumnTypeScanType(i int) reflect.Type {
Autofix:
[~/.cache/go-build/c0/c0d7ddc99355f1d56e73aae651991927f6892b66e109e4f27ffeb06c330f9d8b-d:23] - G115 (CWE-190): integer overflow conversion int -> int32 (Confidence: MEDIUM, Severity: HIGH)
22: )
> 23:
24: // ColumnTypeDatabaseTypeName implement RowsColumnTypeDatabaseTypeName.
Autofix:
And so on....
For my use case, I'm leaning towards excluding the cache directory from the scanner. These findings in cache aren't really helpful cause we don't know the source in the project that led to it. What else can be done here?
Thanks!