Supply Chain Security

If you ship an app built on OpenIAP, its dependencies become part of your product. This section covers what OpenIAP publishes so you can answer questions about that — for a security review, a customer questionnaire, or a regulator.

What current release workflows publish#

Artifact	What it answers
CycloneDX SBOM	Which direct runtime components and dependency contracts this version declares, including first-party OpenIAP native contracts, with versions or constraints, package URLs, suppliers, and licenses where available
Provenance attestation	Cryptographic proof that the SBOM was produced by OpenIAP's CI from a specific commit, not written by hand
npm provenance	For npm packages, that the published tarball was built from this repository
Release tag and commit	Which full source commit the release tag points to, verified at publication and again during later checks

See SBOM for how to download and verify one.

Dependency posture#

The published JavaScript package manifests declare no npm runtime dependencies. React, React Native, and Expo are peer dependencies your application owns and versions. The Expo and React Native release SBOMs separately include the native CocoaPods and Maven contracts resolved by those packages;openiap-conformance has no such native layer.

The Apple SDK has no external package dependencies either — it builds on StoreKit, which ships with the OS. The native Android, Kotlin Multiplatform, .NET MAUI, and Flutter SDKs do depend on platform libraries (Play Billing, AndroidX, Kotlin coroutines, and so on); their release SBOMs enumerate the published direct dependency contracts.

Reporting a vulnerability#

Report privately — do not open a public issue. Email hyo@hyo.dev with the subject prefix [SECURITY], or use GitHub's private vulnerability reporting on the repository.

If the issue is being exploited in the wild, mark it [SECURITY][ACTIVE]. That triggers an accelerated path: an initial assessment within 24 hours, an updated assessment within 72 hours, and a final assessment within 14 days after a fix or mitigation is available. This is OpenIAP's internal service level; legal reporting duties depend on the affected party's role and the event.

Receipt validation, purchase verification, and entitlement handling are the highest-sensitivity areas. The full policy, including what does and does not count as a vulnerability, is in SECURITY.md.

When each thing runs#

The repeatable CI, release, inventory, and scheduled scan controls are automated. Vulnerability reports still require maintainer triage, remediation, and communication.

Trigger	What happens automatically
Every pull request	The SBOM parser and workflow fault tests run alongside release-state audits, so an unsupported dependency shape or an undispatched release lane fails before merge
Merge to main	A change to the SBOM workflow or generator scans the newest stable release of every component and dispatches any missing inventory
A release is published	The release workflow dispatches SBOM generation for its tag. The SBOM job verifies the identity, attests the inventory, attaches it, then downloads and verifies the published asset again
Daily	The missing-SBOM safety net runs. Dependabot and OpenSSF Scorecard also re-check the dependency and repository posture on their schedules
A vulnerability is reported	The response path above — accelerated if it is being actively exploited

The important design choice: SBOMs are generated after a release is published, not on every commit. A release tag is the only moment an inventory is meaningful. Every release lane must dispatch the shared SBOM workflow, and CI checks that wiring.

How dependencies are monitored#

OpenIAP submits all six Bun lock graphs as exact dependency snapshots for repository vulnerability monitoring — coverage motivated by ecosystem-scale research showing a handful of unmaintained packages or compromised maintainer accounts can reach most of a dependency network (USENIX Security 2019). React Native's Yarn graph remains covered by GitHub's native lockfile support and the independent OSV scan. Its CocoaPods toolchain has a committed Bundler lock, a pinned Ruby CI runtime, OSV coverage, and Dependabot updates. Other Dependabot version-update pull requests stay focused on IAPKit, GitHub Actions, and the IAPKit container image.

Native SDK platform dependencies are pinned deliberately — several carry inline notes explaining why a newer version is not yet compatible with the supported toolchain range. They are reviewed as part of platform upgrade work rather than bumped automatically, and each published release's SBOM records its published direct dependency contract. A toolchain resolver export can add transitive entries when needed.

Repository posture#

Three layers cover different things, and none substitutes for another:

Dependabot — which dependencies does GitHub report as outdated or vulnerable in the monitored and submitted graphs?
SBOM — what dependency contract did each published version declare?
OpenSSF Scorecard — is the process that produced it sound? It checks branch protection, workflow token permissions, action pinning, and dangerous workflow patterns, and publishes a score anyone can verify