“Why are there almost no CVEs listed for Delphi or its 3rd-party components?”

Have you ever asked yourself why your Delphi application works perfectly on your development machine, but fails when deployed to a client’s environment? Or why you suddenly discover you need to download and install external drivers or runtimes—like OpenSSL, MDAC, MySQL connectors, or WinZip?

They were part of your toolchain all along. And under modern regulatory frameworks (CRA, DORA), you are expected to declare them in your SBOM upfront.

The reason these dependencies trip up deployment—and compliance—is simple: Delphi and its component ecosystem are largely wrappers around the native libraries, C engines, and OS APIs that actually run your application.

This is precisely what made Delphi so legendary in the first place: RAD (Rapid Application Development) stands for easy-to-use wrappers that hide low-level native complexity behind elegant, event-driven Pascal interfaces.

Ever Wondered Why Delphi Compiles So Fast?

This wrapper architecture is also the secret behind Delphi’s mind-blowing compilation speed.

When you hit F9, the compiler isn’t sitting there parsing complex C math or template metaprogramming from scratch. The heavy C code (aes.obj, zlib.obj, sha2.obj) was already compiled years ago by C compilers into pre-built binary byte-code. Delphi’s single-pass compiler simply compiles your Pascal wrappers and stitches those pre-compiled binary chunks directly into your executable.

It’s brilliant engineering for developer productivity—but in the 2026 security era, it creates a massive visibility illusion.

The Delphi SBOM Illusion: What You Know, What You Guess, and What You Don’t Know You Don’t Know

If you ask a Product Manager or Software Architect building in Delphi what their SBOM (Software Bill of Materials) contains, they will likely hand you a clean list: the Delphi RTL, a few VCL components from TMS or DevExpress, maybe Indy, and a database connection through FireDAC.

On paper? Everything looks green, organized, and fully compliant.

In actual RAM? It is a complete illusion.

Legacy Delphi systems do not actually execute purely on clean Object Pascal code. Beneath the surface, your application is a complex puzzle of C libraries, COM interfaces, resource payloads, native drivers, and internal system calls:

• OpenSSL Dependencies (Indy vs. THTTPClient):
  • If you use Indy (TIdHTTP), your app relies on dynamic loading of external C binaries: libeay32.dll / ssleay32.dll (OpenSSL 1.0.2) or libcrypto-1_1.dll / libssl-1_1.dll (OpenSSL 1.1.1). If those DLLs sit in your app folder, their CVEs belong in your SBOM.
  • If you switch to System.Net.HttpClient.THTTPClient, Delphi bypasses external OpenSSL DLLs on Windows and delegates TLS directly to the OS via SChannel (secur32.dll / schannel.dll). The same Pascal code changes your entire security supply chain from a bundled binary risk to an OS baseline risk.
• Embedded C Engines via {$LINK}: When you use a cryptography or compression component (such as TMS Cryptography or Zip), Delphi’s linker merges pre-compiled C Object files (.obj / .o) directly into your binary executable. The binary code of aes.obj, sha2.obj, or ECDSAp256.obj executes directly out of your process memory. If a CVE exists in the original C engine—it lives inside your executable, even if there is no DLL on the disk.
• FireDAC is Only the Bridge: A TFDConnection component does not talk directly to a database network protocol on its own. At runtime, it executes dynamic LoadLibrary calls to pull native C/C++ libraries into memory (libpq.dll, sqlite3.dll, libmysql.dll, MDAC/OLEDB providers). If you only declare FireDAC in your SBOM, you miss the exact binary exposed to the network.
• Resource Payload Binaries ({$R} / .res / .rc): Delphi applications frequently embed compiled binary assets—such as third-party .dll installers, ActiveX controls, SQLite databases, or certificate bundles—directly into the executable’s resource segment using {$R *.res} or Resource Compiler scripts (.rc). Because they exist as compiled byte arrays inside resources, standard source-code scanners ignore them entirely.
• Include File Architecture ({$I} / .inc): Enterprise Delphi projects rely heavily on {$I filename.inc} directives to inject global compiler definitions or API endpoints across hundreds of units. If an .inc file pulled from a third-party vendor contains malicious code or altered compiler directives, it mutates the security posture of every unit that includes it—without ever showing up as a distinct component in a standard unit-level audit.
• ActiveX, COM, and DCOM Invocations: Calling CreateOleObject('WScript.Shell'), CreateOleObject('Excel.Application'), or connecting via DCOM instantiates external system components via Windows Registry CLSIDs into your process memory or remote RPC servers. These COM/ActiveX GUIDs represent invisible binary runtime dependencies that source code scanners ignore.
• OS Shell & Process Execution: Invocations like ShellExecute, CreateProcess, or WinExec spawn external system binaries (cmd.exe, powershell.exe, certutil.exe). These executables run outside your process memory but constitute part of your application’s operational blast radius and supply chain behavior.
• Kernel Calls & OS Baselines: Native components rely heavily on Microsoft system runtime libraries (msvcrt.dll, advapi32.dll). Knowing where the OS baseline ends and where a reportable third-party dependency begins is critical for compliance.

What We Don’t Know We Don’t Know (The Unknown Unknowns)

1. Frozen-in-Time C Dependencies: When was the last time you checked which toolchain or C release was used to compile the .obj file inside a VCL package you bought in 2018? If the component vendor pulled C source code from 2015, you are executing an unpatched, decade-old cryptographic engine in RAM—without any visibility from reading your own Pascal source code.
2. Hidden Dynamic Bindings in Compiled DCUs: How many LoadLibrary, CreateOleObject, or ShellExecute calls are hidden inside closed-source .dcu files for which you lack source code? Standard source-code AST scanners cannot see them, and your customer’s EDR agent will only detect them when they fire in memory at runtime.
3. Unscanned Resource Payloads: How many embedded .res files inside your build pipeline contain legacy 32-bit third-party DLLs or binaries that haven’t been audited or re-compiled in over a decade?
4. Blind Faith in Vendor Declarations: When a VCL vendor claims full compliance or support for a specific protocol, how much of that code was written natively in Pascal, and how much is merely a wrapper around an unmaintained open-source C library?

The Bottom Line

Most SBOM declarations produced today for Delphi applications serve primarily as paperwork to appease auditors who do not understand Native Executables.

As long as the industry measures SBOMs by .pas and .dcu source files rather than what actually dumps into process memory at runtime, legacy software will continue to operate on borrowed time.

Anyone seeking real security rather than regulatory compliance must deconstruct the executable from a bird’s-eye view—OBJ binaries, resource payloads, include files, dynamic DLLs, COM/ActiveX objects, and system calls included.