SBOM (Software Bill of Materials)

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of every component, library, and dependency contained in a software application, including the relationships between those components and any known vulnerabilities associated with them.

The term comes from manufacturing, where a bill of materials lists every part that goes into a physical product. Applied to software, it answers the same question: what is this thing made of?

What does SBOM stand for?

SBOM stands for Software Bill of Materials. The acronym is used interchangeably with the full name in software security, compliance, and procurement contexts.

An SBOM is not a document you write once. It is generated from the software artifact: the compiled binary, container image, or source repository. It is updated on every release.

What does an SBOM contain?

A complete SBOM records the following for every component in the application:

Component identity: Package name, version number, and supplier.

Dependency relationships: Which components depend on which others, including direct dependencies and transitive dependencies (dependencies of dependencies).

License information: The open-source license governing each component's use.

Hash values: Cryptographic hashes that verify the integrity of each component and confirm it has not been tampered with.

Known vulnerability references: CVE identifiers for any known vulnerabilities in each component version at the time of generation.

The NTIA (National Telecommunications and Information Administration) established the minimum required elements for SBOMs in guidance published under US Executive Order 14028.

SBOM formats: SPDX and CycloneDX

Two machine-readable formats dominate SBOM production and consumption.

SPDX (Software Package Data Exchange)

SPDX is an ISO standard (ISO/IEC 5962:2021) originally developed by the Linux Foundation. It is natively supported by GitHub, GitLab, and most package managers, and is strong for license compliance tracking.

CycloneDX

CycloneDX is an OWASP standard designed specifically for security use cases. It supports vulnerability data, service dependencies, and SBOM composition (nesting SBOMs within SBOMs), and is preferred for supply chain security and vulnerability management workflows.

Both formats are widely accepted for US federal compliance under Executive Order 14028. CycloneDX is more commonly used in mobile security contexts due to its explicit support for binary component metadata and vulnerability exchange (VEX) data.

Why SBOM matters

Modern software applications are built mostly from components developed by others. Open-source libraries, commercial SDKs, and framework code routinely make up 80-plus percent of a production application's codebase.

Without an SBOM, a security team has no systematic way to answer the question: "Is our application affected by this newly disclosed vulnerability?" With an SBOM, the answer is immediate: search the inventory for the affected component version.

This is not theoretical. When Log4Shell (CVE-2021-44228) was disclosed in December 2021, organizations with current SBOMs identified affected applications in hours. Organizations without SBOMs took weeks.

SBOM in mobile app security

Mobile applications introduce a specific SBOM challenge: most of the components in a production mobile app are not in the source code manifest. Third-party analytics, payment, authentication, and advertising SDKs are linked into the binary at build time, after the source code is written.

A source-code-based SBOM lists declared dependencies. A binary-based SBOM analyzes the compiled artifact and inventories every component that is actually present in what ships to users, whether declared or not.

Appknox generates binary-based SBOMs from compiled .ipa and .apk files as part of every automated security scan. The SBOM is produced from the artifact that users download, not from the source code that produced it. This distinction matters for mobile apps because third-party SDKs and transitive dependencies that never appear in a Podfile or Gradle manifest are visible in the binary.

See the full capability: Appknox SBOM. 

Regulatory and compliance requirements

SBOM is now a formal compliance requirement in several regulatory contexts.

US Executive Order 14028 (May 2021): Requires SBOM disclosure for all software sold to US federal agencies. The NTIA established minimum SBOM elements; CISA published expanded guidance in September 2024.

FDA medical device regulation (2022): Medical device manufacturers selling in the US market must submit SBOMs as part of premarket submissions for devices with software components.

EU Cyber Resilience Act: Requires software vendors selling in the EU to maintain SBOMs and provide them to customers and authorities upon request. Entering into force across 2025-2027.

Customer and procurement requirements:  Gartner projected that by 2025, 60% of organizations procuring mission-critical software would mandate SBOM disclosure. Enterprise procurement teams are increasingly requiring SBOMs as a standard contract term.

Frequently asked questions

What is an SBOM in cybersecurity?

An SBOM (Software Bill of Materials) is a machine-readable inventory of every software component, library, and dependency in an application. In cybersecurity, it is used to identify which applications contain a vulnerable component when a new CVE is disclosed, verify the integrity of software components, and demonstrate compliance with supply chain security requirements.

What is the difference between a source code SBOM and a binary SBOM?

A source code SBOM is generated from declared dependencies in manifest files (package.json, Podfile, build.gradle). It lists the dependencies developers wrote down. A binary SBOM is generated by analyzing the compiled artifact and lists every component actually present in the software that ships, including undeclared transitive dependencies and third-party SDKs that are linked at build time.

For mobile apps, binary SBOMs provide more complete coverage because many SDK dependencies are not declared in source manifests.

What formats are SBOMs produced in?

The two dominant formats are SPDX (ISO/IEC 5962:2021), which is strong for license compliance, and CycloneDX (OWASP standard), which is designed for security use cases, including vulnerability tracking and supply chain security. Both are accepted for US federal compliance under Executive Order 14028.

Is SBOM a legal requirement?

SBOM is legally required for software sold to US federal agencies under Executive Order 14028, for medical devices submitted to the FDA under the 2022 regulation, and will be required under the EU Cyber Resilience Act as it phases in across 2025-2027. Many enterprise procurement contracts now include SBOM disclosure requirements independently of regulatory mandates.

How does Appknox generate SBOMs for mobile apps?

Appknox generates binary-based SBOMs from compiled .ipa (iOS) and .apk (Android) files as part of every automated security scan. No source code access is required. The SBOM is generated from the artifact shipped to users, capturing third-party SDK components and transitive dependencies that do not appear in source manifests. SBOMs are generated in CycloneDX format and updated on every build.

Related:  The Definitive SBOM Guide | SBOM for Incident Response | SBOM for DevSecOps Teams | What is MAST? | What is Penetration Testing?

 By Aadarsh Anand, Security Researcher, Appknox Security Research Team 

Appknox is an enterprise mobile application security testing platform. This page was written by Appknox's security research team based on direct experience generating binary-based Software Bills of Materials from compiled iOS and Android app artifacts, identifying third-party SDK supply chain risk, and producing SBOM-backed compliance evidence for enterprise mobile app portfolios.

This page was drafted with AI assistance and reviewed and verified by the Appknox security research team.