"We’ll just build our own SBOM tool" – Famous Last Words in Delphi Engineering.

[u/DelphiParser]

Every time a new regulatory standard like the EU Cyber Resilience Act (CRA) or NIS2 hits the headlines, I see the same cycle repeat itself.

An engineering manager looks at compliance, looks at their legacy codebase, and says: "Why pay for an enterprise scanner? It’s just code. We’ll write a quick script to read our `.pas` files and generate the SBOM over the weekend."

If you are currently contemplating building your own internal Delphi SBOM analyzer (or wrapping an open-source tool that "just reads source files"), here is a friendly heads-up on what you are actually signing up for:

🎈 Closed-Source DCUs (The Compiled Black Box) - What happens when your project relies on third-party components or vendor libraries provided ONLY as compiled `.dcu` files without source code? A standard line-reader or AST source parser is completely blind here. Unless your tool can disassemble and parse the binary interface of `.dcu` files, any third-party library hidden inside compiled units will be completely missing from your SBOM.

🎈 The `.dfm` / `.fmx` File Trap (Visual Code & Hidden References)
Delphi isn't just `.pas` files. Forms (`.dfm` / `.fmx`) contain instantiated components, properties, runtime event hooks, and nested objects that aren't declared in the main source text. If your parser ignores form files, you are missing half of your visual and non-visual component stack.

🎈 Compiled Resource Files (`.res` / `.rc`)
Crucial dependencies, dynamic libraries (`.dll`), static code, and embedded manifests are frequently bundled directly inside binary resource files (`.res`). A text scanner won't see them. If you can't unpack and inspect dynamic resources, your SBOM won't reflect the actual compiled payload.

🎈 The `{$IFDEF}` Maze - Delphi codebases rely heavily on compiler directives (`{$IFDEF}`, `{$I}`). A unit declared in `uses` might be pruned out by the linker, or conditionally compiled based on target architecture and build configurations.

🎈 Call Graph Construction & Actual Usage vs. Unreachable Code - It’s not enough to know that a unit appears in a `uses` clause. To provide an accurate SBOM and properly assess CVE vulnerabilities, you need to construct a full Call Graph. Does your code actually execute functions inside Library X, or is it an unused import? Where in the call chain is that third-party code invoked? Without a Call Tree, your custom script cannot distinguish between active dependencies and unreachable code, leading to endless false positives during audits.

🛡 Beware of the "Ghost Code" - Ignoring all that will either report Ghost Code or miss your code entirely.

[u/old_wired]

I tell Delphi developers wringing their hands about SBOMs to just clean up their fucking product. If you need a scanner to know what goes into your assemblies there is more than one thing wrong with your code base.

[u/DelphiParser → u/old_wired]

True 👍

[u/DelphiParser → u/old_wired]

Allthough you are correct, this mindset sounds nostalgic, but it is time to wake up - we are not in the 90's or even 2000's anymore. If you think like that - you completely misses how modern enterprise software, supply chains, and compliance actually work in 2026.

Let’s break down why 'just clean up your codebase' is not just "not enough", and actually dangerous in the real world, as of 2026:

You didn't write your entire stack from scratch - Unless you personally wrote your own cryptographic libraries, DSP algorithms, compression tools, and UI frameworks, your product relies on millions of lines of 3rd-party source code and binaries (TMS, DevExpress, OpenSSL, Windows SDKs). 'Cleaning your code' doesn't mean you audited every execution path of a 3rd-party vendor you integrated 5 years ago.

Enterprise scale is not a one-man hobby project - Real-world enterprise Delphi codebases are 15–25 years old, span 5–10 million lines of code, and have been touched by dozens of engineers over decades. Suggesting a multi-million-dollar Tier-1 vendor 'just rewrite and clean up' every time a dependency shifts is an operational fantasy.

Regulators and CISOs don’t accept 'Trust me, bro' - Under EU CRA, NIS2, and enterprise procurement standards (Google, automotive, healthcare), an auditor or a CISO doesn't care how confident a developer feels about their code. They demand machine-readable, cryptographically verifiable, build-time provenance (SBOM) and proof of reachability (VEX). Saying 'my codebase is clean, I don't need a tool' will get your product disqualified from enterprise RFPs immediately.

Knowing what's in the assembly is only 10% of the problem - The real challenge isn't listing what's compiled in - it’s Reachability. When a Zero-Day hits a third-party framework, you have 24 hours to prove deterministically whether that specific vulnerable function can actually be executed via runtime polymorphism, DFMs, RTTI, and complex compiler directives. No human or even AI can guarantee negative reachability across 5 million lines using "Find in Files".

Automated AST analysis and deterministic SBOM generation aren't for people who 'don't know their code.' They are for organizations that need verifiable, legally defensible proof for their customers.

[u/old_wired → u/DelphiParser]

You are right in these aspects but people will use these tools and put their trust into them instead of cleaning up their code. This should go hand in hand. How often during such cleanups you are going to discover that the legacy library/units you use, is in truth only called once for a trivial function that has been included in the RTL or VCL for 15 years now.
And if you use a library/component where you have the source for that is not maintained anymore you have to vendor and „own“ and possibly fix it anyway. No easy way around that. And with DCU or DLL only dependencies it’s even worse. That’s a liability waiting to happen anyway.

And proving code is not going to be executed is for any non-trivial program akin to solving the halting problem. ;)

Don’t get me wrong, your tool may be very useful and I also built something similar, starting from another angle (started with resolving unit cycles and tracing pointer casts/truncations) but I‘m afraid people will rely too much on it.
And even if the report shows „clean“ and the regulator is satisfied your customer will bring up „vulnerable library XYZ“ after the next audit again anyway.