BA3004 reports DWARF version 0 for Go 1.26 Linux ELF binaries that contain DWARF v5

[qmuntal]

Summary

BinSkim 4.4.9.7 reports BA3004 with DWARF version 0 for Go 1.26 Linux ELF binaries, even though the same binaries contain DWARF v5 according to readelf.

I reproduced this on simple Go-produced ELF binaries for linux/amd64. The minimal repro below uses a plain default go build, but I also saw the same BA3004 result on -buildmode=pie, -buildmode=pie -linkmode external, and -buildmode=pie -linkmode external -extldflags ''-static-pie''.

Environment

• BinSkim: 4.4.9.7
• Go: go1.26.0
• Repro path used here: build Linux ELF in WSL2 / Linux, then analyze that ELF with BinSkim on Windows
• readelf from GNU binutils

Steps to reproduce

1. In WSL/Linux, create a minimal Go program in a path visible from Windows (for example under /mnt/c/temp/binskim-go-dwarf5/hello.go):

package main

func main() {
    println("Hello, World!")
}

2. Build a Linux ELF with Go 1.26:

cd /mnt/c/temp/binskim-go-dwarf5
go version
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o hello hello.go

3. Confirm the binary contains DWARF v5:

readelf --debug-dump=info hello | grep -m 1 "Version:"

Observed output:

Version:       5

4. Analyze the same binary with BinSkim on Windows:

C:\path\to\BinSkim.exe analyze --verbose --output C:\temp\binskim-go-dwarf5\hello.sarif C:\temp\binskim-go-dwarf5\hello

5. Inspect the BA3004 result in the generated SARIF:

Select-String '"ruleId": "BA3004"' -Path C:\temp\binskim-go-dwarf5\hello.sarif -Context 0,10

Observed BA3004 excerpt:

{
  "ruleId": "BA3004",
  "level": "error",
  "message": {
    "id": "Error",
    "arguments": [
      "hello",
      "0"
    ]
  }
}

Expected behavior

If the ELF actually contains DWARF v5, BA3004 should either:

• pass, or
• at minimum report the detected version as 5, not 0.

Actual behavior

BinSkim reports BA3004 as an error and says the file is using DWARF version 0, even though readelf shows DWARF version 5 in .debug_info.

Notes

I also reproduced the same BA3004 / version 0 result on other Go 1.26 Linux build modes, including PIE and external-linker builds. So this does not appear to be specific to one linker mode; it looks like a BinSkim interpretation issue for these Go-produced ELF binaries.