BOMHort on BOMHort Documentation

Testing

Mon, 01 Jan 0001 00:00:00 +0000

Quick Start

# Run all tests
cd backend && go test ./... -count=1

# Run with verbose output
go test ./... -v -count=1

# Run tests for a specific package
go test ./internal/vex/ -v -count=1

# Run a single test by name
go test ./internal/vex/ -run TestNormalizeVulnID -v

# Run with race detection (used in CI)
go test ./... -count=1 -race

# Check coverage
go test ./... -coverprofile=coverage.out
go tool cover -html=coverage.out

Test Structure

Tests live next to the code they test, using Go’s _test.go convention:

Why we renamed SeeBOM to BOMHort

Mon, 01 Jan 0001 00:00:00 +0000

What changed

The project name is now BOMHort (formerly known as SeeBOM).

The rename only affects branding and repository naming. The mission and technical direction stay the same: Kubernetes-native SBOM ingestion, enrichment, visualization, and governance.

Why we renamed

The name SeeBOM served us well, but it created confusion: spoken out loud, it sounds very similar to CBOM (Cryptography Bill of Materials).

In the xBOM ecosystem, names like CBOM usually refer to BOM document types, not to tools. Ahead of OpenSSF sandbox intake, we wanted a project name that is clearly identifiable as a platform.

Contributor Ladder

Mon, 01 Jan 0001 00:00:00 +0000

Overview

BOMHort uses a transparent contributor ladder inspired by the CNCF contributor ladder template. Each rung provides clear expectations and privileges, so you always know what the next step looks like.

┌─────────────────────────────────────────────┐
│ Maintainer — merge, release, direction │
├─────────────────────────────────────────────┤
│ Reviewer — approve PRs in their area │
├─────────────────────────────────────────────┤
│ Contributor — regular code/docs/tests │
├─────────────────────────────────────────────┤
│ Community — issues, discussions, usage │
└─────────────────────────────────────────────┘

🌱 Community Member

Who: Anyone who uses BOMHort, files issues, or participates in discussions.

SBOM Parsers

Mon, 01 Jan 0001 00:00:00 +0000

Overview

BOMHort supports multiple SBOM formats through a format-detection dispatch layer at internal/sbom/parse.go. When a file is processed, the dispatcher:

Reads the raw bytes
Probes JSON fields to identify the format
Routes to the appropriate parser backend
Returns a unified ParseResult (SBOM metadata + packages)

This happens transparently — the parsing worker simply calls sbom.Parse(reader, sourceFile, hash).

Supported Formats

Format	File Extension	Detection Method
SPDX 2.3 JSON	`.spdx.json`, `.json`	`"spdxVersion"` field present
In-toto attestation (SPDX)	`.spdx.json`, `.json`	`"predicateType"` contains “spdx”
CycloneDX 1.0–1.7 JSON	`.cdx.json`, `.json`	`"bomFormat": "CycloneDX"`

Parser Backends

Built-in (Default)

The default parsers use goccy/go-json for high-performance streaming and add zero additional dependencies beyond what BOMHort already requires.

AI Usage Policy

Mon, 01 Jan 0001 00:00:00 +0000

Policy

BOMHort welcomes AI-assisted contributions. We use AI tools extensively in our own development workflow (see AGENTS.md). However, we have clear rules to ensure accountability and code quality.

Rules

1. You own it

If you use AI to generate code, you are responsible for that code. Review it, test it, and understand it before submitting. “The AI wrote it” is not an excuse for bugs, security issues, or convention violations.

2. Sign your commits

Every commit must carry your DCO sign-off (Signed-off-by: Your Name <your@email.com>). This is non-negotiable — it certifies that you are the author and take responsibility, regardless of whether AI assisted you.