The operating assumption in most supply chain security conversations is that the code under discussion is modern: Git-hosted, CI/CD-deployed, containerized, written in a language with a rich package ecosystem. COBOL breaks every one of those assumptions. A meaningful share of the world's banking, insurance, airline, and government infrastructure still runs on COBOL, often on IBM z/OS mainframes, with build tooling that predates the concept of a build tool as we currently use the term. The code works, it is not going anywhere, and the institutions that depend on it are under the same regulatory and threat pressure as any other organization.
Modernizing the supply chain around COBOL systems does not mean rewriting them. It means extending the provenance, visibility, and policy discipline that apply to modern systems into the mainframe world, using the tools and cultural patterns that already exist there.
What "supply chain" means for COBOL
The term supply chain evokes open source dependencies, and COBOL does not have an analog to npm or PyPI. What it does have is just as consequential: vendor-supplied copybooks, utility libraries, third-party system software, load modules assembled from multiple sources, and a web of JCL that links them together at runtime.
A COBOL supply chain view therefore covers five categories of input. Application source code is the COBOL programs themselves and the copybooks they include. System software is the z/OS release, the language compiler version, the subsystem products — CICS, IMS, DB2, MQ — and the utilities used in batch. Third-party software is ISV-supplied libraries, tools, and frameworks. Operational tooling is the scheduler, the tape management system, the security manager — RACF, ACF2, or Top Secret — and the change management platform. Human process is the approval and promotion flow that moves code through environments.
A supply chain breach on a mainframe can originate in any of those categories. Modernization means applying the same diligence to each of them that a web application team would apply to its container image and its dependency tree.
Producing SBOMs for COBOL applications
The SBOM concept translates well to COBOL, though the tooling does not exist off the shelf to the degree it does for open source ecosystems. A workable SBOM for a COBOL application captures the program members, the copybooks each program includes, the load modules produced by link-edit, and the subsystem resources the application binds to at runtime.
The mechanical production of the SBOM uses the tools already present in most mainframe shops. The source control system — whether that is Endevor, ChangeMan, RTC, or a modern Git bridge — records which source members contributed to which load modules. The compile and link steps emit listing datasets that enumerate copybook includes and external references. A lightweight job can parse those listings and produce a CycloneDX or SPDX document that conforms to the same standards modern teams use.
The payoff is not philosophical. An SBOM lets you answer the same kinds of questions on the mainframe that open source SBOMs answer elsewhere. Which programs include a given copybook? Which load modules use a specific system utility? When a vendor issues a security advisory for a product, which applications are exposed? Those questions are difficult to answer manually on a large mainframe estate, and they become straightforward once the SBOM exists.
Provenance for mainframe code
Provenance for COBOL code is well supported by the existing change management tooling, often better supported than in modern systems, though the outputs are not always externalized in formats that fit into a broader supply chain program.
Endevor, ChangeMan, RTC, and their peers track who made what change, when, with what approvals, and through which environments. The missing piece is usually an integration that publishes that provenance data to the same platform that tracks provenance for modern systems. A simple export job that emits signed attestations — in-toto or similar — for each production promotion closes that gap and gives security and compliance teams a unified view across mainframe and distributed systems.
The provenance data is also the foundation for policy gates on the mainframe. A promotion from pre-production to production can be blocked programmatically if the SBOM includes a product version with an open advisory, if the approver set does not meet policy, or if the compile chain diverges from the expected one. Those gates are entirely feasible with existing mainframe scheduling and change management tooling; they just need to be built.
Third-party and ISV software
ISV software is where mainframe supply chains most resemble modern open source supply chains, and where the most recent attention has concentrated. Products like file transfer utilities, performance monitors, scheduling tools, and tape management systems are distributed by commercial vendors and sometimes consumed with less scrutiny than an npm dependency would receive on a modern team.
The minimum bar is a vendor inventory that records product name, version, PTF level, license scope, and the business function it supports. The next bar is an advisory feed from each vendor piped into the same intake as CVE data. The bar after that is a policy that requires vendor products to be current within N PTF levels of the latest supported release.
The mainframe vendor ecosystem is small enough that relationships matter. Vendors that respond to security advisories quickly and publish SBOMs for their products are materially easier to operate with than those that do not. Procurement conversations that treat supply chain posture as a selection criterion move the industry forward.
The operational fabric
Modernization is partly tooling and partly process. The process pieces that matter most are the ones that look familiar from the modern side of the house: documented threat models for critical applications, runbooks for advisory response, drills that exercise the incident response path, and metrics that measure how long it takes to go from vendor disclosure to deployed mitigation.
Mainframe teams often already have these practices at high maturity for operational incidents. Extending them explicitly to supply chain incidents — especially vendor advisories and unusual PTF timing — is a modest organizational lift with outsized benefit.
Integration with the rest of the program
The strongest argument for COBOL supply chain modernization is that it makes the rest of the security program coherent. A chief information security officer responsible for both mainframe and distributed systems has a hard time answering basic questions — what is our total exposure to product X, what is our mean time to remediate vendor advisories, what is the shape of our software composition overall — when the two sides of the house produce incompatible data. A unified SBOM format, a unified advisory intake, and a unified provenance model close that gap.
The modernization does not require rewriting COBOL, and should not. It requires treating COBOL with the same supply chain rigor as modern systems, using the tools that already exist, and publishing outputs in formats that the rest of the security program can consume.
How Safeguard Helps
Safeguard's SBOM and provenance platform ingests mainframe inventories, ISV product data, and change management outputs alongside open source SBOMs and container image data. Teams running COBOL on z/OS alongside modern distributed systems get a single view of total software composition, advisory exposure, and provenance posture across both environments. Policy gates, dashboards, and reporting work uniformly regardless of where the code runs. Our API and export tooling integrate with Endevor, ChangeMan, and modern source control systems, so the mainframe supply chain story lives in the same platform as the rest of the software estate.