Improve BOM file naming and writing strategy

[wiebe-vandendriessche]

Problem or motivation

• Current filename generation:

  fileName := fmt.Sprintf("%s_aibom%s", sanitized, fileExt)

• Risk of filename collisions when components share the same name

• No version, format, or spec info in filenames

• Inconsistent fallback logic (Component.Name, Discovery.Name, ID, "model")

• Ad hoc sanitization logic

• Naming logic tightly coupled to file writing

• Not aligned with common SBOM conventions

• Format handling is inconsistent and confusing:

  • Users can specify format via flag or file extension
  • auto detection based on extension introduces implicit behavior
  • Validation enforces extension matching format, adding complexity
  • Same concern exists in both ReadBOM and WriteBOM

• File-based workflows are harder than necessary:

  • Validating BOMs in a directory requires parsing each file first
  • No simple way to operate on files based on extension alone
  • Tight coupling between parsing and higher-level operations

Proposed solution

• Introduce structured naming scheme, for example:

  • <name>-<version>.aibom.<ext>
  • <name>-<version>-cdx<spec>.<ext>

• Include optional metadata:

  • component version
  • spec version
  • format (json or xml)

• Ensure uniqueness:

  • add hash or timestamp suffix when needed

• Centralize naming logic:

  func GenerateBOMFileName(...) string

• Simplify format handling:

  • Choose a single source of truth:
    • either explicit --format
    • or infer from extension, not both
  • Remove or limit auto behavior
  • Avoid strict extension versus format mismatch errors

• Decouple file operations from parsing:

  • Allow directory-based workflows using file extensions only
  • Add utilities to list and filter BOM files without decoding them
  • Enable validation and similar operations directly on file paths

• Separate concerns:

  • naming
  • format resolution
  • parsing and encoding
  • file system operations

Alternatives considered

/

Additional context

/