custom-gosec-security-scan-instructions.txt

Additional security categories to check for in this codebase (github.com/securego/gosec — a Go static analysis security scanner):

1. Check for path traversal in report output: the output file path is supplied by the user via command-line flag. Verify it is not used in any file operation without sanitization, preventing writes to arbitrary locations outside the intended output directory.
2. Check for ReDoS (Regular Expression Denial of Service) in path-exclusion rule compilation: user-supplied regex patterns from configuration files and --exclude-rules flags are compiled at startup. Flag any case where a compiled regex is applied to unbounded input without a timeout or complexity limit.
3. Check for unsafe JSON unmarshalling in configuration loading: gosec reads a JSON config file whose structure is user-controlled. Look for use of interface{} targets or reflect-based unmarshalling that could panic or behave unexpectedly with malformed input.
4. Check for arbitrary file read via package path arguments: gosec calls go/packages.Load() with user-supplied package paths. Verify that paths are validated before being passed to the loader to prevent reading files outside the intended scan scope.
5. Check for nosec suppression bypass: the suppression system parses #nosec and //gosec:disable comments from source code being scanned. Flag any logic where a crafted comment in scanned code could suppress a finding it was not intended to suppress, or could affect findings in other files.
6. Check for resource exhaustion in SSA taint analysis: the SSA traversal uses a depth limit (max 20) and visited maps to prevent infinite loops. Verify the depth limit is enforced on all recursive paths and that visited maps are properly scoped per-analysis to prevent cross-package state leakage.
7. Check for TOCTOU (time-of-check/time-of-use) issues in directory exclusion: the vendor and .git exclusion logic checks directory names before passing them to go/packages. Ensure the exclusion check and the subsequent load use the same resolved path to prevent symlink-based bypass.
8. Check for injection in SARIF/HTML report generation: finding details (file paths, code snippets, rule descriptions) sourced from scanned code are embedded into output reports. Verify that all untrusted content is properly escaped for the target format (XML escaping for SARIF, HTML escaping for HTML reports) before being written.
9. Check for integer overflow in severity/confidence score comparisons: severity and confidence levels are numeric enums compared against user-supplied threshold flags. Verify the comparison logic handles out-of-range threshold values without wrapping or bypassing the filter.
10. Check for goroutine leaks in concurrent package analysis: if gosec processes packages concurrently, verify that all goroutines are bounded by a context with cancellation and that any early exit (on error or signal) properly waits for all analysis goroutines to finish before exiting.
11. Check for hardcoded rule IDs or sensitive strings in test fixtures: test fixtures in the rules/ and testdata/ directories may contain intentionally vulnerable code snippets. Ensure these are isolated and cannot be imported or executed outside of the test environment.
12. Check for unsafe use of os/exec in any internal tooling or helper scripts: gosec itself detects command injection in user code, so any use of exec.Command in its own build scripts or integration tests must not interpolate external input into command arguments.