Software Bills of Material After EO 14028: What Financial Vendors Now Hand Their Buyers

Executive Order 14028 of May 12, 2021 set the federal government's software-security machinery in motion, and its procurement layer is why software bills of material became ordinary business documents: OMB memorandum M-22-18 (September 2022) requires producers selling software to federal agencies to attest to secure development and, for critical software, to provide an SBOM meeting the NTIA minimum elements of July 2021 — with M-23-16 extending the attestation approach across the government's software purchases. Vendors to financial institutions were never the direct addressee; they inherited the artifact because the same product teams now generate SBOMs for everyone.

3G Times publishes information, not legal advice; procurement and regulatory applicability questions belong with counsel and each institution's third-party risk program.

What an SBOM is, minimally

The NTIA minimum elements define a machine-readable inventory of a software product's components: the supplier of each component, its name, version, and any unique identifiers, its dependency relationships, the SBOM's author, and its generation timestamp. Two open formats carry nearly all of the weight — SPDX out of the Linux Foundation lineage and CycloneDX from OWASP — and both express the same floor. What the document does is make the supply chain enumerable: when the next log4j-scale disclosure lands, the question "are we exposed" becomes a lookup instead of a hunt.

Which sellers owe what to the government

The federal mechanics run through agency contracts. M-22-18 required attestation letters from software producers — the CEO-level signature attesting to secure-development practices — with SBOMs for critical software first; M-23-16 spread attestation collection across all software categories on a phased calendar, and a common-form attestation template published through CISA standardized the letter. Continuation-of-services dependencies and open-source producers had lighter paths. The practical endpoint by 2026: any vendor with a federal footprint has already built the SBOM pipeline, and the document exists whether or not a private buyer asks for it.

How financial institutions pulled the same artifact into their stack

Banks and fintechs did not need a new regulation to want the inventory. Third-party risk programs — driven by interagency guidance on vendor management and by operational-resilience frameworks in Europe — already demanded component transparency for anything touching the payment path; the SBOM simply standardized the response. Procurement templates now ask for a current SBOM per release, vulnerability-disclosure SLAs tied to it, and notification duties when a listed component is disclosed as vulnerable. The buyer-side economics are unromantic: the SBOM converts vendor-security questionnaires from narrative to lookup, and it gives incident-response teams a floor under the first hours of the next named vulnerability.

The disclosure-week arithmetic explains the urgency. When a critical vulnerability lands in a widely used library, an institution with correlated inventories answers exposure questions in minutes and spends the day patching; an institution without them spends the day asking vendors, and the answers arrive after the exploitation window that mattered. That asymmetry, repeated annually, is what turned a federal procurement formality into a private-sector standard.

What good buyer-side use looks like

Receiving an SBOM is not using one. Institutions that get value maintain a correlation step — SBOM entries matched against vulnerability feeds continuously, not at audit time — and they treat inventory drift as a contract event rather than a surprise. The second-order use is concentration risk: dependency graphs across vendors reveal that five suppliers share one unmaintained parser library, which is exactly the systemic fact the federal program was built to surface and exactly the one no questionnaire ever caught.

A note on custody of the artifact itself: SBOMs age the moment they are emailed. Buyers increasingly require a living channel — a vendor endpoint or release feed the institution's tooling polls — because the difference between a current inventory and last quarter's is the difference between an answer and a guess during the first hours of a disclosure event.

Where does the attestation regime still fall short?

The paperwork has known limits, and buyers price them. The attestation letter is self-certified — a signature stands behind development practices no auditor verified, and the common form contemplates reliance rather than inspection. SBOM completeness is only as honest as its generator: a hand-edited inventory can omit the component nobody wants to discuss, and the minimum elements do not require the build process that produced the document to be reproducible. Depth varies too — a flat list satisfies the floor while hiding the transitive chains where the real incidents have lived. None of this is fatal, because procurement is the correction mechanism: buyers who care add contractual teeth — reproducible SBOM generation from the build pipeline rather than a spreadsheet, the right to sample-audit against the artifact, liability tied to material omission, and severity-tiered notification clocks. The institutions that treat the federal floor as a starting negotiation position rather than the requirement itself are the ones whose correlation dashboards mean something during the next disclosure week.

What does this mean in practice?

• Make the SBOM a contract deliverable, not a courtesy. Per release, machine-readable, in a stated format, with a change-notification trigger when the dependency set moves.
• Correlate continuously. A stored SBOM that nobody queries is compliance theater; the value is the lookup speed during disclosure events.
• Read the attestation's scope before relying on it. The federal letter attests practices, not absence of vulnerabilities — buyers should pair it with their own verification.
• Ask for the dependency depth. Transitive dependencies are where log4j hid; minimum elements permit both flat and nested graphs, and nested is the one that answers the question being asked.

EO 14028's software-security layer is often summarized as a federal paperwork exercise. Its durable effect is narrower and larger: it standardized the inventory of what software is made of, and every serious buyer downstream of the government — which in financial services means everyone — now writes the standard into contracts.

Who inside the institution should own the SBOM file?

Third-party risk is the natural custodian, with information security consuming the feeds; the mistake is leaving it with procurement alone, which receives the documents but correlates nothing. The artifact is most valuable to the incident-response team, and the contract should name them as a distribution point.

Frequently asked questions

Are financial vendors legally required to give banks SBOMs?

Not by EO 14028 itself, which binds federal procurement. The requirement arrives contractually: institutions' third-party risk programs demand the artifact, and vendors with federal customers already produce it. Regulatory expectations for managing technology vendors supply the pressure behind the demand.

SPDX or CycloneDX — does the choice matter?

Both satisfy the NTIA minimum elements; what matters is consistency and depth. Pick one format per contract, require nested dependency graphs, and let tooling, not negotiation, pick the winner.

What about SaaS with no shipped binary?

The minimum-elements framing assumed delivered software, but the inventory logic translates: buyers increasingly ask SaaS providers for the SBOM of the deployed stack and for the vulnerability-handling SLAs around it, and the federal attestation approach is extending to cloud offerings through agency contract clauses.