Binary catalogers load full ELF symbol tables for every executable — excessive allocations for non-matching files

Problem

Several binary-scanning catalogers open every executable in the image and load large data structures (ELF symbol tables, full file contents) before determining if the file is relevant. The vast majority of executables are not Go binaries, GraalVM native images, or Rust auditable binaries — but they all get expensive processing regardless.

The main offenders:

• graalvm-native-image-cataloger — calls elf.File.Symbols() + DynamicSymbols() on every ELF binary, loading the full .symtab/.dynsym sections and .strtab/.dynstr string tables into memory. On alpine (8.7 MB, zero GraalVM binaries), this allocates 883 MB cumulatively.

• go-module-binary-cataloger — uses debug/buildinfo.Read() which calls searchMagic, scanning the entire binary file in memory looking for the \xff Go buildinf: magic sequence. Also uses goversion library which loads ELF symbols via (*elfExe).Symbols. On alpine (zero Go binaries), this allocates 529 MB.

• binary-classifier-cataloger, elf-binary-package-cataloger, cargo-auditable-binary-cataloger — similar patterns of loading substantial data from every executable.

Profiling Data

Profiled syft v1.32.0 with pprof and per-cataloger ReadMemStats attribution:

Per-cataloger TotalAlloc (cumulative allocations, includes GC'd objects)

pprof top allocations (alpine, alloc_space at peak)

These are cumulative allocations — most get GC'd — but they drive peak RSS through GC timing (heap grows to 2x live set before collection). With parallel execution (default NumCPU * 4), multiple catalogers process binaries simultaneously, stacking live allocations.

Context

We use syft as a library in Kubescape for in-cluster SBOM scanning of container images. Memory-constrained sidecars (1400 Mi) frequently OOM on medium-to-large images. #3800 reports a similar finding — disabling the Go binary cataloger resolved OOM on a 330 MB image.

Suggested Approach: Cheap Pre-Filtering

Each binary cataloger could do a cheap check before loading heavy data:

• GraalVM cataloger: Check for specific ELF section names or do a byte scan for graal_create_isolate before calling .Symbols() / .DynamicSymbols()
• Go module cataloger: Check for .go.buildinfo ELF section existence before calling buildinfo.Read() (a section header lookup, no data loading)
• Cargo auditable cataloger: Check for .dep-v0 section before parsing
• Binary classifier / ELF package cataloger: Lighter initial pass before loading full binary content

The section header check is essentially free — debug/elf.NewFile already parses section headers when opening the ELF file. Checking section names is a lookup on already-parsed data, adding zero allocations.

This would eliminate the vast majority of allocations since <1% of ELF files in typical images are Go/GraalVM/Rust binaries.

We're happy to contribute a PR for this.

Start with the graalvm-native-image-cataloger, go-module-binary-cataloger, cargo-auditable-binary-cataloger, binary-classifier-cataloger, and elf-binary-package-cataloger entry points, focusing on their ELF, buildinfo, and symbol-loading paths. Compare the suggested section or byte pre-filters with the existing profiling data, then verify that non-matching executables avoid heavy allocations without changing cataloging results.