Software Supply Chain Security

Software supply chain security is the practice of managing risk across every third-party component, dependency, and build process that goes into a piece of software, not just the code an organization writes itself. For a mobile app, that means the SDKs, open-source libraries, and build tools compiled into the binary, often written by people the team building the app has never met.

This isn't physical supply chain security. No shipping containers, no factory risk. The chain here is made of code, and the weakest link is usually a dependency nobody on the team wrote or reviewed.

Why it matters, specifically for mobile

Most software isn't built from scratch anymore. Gartner estimates third-party code makes up 40% to 80% of a typical application.

Mobile apps concentrate that risk further: a single SDK, for analytics, payments, or advertising, gets compiled directly into the binary and ships to every user, with the same access to the device as the app's own code.

OWASP tracked this shift directly.
When the OWASP Mobile Top 10 refreshed in 2024, Inadequate Supply Chain Security entered the list at #2, a category that didn't exist at all in 2016.

What it actually covers

Software supply chain security covers four things, mainly:

Dependency and third-party risk

To know what's inside a build: which SDKs, which open-source libraries, which versions, and whether any carry a known vulnerability. This is what an SBOM inventories.

Build pipeline integrity

Software supply chain security checks whether the process that compiles source code into a shipped binary can itself be tampered with, separate from whether the source code is clean. This was the actual mechanism behind the SolarWinds breach.

Attackers never touched SolarWinds' source repository. Malware sitting on the build servers inserted a backdoor into a temporary file used only during compilation, then deleted itself once the build finished. The resulting binary was signed with SolarWinds' own legitimate certificate.

An SBOM generated from that build would have listed a perfectly clean set of components, because the components genuinely were clean. The backdoor lived in the process, not the parts list.

Provenance and code signing

To verify a component came from where it claims to, and hasn't changed since. Frameworks like SLSA and tools like Sigstore exist specifically to make this checkable instead of assumed.

Malicious package injection

Attackers publishing deliberately malicious packages under names close to popular ones, hoping a typo or a compromised maintainer account gets the fake one pulled into someone else's build.

Where SBOM fits

SBOM is the tool for the first category above, and the most mature one. It doesn't cover the other three on its own. A clean SBOM tells you what's supposed to be in a build. It can't tell you

• Whether the build process that produced it was compromised,
• Whether a component's origin was verified, or
• Whether a dependency was swapped for a malicious lookalike after the SBOM was generated.

That's not a flaw in SBOM. It's a scope boundary worth knowing, especially before assuming SBOM alone satisfies the full discipline.

For the full breakdown of what an SBOM is and how it's generated,

See: What is SBOM?

Where Appknox fits

Appknox's supply chain coverage centers on the first category: binary-based SBOM generation that inventories every third-party SDK and library compiled into a mobile app, flagged against known vulnerabilities.

Appknox doesn't currently verify build-pipeline provenance the way SLSA or Sigstore do; that's a distinct capability outside binary analysis.

For the mobile-specific dependency risk that Appknox does address, this is where most of a mobile app's actual attack surface sits.

See how Appknox generates an SBOM from the compiled binary: SBOM.

Frequently asked questions

What is software supply chain security?

Software supply chain security is the practice of managing risk across every third-party component, dependency, and build process that goes into a piece of software, not just the code an organization writes itself.

Is this the same as physical supply chain security?

No. Physical supply chain security covers shipping, manufacturing, and logistics risk. Software supply chain security covers code: dependencies, build processes, and component provenance.

Is SBOM the same as supply chain security?

No. SBOM is one tool within supply chain security, covering dependency visibility. Build pipeline integrity, provenance, and malicious package injection are separate risks an SBOM alone doesn't address.

Why did OWASP add supply chain security to the Mobile Top 10?

OWASP added supply chain to the Mobile Top 10 because third-party SDKs and libraries now make up a large share of a typical mobile app's code, and that code ships with the same device access as the app's own code. The category, Inadequate Supply Chain Security, entered the OWASP Mobile Top 10 2024 list at #2.

Does Appknox cover software supply chain security?

Appknox generates a binary-based SBOM for every build, inventorying third-party SDKs and libraries and flagging known vulnerabilities. It doesn't currently verify build-pipeline provenance.

Related: What is an SBOM? | What is OWASP Mobile Top 10? | Appknox Automated Vulnerability Assessment

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 mapping third-party SDK and dependency risk across financial services, healthcare, and enterprise mobile app portfolios.

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