Use of inherently dangerous function (unsafe package)
- Rule ID: go_gosec_unsafe_unsafe
- Languages: go
- Source: unsafe.yml
The Go programming language features the
unsafe package which grants low-level memory management capabilities, inclusive of direct memory access and pointer manipulation. Though the
unsafe package can be quite potent, its usage sidesteps the Go compiler's type safety checks. This can lead to an array of security vulnerabilities and unpredictable system behavior.
unsafe Unless Absolutely Necessary
The overarching guidance here is to steer clear of the
unsafe package unless there's an absolute necessity for its functions. When opting for low-level memory operations, ensure that their implications are well-understood and that their deployment is preceded by rigorous testing.
✅ Be Wary of Buffer Overflows
Direct manipulation of memory can lead to buffer overflows, potentially enabling unauthorized code execution. Ensure buffer boundaries are always respected.
✅ Avoid Use After Free
Accessing memory that has already been freed can result in unintended code execution or unpredictable behaviors. Ensure that once memory has been freed, it isn't accessed further.
✅ Prevent Information/Memory Leaks
Unintended memory retention or unintended disclosure of information in memory can occur when using unsafe functions. This can compromise other security defenses or lead to system failures due to exhausted memory. Regularly review and audit your code to check for such leaks.
To skip this rule during a scan, use the following flag
bearer scan /path/to/your-project/ --skip-rule=go_gosec_unsafe_unsafe
To run only this rule during a scan, use the following flag
bearer scan /path/to/your-project/ --only-rule=go_gosec_unsafe_unsafe
Ready to take the next step? Learn more about Bearer Cloud.