nosec statement ignored when additionally defined in front of function, const or variable segment

[joernlenoch]

Summary

Adding a #nosec marker in front of this const or var segment causes the parser to ignore the actual nosec statements.

Steps to reproduce the behavior

// #nosec G101
const (
    ConfigLearnerTokenAuth string = "learner_auth_token_config" // #nosec G101
)

will create this error message.

Results:

[...:9] - G101 (CWE-798): Potential hardcoded credentials (Confidence: LOW, Severity: HIGH)
    8: const (
  > 9:  ConfigLearnerTokenAuthTemp string = "learner_auth_token_config" // #nosec G101
    10: )

When removed, no error is shown.

const (
	ConfigLearnerTokenAuthTemp string = "learner_auth_token_config" // #nosec G101
)

Results:


Summary: [...]

gosec version

2.19.0 (latest on 14th February 2024)

Works fine with 2.18.

Go version (output of 'go version')

go version go1.21.4 windows/amd64

Operating system / Environment

Windows 11

Expected behavior

Should not show the ignored security errors.

Actual behavior

Ignores the #nosec statements and displays an error.

[joernlenoch]

Same issue is true for functions

// RandomizeRuntime ...
// #nosec G404
func (p *passwordResetter) RandomizeRuntime() {
	sleepTime := rand.Intn(1000) + 1000 // #nosec G404
	time.Sleep(time.Duration(sleepTime) * time.Millisecond)
}

will cause the same behaviour. Removing the first nosec-marker will solve this issue as well..

[rd-bruno-lueders]

It seems like block-wide nosec statements are broken in general. Example:

//#nosec G404
fmt.Printf("%d\n",
    rand.Int())

In v2.18.2, the nosec directive suppresses the G404 warning, but in v2.19.0, that doesn't work anymore. To make it work in v2.19.0, I have to move the nosec right next to the rand.Int call:

fmt.Printf("%d\n",
    //#nosec G404
    rand.Int())

Interestingly, there has to be a line-feed in the Printf call. This works in both versions:

//#nosec G404
fmt.Printf("%d\n", rand.Int())

[ccojocar]

The nonsec directive was refactored to be more fined-grained instead of ignoring an entire AST node.

[MaehlerChristopher]

Unfortunately, the use of #nosec is no longer predictable in the current version (2.19.0). Multiple tests show a different number of issues with the same code. With version 2.18.2, the problem does not occur at all.

example Code:

...
                _, _, err := procPathNameVolume.Call(
                        uintptr(unsafe.Pointer(volumeName)),     //#nosec
                        uintptr(unsafe.Pointer(&nameBuffer[0])), //#nosec
                        uintptr(nameSize),
                        uintptr(unsafe.Pointer(&retSize))) //#nosec
...

first run with 2.19.0:

utils.go:84] - G103 (CWE-242): Use of unsafe calls should be audited (Confidence: HIGH, Severity: LOW)
    83:                         uintptr(nameSize),
  > 84:                         uintptr(unsafe.Pointer(&retSize))) //#nosec
    85:                 if err == windows.ERROR_MORE_DATA {



Summary:
  Gosec  : dev
  Files  : 4
  Lines  : 1497
  Nosec  : 4
  Issues : 1

second run with 2.19.0:

utils.go:81] - G103 (CWE-242): Use of unsafe calls should be audited (Confidence: HIGH, Severity: LOW)
    80:                 _, _, err := procPathNameVolume.Call(
  > 81:                         uintptr(unsafe.Pointer(volumeName)),     //#nosec
    82:                         uintptr(unsafe.Pointer(&nameBuffer[0])), //#nosec



Summary:
  Gosec  : dev
  Files  : 4
  Lines  : 1497
  Nosec  : 4
  Issues : 3

third run with 2.19.0:

utils.go:81] - G103 (CWE-242): Use of unsafe calls should be audited (Confidence: HIGH, Severity: LOW)
    80:                 _, _, err := procPathNameVolume.Call(
  > 81:                         uintptr(unsafe.Pointer(volumeName)),     //#nosec
    82:                         uintptr(unsafe.Pointer(&nameBuffer[0])), //#nosec



Summary:
  Gosec  : dev
  Files  : 4
  Lines  : 1497
  Nosec  : 4
  Issues : 2

run with 2.18.0:

Summary:
  Gosec  : dev
  Files  : 4
  Lines  : 1497
  Nosec  : 4
  Issues : 0