Don't Drop the 'S'BOMs

Since around the same time as EO14028, which drove Zero Trust adoption architectures, there has been another silent requirement that is becoming more required and prevalent, Software Bills of Materials or ("SBOMs"). Although DHS CISA has been capturing agency "CPE", common platform enumerations for quite some time as a part of CDM, new guidance specific to SBOMS have shifted to be more specific and granular in nature. They are no longer "nice to have" and today in 2026 the expectations have hardened into strict, enforceable, machine readable standards. If you are still managing SBOMS as a checklist item or on a static worksheet somewhere, your organization may be at risk of falling behind or disqualification, or missing out on opportunities to continue to strengthen your security program. Lets talk about the new requirements specified by OMB-26-05, Adopting a Risk-based Approach to Software and Hardware Security, and why its a game changer in world of SBOMs and steps you can take to comply, but also innovative ways to benefit.

The latest Memo refers ultimately to guidelines set out by DHS CISA in August 2025's Minimum Elements for a Software Bill of Materials and rescinded what used to be "check-the-box" attestation forms that seemed to put paperwork over actual security implementation and measures. These new requirements are intense, as vendors should now expect agency specific attestation based on risks, contract values, and data classifications and sensitivity. Some vendors should expect to map security evidence to each agency’s risk model as well, maintain on-demand SBOMs, current vulnerability disclosure policies, and evidence of secure development policies and practices. Vendors should also plan for multiple attestation workflows rather than the old "one size fits all" model. In addition to the Federal Memo, automated SBOM management requirements are making their way into the global sector.  In the EU, the Cyber Resilience Act (CRA) legally requires SBOMs for digital products, and the NIS2 Directive mandates strict supply chain security controls. In the private sector, standards like PCI DSS 4.0 require software component inventories, pushing enterprises to demand SBOMs to satisfy cyber insurance, customer audits, and zero-trust architecture requirements.

The new demands are heavy, as organizational liability now falls to agency heads. To prove your supply chain software is secure, your SBOM is needed to SBOMS need to meet the following requirements:

• Be in a standardized format like CycloneDX or SPDX. CycloneDX is from the OSWAP security community and focused on cybersecurity and vulnerability management, where SPDX is a Linux foundation origin and is for license compliance and IP tracking.

• Deep Component Visibility - SBOMS need to go beyond just the basics and include provenance and other details of its "digital birth", as well as integrity meta-data, hashes, and other license information fields.

• Automated generation and continuous monitoring is expected along with with real-time updates tied to vulnerabilities via VEX (Vulnerability Exploitability eXchange).

The image below shows NIST's "Illustrative Example of Software Life Cycle and Bill of Materials Assembly Line"

In order to not drop the SBOM, NIST provides guidance on how to integrate into your software development lifecycle throughout the process. What you're developing with and building on needs to be includes, as well as documentation for the release, packing and installation. Adding SBOM automation processes into your environment can be done, but requires some steps. As with most things, it starts with inventory. Zero Trust starts with inventory of identities and strong device parity and direct user-mappings to data that is appropriately classified and labeled with the appropriate policies. Inventories of Users, Devices, Applications, and Data, whether structured or unstructured. SBOM generation also requires inventory. All  all software products, services, hardware, and internal apps, mapping each to its repository, build pipeline, and deployment targets must be inventoried and enumerated. SBOMs steps should also be built into your CI pipeline and no code or artifact should be released without SBOM information as required. SBOMS also need to be included in the run-time as well. Periodically scan containers and workloads in production to maintain continuous deployment manifests.

The following is a mapping of an example SBOM of a sample Azure architecture. I essentially asked Google Gemini for an image of what a compliant JSON mapping look like in an Azure Subscription, Resource Group, two vnets with Azure functions in one and a direct flow to a SQL Server

Once the SBOM is produced, there needs to be continuous monitoring of drift. Compare your run-times to build times and notify cybersecurity and respective teams of any variances. This is important to ensure real-time accurate BOM documentation. Some organizations are even alerting in this instance, and creating incidents in SIEMS to notify and remediate. And last, all SBOMS needs to be saved in a centralized, versioned repository known as an SBOM Registry. The registry acts as a system of record and history but also contains critical metadata such as product details, versions, environments, build IDs, and git commit hashes. When starting out, the infrastructure can be as simple as an "S3 bucket + index DB," provided it acts as a unified internal service. The contents also need to be secured in a Zero Trust fashion. SBOMS contain confidential items such as infrastructure details and workflows that only few should be able to pull and access, along with strict logging controls.

Ultimately, "not dropping the SBOM" is about more than just checking a regulatory box for OMB-26-05; it’s about institutionalizing transparency in an age of digital fragility. By moving away from static spreadsheets and adopting machine-readable standards. organizations can transform their security posture from reactive to proactive. SBOMs provide a verifiable map of your Azure runtime environment, trust boundaries, and AI lineage. In 2026, the vendors who win will be those who treat security evidence not as a burden, but as a core feature of their product, proving to agency heads and stakeholders alike that their software is built on a foundation of Zero Trust and radical accountability.