Weird Behavior with C-Go projects

[chheda-deshaw]

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!

[ccojocar]

I think there are some cgo issues, because some symbols cannot be found:

Golang errors in file: []:

  > [line 0 : column 0] - # command-line-arguments
_example/vtable/vtable.go:22:78: undefined: sqlite3.VTab
_example/vtable/vtable.go:23:11: c.DeclareVTab undefined (type *sqlite3.SQLiteConn has no field or method DeclareVTab)
_example/vtable/vtable.go:36:79: undefined: sqlite3.VTab
_example/vtable/vtable.go:46:39: undefined: sqlite3.VTabCursor
_example/vtable/vtable.go:65:48: undefined: sqlite3.InfoConstraint
_example/vtable/vtable.go:65:77: undefined: sqlite3.InfoOrderBy
_example/vtable/vtable.go:65:100: undefined: sqlite3.IndexResult
_example/vtable/vtable.go:67:18: undefined: sqlite3.IndexResult
_example/vtable/main.go:14:16: conn.CreateModule undefined (type *sqlite3.SQLiteConn has no field or method CreateModule)

gosec doesn't work well with cgo packages.

[chheda-deshaw]

I see, thanks @ccojocar.
Is there a way I can exclude the .cache directory? -exclude-dir only seems to work for dirs within the project being scanned.

[ccojocar]

I think this expansion is in the Go AST package which tries to resolve the cgo symbols. I would leave the bug open to try to investigate if we can do something to improve the situation.

[ccojocar]

Closing this since there isn't much we can do on the gosec side.