When regulators, customers, and insurers started asking for a software bill of materials (SBOM), most engineering teams had a confident answer ready for their newest applications. Modern build-pipelines can generate an SBOM on their own. A tool reads the dependency manifest, produces a machine-readable inventory in a standard format, and attaches it to the release. For a new application, the ingredients list for software is close to a solved problem.
Then someone asks the harder question. What about the payroll system that has quietly run the back office since 2009? The custom order-management platform that arrived three acquisitions ago? The homegrown reporting engine that no current employee fully understands? Those systems touch real data every day, and almost none of them can produce a bill of materials on demand.
That gap is where software transparency stops being a checkbox and starts being a problem.
Two Very Different Problems, One Name
The 2026 Minimum Elements for a Software Bill of Materials, published by CISA alongside the NSA, FBI, and a coalition of international cyber agencies, apply to all software. The expectations are specific. An SBOM has to identify each component and its version, provide unique identifiers, record cryptographic hashes and license terms, describe how components depend on one another, and carry metadata about who generated the document and with what tool. In practice that means a machine-readable file in a format such as SPDX or CycloneDX.
For a team building something new, meeting that list is mostly a configuration exercise. The dependencies are declared, the build system already knows them, and the tooling does the rest. For a legacy custom system, the same list reads more like an archaeology assignment. The dependencies were never declared in a form a tool can read, and the knowledge that would fill the gaps left the building years ago.
Should Legacy Systems Face the Same Standard?
This is the question boards and security leaders keep circling. A company that sells software has a clear and growing obligation to ship an SBOM. The European Union’s Cyber Resilience Act now requires manufacturers of products with digital elements to include one in their technical documentation, and federal contracting increasingly expects the same. But a back-office system that a company built for its own use and never sold is not, in the strict sense, a manufactured product. Should it carry the manufacturer’s burden?
In a narrow legal reading, the answer is often no. The CISA minimum elements are voluntary baseline guidance, not a blanket mandate that reaches every internal system. That is the wrong place to stop, though, because the risk does not care about the distinction. When the next widely exploited component vulnerability lands, the question your team must answer in hours is simple. Are we exposed, and where? A system that cannot list its own components cannot answer. Cyber-insurance underwriting, private-equity technical diligence, and customer security questionnaires are all converging on the same expectation, whether or not a statute happens to name your software.
So, the honest position is this. Your legacy systems may not owe an SBOM to a regulator, but they owe one to you.
Why You Cannot Just Run a Tool
The reason modernization teams dread this work is that older custom systems break nearly every assumption SBOM tooling depends on. There is often no dependency manifest and no build that emits one. Third-party code was frequently copied into the source tree rather than imported, so it hides in plain sight with no version or origin attached. Homegrown libraries, abandoned modules, and dead code accumulate over the years, and the provenance of much of it is simply unknown.
The 2026 guidance anticipates some of this. It allows an SBOM author to state explicitly when information is unknown rather than pretend to certainty. That honesty is useful, but it is not a strategy. An SBOM that is mostly unknown satisfies the format and does almost nothing for your risk. The work that matters involves reducing the unknowns, and that requires reading the software as it actually exists, not as anyone remembers it.
Aspen Codex™: The Record Your Systems Never Had
This is where a team facing an audit, a mandate, or a diligence request needs a guide rather than another tool license. Aspen Codex™ is Aspen’s documentation solution, built to reconstruct the record that legacy custom applications were never given.
Instead of relying on interviews and best guesses, Aspen Codex™ works from analysis of the actual code. Aspen’s modernization practice is grounded in deep code analysis, independently validated through our partnership with Silverthread and its CodeMRI® platform, and Aspen Codex™ applies that same rigor to the transparency problem. The result is a component inventory and a bill of materials expressed in the standard machine-readable formats, mapped to the CISA minimum elements, along with the surrounding system documentation that legacy teams almost always lack. Architecture, dependencies, and the true shape of the system come into view together, rather than as a scatter of tribal knowledge.
Because that inventory comes from the code rather than from folklore, it becomes a foundation you can build on. The same understanding that produces a defensible SBOM is what any responsible modernization effort needs first. You cannot safely modernize, or responsibly layer AI onto, a system you cannot see. Aspen Codex™ is how you start seeing it.
A Plan, Not a Scramble
Meeting SBOM expectations across a legacy portfolio does not have to become a year-long engagement with a large systems integrator. A workable path is more focused than that. Inventory the applications that carry real operational or regulatory weight. Prioritize them by exposure rather than by age. Produce documented, code-derived SBOMs for the systems that matter most. Then keep those records current as the software changes.
Handled that way, software transparency stops being a threat hanging over your oldest systems and becomes something closer to an asset. You gain a clear account of what you run, why it behaves the way it does, and where your real risk sits.
Book a Call with Aspen
If regulators, customers, or your own board are asking what is inside your legacy systems, and you do not yet have a confident answer, let’s talk. Aspen can help you turn undocumented custom software into a clear, defensible record, and give your modernization roadmap a foundation it can stand on.
Schedule a discovery chat: https://calendly.com/aspen-ess/aspen-ess-discovery-chat
