SBOM
An SBOM — software bill of materials — is the machine-readable inventory of everything your software contains: direct and transitive dependencies, versions, licenses, suppliers. The two dominant formats are SPDX and CycloneDX; modern build tooling generates either automatically.
Why buyers ask for it
Log4Shell made the case permanently: when a critical vulnerability lands in a common library, “are we affected?” is answerable in minutes with SBOMs and in weeks without. US federal procurement pushed requirements first (Executive Order 14028 and successors); enterprise security reviews followed, and SBOM requests now appear in ordinary SaaS questionnaires — especially from defense-adjacent and critical- infrastructure customers.
The compliance angle
An SBOM is your dependency layer’s audit trail: it evidences that vulnerability management covers what you actually ship, not just what you remember shipping. Paired with scanner output (Dependabot, Snyk), it closes the loop — the inventory says what’s inside, the scanner says what’s vulnerable, the remediation SLAs say what happened next.
The practical minimum
Generate SBOMs in CI on every release (one flag in most build systems), store them per version, and be able to produce one on request. That’s an afternoon of pipeline work that upgrades three separate questionnaire answers — supply-chain security, vulnerability management, and incident readiness — from prose to artifact.
Penetration Test vs Vulnerability Scan — A vulnerability scan is automated and finds known issues; a penetration test is a human actively exploiting your defenses. Auditors and customers ask for both.
Sub-processor — A sub-processor is any third party your company uses to process customer personal data — your cloud host, email provider, analytics. You must disclose them.