Application Binary Interface

What the application binary interface defines

An application binary interface, or ABI, is the machine-level contract that lets separately compiled code interoperate correctly. It fixes expectations for how functions are called, how arguments and return values are passed, how data structures are laid out in memory, and how symbols are named and resolved across object files and libraries.

Because the ABI operates below source code, it is the point where a program stops being an abstract design and becomes something the operating system, linker, runtime, and CPU must all agree on. A source-compatible change can still break binary compatibility if the ABI changes.

Why ABI compatibility matters

ABI compatibility determines whether an executable, library, plugin, driver, or runtime component can be mixed with another build without corruption or crashes. If two components disagree on calling convention, alignment, endianness, register use, or object layout, the result can be subtle failure rather than an obvious load-time error.

This is why ABI stability matters so much for shared libraries, operating system interfaces, language runtimes, and plugin ecosystems. Teams often treat source compatibility as sufficient, but binary interfaces are what users and downstream systems actually execute. A small change in structure packing or parameter passing can turn into runtime instability, incorrect data interpretation, or undefined behaviour.

Common sources of ABI breakage

ABI breaks often come from changes that look minor at the source level: reordering structure fields, changing type sizes, altering enum widths, modifying calling conventions, or introducing different compiler flags that affect packing or symbol visibility. Even architecture differences, such as 32-bit versus 64-bit assumptions, can create incompatible binaries.

Versioned libraries and language runtimes try to contain this risk by preserving stable entry points and documenting compatibility expectations. In practice, ABI discipline is as much about governance as engineering, because once binaries are distributed, consumers may depend on details that the original authors did not intend to make permanent.

How ABI affects security and reliability

An ABI is not a security control by itself, but it can shape reliability, trust boundaries, and exploitability. Mismatched layouts or calling conventions can produce memory corruption, crashes, or silent data misinterpretation, and those failures can become security-relevant when they affect parsers, privilege-bearing components, or security-sensitive libraries.

ABI assumptions also matter in patching and hardening. If an update changes binary interfaces unexpectedly, teams may delay deployment, pin vulnerable versions, or introduce compatibility shims that widen the attack surface. For that reason, ABI stability is part of resilient software delivery, especially where vendors, plugins, kernels, and cryptographic or authentication modules must interoperate cleanly.

Practitioner Guidance

Why practitioners should care: Treat ABI compatibility as a release and integration requirement, not just a compiler detail. When you ship libraries, runtimes, or plugins, binary compatibility failures usually surface only after deployment and can be harder to diagnose than ordinary build errors.

What to watch for: Pay close attention to changes in exported symbols, structure definitions, compiler options, and platform-specific calling conventions. If a change alters how compiled components exchange data, assume downstream breakage until compatibility has been checked at the binary level.

Related resources from NHI Mgmt Group

• Why do obfuscation and binary hardening not solve application security by themselves?
• Why can a container policy look correct but still fail to stop application access to a sensitive binary?
• What is the difference between API versioning and a canary deployment when introducing a new application interface?
• How should security teams handle a GWT application that still depends on binary Java serialization?