SBOM-A-RAMA!

CISA held SBOM-A-RAMA 2023 on June 14, a fast-paced collection of updates and reviews of the activities surrounding the guidance and policies being written around Software Bill of Materials (SBOM) or maybe what will be called Full or Cross Stack BOM (XBOM) or Technology BOM (TBOM). IT Procurement and Technology Asset Management (ITAM) come in all shapes and sizes, which is why I was surprised so few people in these roles attended this massively informative event. Also, I was surprised the entire audience wasn’t larger, but not so shocked that the primary audience were security related professionals. It would seem the concept of Bill of Materials started with a need for procurement knowledge because you can’t make the product without the materials! But along the way IT Procurement professionals got left in the dark and have no idea what comprises the technology they buy, and often they don’t have the knowledge to even ask the right questions. One of my former leaders had a very not vegan friendly way of saying he didn’t need to “know what’s in the sausage”. During the last decade of abundant tech jobs, IT Procurement and ITAM weren’t promoted as technical positions as much as administrative and this meant in some places having technical knowledge wasn’t as important as getting data entered, purchase orders issued, budgets planned, and reports run. But in this world where companies of all sizes can be in the line of fire in cyber warfare IT Procurement and ITAM have a critical role in securing the Software Supply Chain. It’s time to step up to defend your role and company if you’re an IT Procurement or ITAM professional now, or if you’re looking for a role in securing technology, maybe these are the roles for you.

Speaking the same SBOM language.

Speaking the same language in technology can be challenging even when we’re speaking the same written and verbal languages. IT Procurement and ITAM already know this heartache in trying to speak the technical lingo of the IT Administrators, Developers or Engineers then translating to their stakeholders in Finance, Accounting and Leadership and let’s not forget also understanding the Legal terms involved with our without a Legal department. But they may not know CISA’s speak around SBOM. The National Telecommunications and Information Administration (NTIA) document Roles and Benefits for SBOM Across the Supply Chain describes the three perspectives in the process as; Produce, Choose or Operate. Most IT Procurement and ITAM professionals are going to be in the Choose role but may support the Operate roles or work in a company that is also a Producer. I’ve had the joy of mostly working for software development companies, tangling me up in all the roles.

Being the Chooser is being the Gatekeeper.

Ensuring all the proper information is gathered during the purchase of any given technology product should land in the realm of IT Procurement and/or ITAM depending on where these functions sit in your organization. If you’re a one person IT department, or a Buyer that specifically handles a department of 500 hundred in a multi-national organization, if your role is responsible or even just part of the technology lifecycle obtaining an SBOM during the process of selection makes you the gatekeeper. As the hub of technology related information throughout the buying or obtaining (since this is all applicable to freeware or deciding to develop your own software as well) process you’re typically collecting the materials provided including requirements, proposals, communications, legal terms, quotes, maintenance agreements, SLAs and so much more. It makes sense that you need to be asking for a Software Bill of Materials, but what are you asking for?

Knowing what to ask.

Determining what to ask for will depend on your use case for what you are choosing. NIST recommended the initial implementation phase focus on “on-premises” software, and I’ll start there. Further let’s just focus on the on-premises software and not the entire stack, but keep in mind that for every software platform you have a hardware stack, firmware, operating system, potential networking, drivers, and other software requirements, so this requirement bleeds into each piece of the pie. You have your need for a new software platform and you’re putting out an RFI or RFP (if you’re that fancy maybe you’re just emailing resellers or direct software makers), do you just include SBOM as a deliverable and hope for the best? From my experience so far, this just got me delivered some raised eyebrows and nothing tangible.

• Be clear about the format you want, which will be based on how you intend to ingest the SBOM for your needs and we’ll dive into this more below.
• What standard should the SBOM follow; SPDX and CycloneDX are both supported by the CISA/NTIA guidance.
• Provide your own minimum elements. What the Department of Commerce and NTIA list may not be enough for your needs.

• Include requirements for delivery, make sure you have an easy mechanism for obtaining the SBOM with each release of the software you receive. Not all producers will be providing SBOMs on their websites, though CISA is requesting inclusion in support documentation this may prove difficult or push more documentation behind logins.
• Define repercussions for lack of delivery but avoid punishment for error. Mistakes will happen as producers are getting their footing with SBOM practices. Developers are still learning techniques for implementing SBOM and in unregulated, non-government industries a lot of these concepts are still new.

Knowing your limits.

Keep in mind throughout this process that there is no LAW requiring SBOMs for the purchase of software. We’re not at a point where you’ll get an ingredient style SBOM label on your next CandyCrush download, but never say never. Right now even the government isn’t going to waste time trying to collect BOMs from the open source or freeware world as stated in the June 9th 2023, Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices states:

“Agencies are not required to collect attestations from software producers for products that are proprietary but freely obtained and publicly available. Open-source software freely and directly obtained by Federal agencies is outside the scope of NIST’s guidance for agencies on software supply chain security.7 This memorandum further clarifies that no-cost, publicly available proprietary software is also out of scope for M-22-18 attestation collection.”

And the requirements are just coming into play for FDA regulated medical device software around October for software developed after Sept. 14, 2022, as the first agency. If you’re an IT Procurement or ITAM working in Medical, Energy or Automotive, this is very likely old news to you as these are the industries involved in the POCs which are forming the CISA guidance. Outside these industries, without regulations you’ll need to use other techniques to get the Producers to work with you on delivering SBOMS.

Ingesting and Actioning on SBOMs.

To know what formats and minimum fields to request from producers, IT Procurement and ITAM must have a way to read the SBOM, review the data for key information, process the information to the correct stakeholders, relate the SBOM to the rest of the technology stack, store the SBOM and update the SBOM along the software lifecycle. What tools do you already have that might read SBOMs?

ITAM Tools don’t often have built in importing for SBOMs but some of the larger offerings are starting to roll out integrations like Flexera One with Revenera SBOM Insights and Service Now with Snyk. If your company doesn’t have an ITAM tool suite today, there is a huge gap in your organization, but depending on your size and overall goals with the SBOM it may not be the best or only place for your SBOM management.

Hopefully you’re not also wearing the Cyber Security hat at your company, because “That’s too Much!”. But your Cyber Security team may have tools to read and store SBOMs already. Vulnerability management has grown since the inception of the CVE list in 1999 and many tools are great at exposing third party known packages and connecting them with the published CVEs. These tools are focused on either the Cyber Security teams mitigating threats such as (Tenable, Qualsys, Tanium, etc.) or developers looking to avoid building products with known vulnerabilities (Veracode, CheckMarx CXOne, Mend FKA WhiteSource, Snyk). If you develop software in-house, or host customer solutions you may or may not have needed any of the above tools. These will often read an SBOM and connect known vulnerability data, but you will probably have to figure out any licensing implications on your own.

If your company is developing software, chances are you have some form of Legal assistance or department, sometimes large organizations even have an Open Source Policy Office, or Technology acquisition committee. Companies with teams focused on the legal aspects of third party technology use might have tools such as (Revenera Code Insight, Synopsys Black Duck or Soos)

But if you’re in a small operation and you have no budget that doesn’t mean you’re not able to read SBOMs. There are a number of open source, free use tools out there, like OWASP Dependency Track, but they will take time to learn and implement. Using an open source or home-grown process also runs the standard risks of becoming stale, unsupported or requiring more resources to support than purchasing from a third party. There are also a growing number of consultant groups that specialize in assistance with managing SBOM data and auditing. Even if you have no tooling at all, you can still ask for a good old spreadsheet with human readable data, though I don’t recommend this for your sanity.

In all these cases, the tool will dictate the format, standard and data fields accepted and tracked. If you’re ingesting SBOM for multiple purposes and different tools are used this can also mean incompatibility. If you’re ITAM tool is only reading SPDX and your Cyber Security tooling reads CycloneDX you may have to perform your own conversion process and when requesting SBOMs decide which is preferred to start with.

Sharing the SBOM love.

Acting on SBOM data needs to be timely. If you’re in an RFP process trying to determine the software or negotiate a purchase license and vulnerability data can be critical. Making sure the SBOM data is accessible to the Legal and Security teams can avoid a regretful purchase but who else in your organization might need access to the SBOM data? Who is managing the lifecycle of the software? Who is supporting the rest of the stack? Does your company utilize business and risk analysis teams? It’s hard to say how far SBOM data goes in any given organization so explore all the areas of your business that software will potentially impact. Often ITAM and IT Procurement has the ability to see all aspects of the business since every employee ends up a customer in some form. This is why getting SBOM data upfront in the IT Procurement process is so critical, and if you can’t at purchase, then before an ITAM onboards software or any technology asset into their environment.

Negotiating for SBOMs.

Technology negotiations are already filled with variables, and this is just another lever to pull along the way. Every organization will have to make the choice of how strict to be when asking for SBOMs and when in the process. Because many producers still see SBOMs incorrectly as a threat to their Intellectual Property, there is a lot of push back on providing them. Getting SBOMs before a purchase may be challenging since often NDA or more extensive Legal paperwork has to exist between parties before SBOMs are delivered. If you’re a regulated industry or government entity getting SBOMs will be easier than in the more commercially free businesses. When there are no hard requirements, you may need to accept the promise of Deployment SBOM when the software is installed. Use this as a point for producers to compete and like anything in the market, the process will improve to satisfy choosers. Don’t forget that you need the continual delivery of updates and a mechanism for ending your agreement if they are unable to comply.

All along the lifecycle.

Once you have the SBOM, storage and updating will likely move more to the ITAM side of the role and keeping in sync with all the other teams in the chain will be part of the lifecycle. Ensuring updates are received and provided to all the right teams in a timely fashion will be part of the ongoing ITAM work unless automated through tooling. The CISA documentation explains Low, Medium and High levels of sophistication in the SBOM sharing process. Most organizations are in the Low Sophistication level when it comes to Discovery, meaning that SBOM sharing is still a customer-initiated process. As more and more requests for SBOMs come from IT Procurement and ITAM, more producers will move into medium and high sophistication allowing for the process of obtaining the SBOM to become a simple search rather than contractual negotiation effort.

Knowledge is power.

Now that you know how critical the IT Procurement and ITAM role is in the Software Supply Chain you can’t unlearn it! You should incorporate the collection, review, and dissemination of SBOMs into your technology acquisition and software lifecycle processes. Write into your technology purchase policy the requirement for Software Bill of Materials (SBOM) with any software purchase or SaaS subscription. I only touched on how on-premises software in this article, but the concepts translate with additional complicating factors as we span other technologies. Depending on the hardware and IoT purchase process, firmware will require SBOM, along with management software and hosted platforms used to support or service the hardware. Wearable technology holds many threats when we don’t know the software stack under the hood, it’s time to pop it open! With the rise of AI, advanced minds in this field should consider potential needs for data bill of materials (DBOM) and third party attribution when obtaining stock media, such as photos and videos or NFTs. I have so much more about AI, SBOM and ITAM to share in upcoming articles so keep watching!

Share your thoughts on IT Procurement and ITAMs role in the Software Supply Chain so I know what you think! Don’t forget to check out my YouTube Channel to follow my adventure finding out, “Can I AI My Life?”.