CycloneDX SBOM for Mobile Apps: Why Your Supply Chain Audit Starts at the Binary

TL;DR: - A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your software. US Executive Order 14028 and the EU Cyber Resilience Act now require them. - CycloneDX (OWASP) and SPDX (Linux Foundation) are the two main SBOM standards. CycloneDX is purpose-built for security use cases and supports software, hardware, vulnerability, and operations BOMs. - Source-level dependency files like Podfile.lock and build.gradle miss transitive dependencies, pre-built SDKs, and statically linked libraries. Binary-level SBOM generation catches what source analysis cannot. - The NTIA defines minimum SBOM elements: supplier name, component name, version, unique identifier, dependency relationship, author, and timestamp. If your SBOM is missing any of these, it won't satisfy regulatory requirements.

What is an SBOM and why does it matter now?

A Software Bill of Materials, or SBOM, is a structured, machine-readable inventory of every component shipped inside a piece of software. Think of it as an ingredients label for your application. It lists every library, framework, and module that made it into the final artifact, along with version numbers, licenses, and supplier information.

The concept isn't new, but regulatory pressure has made it urgent.

US Executive Order 14028

In May 2021, the White House issued Executive Order 14028, "Improving the Nation's Cybersecurity." Among its requirements: any software sold to the US federal government must include an SBOM. This applies to commercial off-the-shelf software, cloud services, and yes, mobile applications used by government agencies. NIST followed up with guidance on minimum SBOM elements, and the NTIA published its minimum elements specification.

EU Cyber Resilience Act

The EU Cyber Resilience Act (Regulation 2024/2847) goes further. It requires SBOM for all "products with digital elements" sold in the EU market. That includes mobile applications. The CRA mandates that manufacturers identify and document vulnerabilities in components, maintain SBOMs throughout the product lifecycle, and provide them to market surveillance authorities upon request.

These aren't aspirational guidelines. They carry enforcement mechanisms and financial penalties.

CycloneDX vs SPDX: which standard should you use?

Two SBOM standards dominate the industry. Both are mature, well-supported, and actively maintained.

Aspect	CycloneDX	SPDX
Governance	OWASP Foundation	Linux Foundation
Current version	1.7 (2025, ECMA-424 2nd Ed.)	3.0 (2024); 2.3 is ISO/IEC 5962:2021
Formats	JSON, XML, Protocol Buffers	JSON, XML, RDF, Tag-Value, YAML
ISO standard	ECMA-424 (not ISO)	Yes (ISO/IEC 5962:2021)
BOM types	SBOM, HBOM, OBOM, CBOM, MBOM, AI/ML-BOM, SaaSBOM, VEX	SBOM focused, VEX via SPDX 3.0 Security Profile
Primary strength	Security and risk analysis, vulnerability tracking	License compliance, provenance tracking
Tooling ecosystem	cdxgen, Trivy, Syft, OWASP Dependency-Track	FOSSology, Tern, sw360, Syft
Vulnerability linking	Native VEX support integrated into BOM	Separate VEX document or SPDX 3.0

For mobile app security and compliance, CycloneDX is the more natural fit. Its native support for vulnerability exploitability exchange (VEX), multiple BOM types, and tight integration with security tooling make it the preferred choice when supply chain risk is your primary concern. SPDX is the stronger choice when license compliance and legal provenance are the priority.

In practice, many teams generate both. The tooling supports it, and some procurement contracts specify one or the other.

Why do mobile apps need binary-level SBOMs?

This is where most SBOM strategies fall apart for mobile development.

Source-level dependency lists are incomplete

When you run a standard SBOM generator against your project directory, it reads your lockfiles: Podfile.lock, build.gradle, package-lock.json, pubspec.lock. These files describe what your package manager resolved at build time. They do not describe what ended up in your compiled binary.

The gap is significant for mobile apps because of three factors.

Transitive dependencies. Your Podfile lists 12 pods. Podfile.lock resolves to 45. A Gradle dependency with three direct libraries fans out to 30 transitive artifacts. Source-level tools often capture direct and first-level transitive dependencies but miss deeply nested ones, especially when the resolution involves platform-specific variants.

Pre-built SDKs. Many mobile SDKs distribute as pre-compiled .xcframework or .aar files. These are opaque binaries. Your package manager knows the top-level package name and version, but it has no visibility into what libraries, fonts, or modules the vendor bundled inside. A pre-built SDK can contain its own copy of OpenSSL, a JSON parser, or an analytics module, none of which appear in your lockfile.

Statically linked libraries. When libraries are statically linked into your binary, they become part of your executable code. There is no runtime reference, no dynamic linking record, and no metadata in the compiled output that a source-level scanner can trace back. The code is simply there, invisible to anything that doesn't analyze the binary itself.

The binary is what gets reviewed

Apple and Google review your compiled binary, not your source code. Regulatory bodies requesting SBOMs want to know what you shipped, not what your build system intended to ship. An SBOM built from source is a statement of intent. An SBOM built from binary analysis is a statement of fact.

For a detailed look at what hides in compiled mobile app binaries, see SDK Inventory: What's Inside Your App Binary.

Anatomy of a CycloneDX SBOM

A CycloneDX SBOM is a structured document listing every component in your software. Here is a simplified JSON example showing the key fields:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "version": 1,
  "metadata": {
    "timestamp": "2026-04-16T10:00:00Z",
    "component": {
      "type": "application",
      "name": "com.example.myapp",
      "version": "3.2.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "firebase-analytics",
      "version": "21.5.0",
      "purl": "pkg:maven/com.google.firebase/firebase-analytics@21.5.0",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a1b2c3d4e5f6..."
        }
      ]
    }
  ]
}

The key fields:

• bomFormat / specVersion: Identifies this as a CycloneDX 1.7 document.
• metadata.timestamp: When the SBOM was generated. Required by NTIA minimum elements.
• metadata.component: The top-level application being described.
• components[].type: What kind of component this is (library, framework, application, device, firmware).
• components[].purl: Package URL, a standardized way to identify and locate a software package. The format is pkg:<type>/<namespace>/<name>@<version>. This is the unique identifier that tools use to cross-reference vulnerabilities and licenses.
• components[].licenses: SPDX license identifiers for the component.
• components[].hashes: Cryptographic hashes for integrity verification.

How to generate an SBOM for your mobile app

Source-level tools

Several mature tools can generate CycloneDX SBOMs from your project files:

cdxgen (OWASP) supports Gradle, Maven, CocoaPods, Swift Package Manager, npm, and Flutter/Dart. It reads lockfiles and project configurations to produce a CycloneDX BOM.

Syft (Anchore) is a general-purpose SBOM generator that supports both CycloneDX and SPDX output. It can scan project directories, container images, and archives.

Trivy (Aqua Security) is primarily a vulnerability scanner but can generate CycloneDX SBOMs from project directories and container images.

These tools work well for what they can see. The limitation is structural: they operate on source artifacts and lockfiles, not on the compiled output.

Why binary scanning fills the gap

Source-level tools cannot detect components that enter your binary through pre-compiled SDKs, static linking, build-time code generation, or vendored source files that aren't managed by a package manager. For mobile apps, this blind spot is substantial.

Binary-level analysis examines the compiled artifact directly. It identifies libraries by matching symbols, strings, class names, and embedded metadata against known SDK signatures. This approach discovers components regardless of how they entered the binary.

AppCompliance generates CycloneDX-compatible component inventories from binary analysis of IPA, APK, and AAB files, capturing SDKs and libraries that source-level tools miss.

The strongest SBOM strategy combines both approaches: source-level generation for the components your package manager tracks, and binary analysis to catch everything else.

NTIA minimum elements checklist

The National Telecommunications and Information Administration (NTIA) published minimum elements that an SBOM must contain to be useful. Use this as a validation checklist:

Element	Description	CycloneDX field
Supplier name	Who supplied the component	components[].supplier.name or components[].publisher
Component name	Name of the software component	components[].name
Version	Version identifier	components[].version
Unique identifier	Unambiguous reference to the component	components[].purl or components[].cpe
Dependency relationship	Which components depend on which	dependencies[] section
Author of SBOM data	Who generated the SBOM	metadata.authors[]
Timestamp	When the SBOM was generated	metadata.timestamp

If your generated SBOM is missing any of these fields, it does not meet the NTIA minimum. Most tooling fills these automatically, but pre-built and vendored components often lack supplier information and dependency relationships. These gaps require manual enrichment or binary-level analysis to fill.

Integrating SBOM into your workflow

An SBOM generated once and filed away provides limited value. The real benefit comes from integrating SBOM generation into your development lifecycle.

CI/CD pipeline integration

Generate a fresh SBOM on every release build. This ensures the SBOM reflects the actual artifact you ship. Most SBOM tools have CLI interfaces that integrate into GitHub Actions, GitLab CI, Bitrise, or any build system that runs shell commands.

A typical pipeline step:

1. Build the app binary (IPA, APK, or AAB).
2. Run source-level SBOM generation against the project directory.
3. Run binary-level analysis against the compiled artifact.
4. Merge or compare both SBOMs to identify discrepancies.
5. Store the SBOM alongside the build artifact in your release repository.

Vulnerability monitoring

An SBOM becomes a living document when you feed it into a vulnerability tracking system. Tools like OWASP Dependency-Track ingest CycloneDX SBOMs and continuously monitor for new CVEs against your component inventory. When a vulnerability is disclosed for a library in your SBOM, you get notified immediately, even for components you didn't know were in your binary.

Compliance reporting

For EU CRA compliance, you need to demonstrate that you maintain an up-to-date SBOM and actively monitor for vulnerabilities in your components. For US federal procurement, you need to provide the SBOM on request. Automated generation tied to your release process creates an auditable trail that satisfies both requirements.

Store SBOMs in a versioned repository alongside their corresponding build artifacts. Tag them with the app version and build number. This gives compliance teams and auditors a clear mapping from any shipped version to its complete component inventory.

Frequently asked questions

Do I actually need an SBOM for my mobile app?

If you sell software to US federal agencies, yes, it's required under EO 14028. If you distribute a mobile app in the EU, the Cyber Resilience Act will require it for products with digital elements. Even without regulatory mandates, an SBOM gives you visibility into your supply chain, which helps with vulnerability response, license compliance, and store review preparation. The trend is clear: SBOM is becoming a baseline expectation, not an optional extra.

Which format should I choose, CycloneDX or SPDX?

For most mobile development teams focused on security and compliance, CycloneDX is the practical choice. It has strong tooling support, native vulnerability tracking, and a clear component model. If your legal team needs detailed license provenance, SPDX may be more appropriate. Many tools like Syft generate both formats from the same scan, so you don't have to commit to one exclusively.

How often should I regenerate my SBOM?

Generate a new SBOM for every release build. If your app ships weekly, your SBOM updates weekly. Tying generation to your CI/CD pipeline ensures the SBOM always matches an actual artifact. Between releases, monitor the existing SBOM against new vulnerability disclosures.

What about closed-source SDKs where I can't see the source?

This is exactly where binary-level analysis matters. Closed-source SDKs distributed as .xcframework or .aar files are opaque to source-level tools. Binary analysis can identify bundled libraries, detect known SDK signatures, and surface components that the vendor may not document. Your SBOM should reflect what's in the binary, not just what the vendor's changelog mentions.

What are the regulatory deadlines I should track?

US EO 14028 requirements are already in effect for federal software procurement. The EU Cyber Resilience Act entered into force in late 2024, with a transition period before full enforcement. Most obligations will apply by late 2027. Manufacturers should start generating and maintaining SBOMs now to build the processes and tooling before deadlines hit.

How does AppCompliance help with SBOM generation?

AppCompliance analyzes your compiled IPA, APK, or AAB binary to identify every SDK and library present in the final artifact. This binary-level component inventory captures transitive dependencies, pre-built frameworks, and statically linked libraries that source-level SBOM tools miss. The result is a more complete picture of what you actually ship.