Adopting (or enhancing) a supply chain risk management program is a vital and key pillar for a strong information security program. Mature information security programs find great value in inspecting and gathering insights into their software and hardware supply chains. But how is this achieved? Qualified tooling and seasoned practitioners.

We live in an interconnected world, and there is a platitude that holds very true to how we operate as information security professionals and decision-makers:

No man is an island.

—Seventeenth-century English author John Donne

No one stands on their own and gets things done alone. No single person designs and executes an enterprise-ready product without contributions from others. While one, or one’s respective team, may believe they’ve single-handedly authored the world’s best product, it’s often dependent on valuable contributions made by others — those whom you usually have no affiliation with but place trust in their works. And these are called dependencies. We write software that includes dependencies. We run software that contains dependencies. Dependencies, dependencies, dependencies: it’s where we are, and we need a clear path to dealing with it.

So what’s included in the composition of SaaS, commercial off-the-shelf (COTS), or proprietary applications you use to get things done? Do you know? If you don’t know, you should find out. Fast. And if you think you know, you should keep looking deeper.

This post will highlight pertinent capabilities and the expected instrumental value you should look for when selecting tooling for analyzing software bills of material (herein, “SBOM”).

Start Here.
And Get Ready To Measure.

As an information security professional charged with uncovering cyber supply chain risks, you need a very accurate understanding of the risks within your organization. Yes, I said it correctly - your organization is running with risks, and you need to know what those risks are, how to measure potential impact, and how to reduce said respective risks. Cloud is no exception. A number of organizations have even pivoted to SaaS in efforts to scale, provide higher availability, flexibility in security, etc., and the amount of migration to the cloud has significantly increased since the pandemic started, as this survey and market research shows. No organization should assume that cloud is safer than on-premise. And no organization should assume that on-premise is safer than cloud. Each comes with its own level of responsibility, and you should be capable of evaluating those risks at every step. I’ve composed a quick list of what to look for when evaluating SBOM tooling:

Trust and Risk Scoring. You’ll find it necessary to have SBOM tooling that provides a clear way to score components based on your security requirements. Your organization may have stringent application security requirements, such as adherence to specific frameworks and/or standards. Or you may have a coupled, pressing need to know when there are any vulnerabilities in the applications your business runs on. You need the ability to measure how well your apps and all of their dependencies size up to your requirements. From there, scoring can help you determine what’s critical and how far a component has deviated from what you’ve defined as acceptable.

SBOM Ingestion. Your tool needs to be capable of receiving a Bill of Materials in an automated fashion. When SBOM ingestion is manual, there is room for human error. Vendors need to remember to upload. And you’ve got to track that. This practice is not the becoming of a well-disciplined information security program. Ensure your vendor can interface with you via API. You’ll thank me later.

SBOM Formats. SBOMs come in many formats, and your tool should be capable of receiving all industry-standard formats. If your tool is incapable, you leave room for being incapable of having insights on risks. Consider a tool that can be flexible enough to ingest all formats. In addition to receiving all formats, National Security Agency (NSA) guidance recommends that your SBOM tool should also be capable of exporting SBOMs using either CDX or SPDX format and converting SBOM files from one format to another (other formats may include, but are not limited to JSON, XML, CSV). Lastly, your SBOM tool should be capable of aggregating multiple SBOMs from the SBOM’s repository and placing them into a single SBOM.

Role-Based Access Controls. Each person/group with access to your SBOM tooling should only be able to see their specific project.This may seem obvious, but you expose your organization’s cross-view of pending vulnerabilities without it. There may be severe legal injury and consequences for undesired exposure.

Multi-dimensional Dependency Tree Reconnaissance. Leave no stone unturned. You may be very familiar with designing and composing software; if you aren’t, listen up. Each program we run usually calls in for help. Dependencies. import x; import y; import z. And the list goes on. And it all starts here. And for good reason. No programmer wants to reinvent the wheel. Reinventing the wheel requires maintenance, which means more work and less time to be productive. So we import what we need. We import and inherit the risks of respective dependencies. Our tool should be capable of analyzing each dependency as a distinct component. And each dependency of that dependency. And each dependency of the dependency’s dependency.

Represented as:

In the same manner, transitive components should be discovered, clearly pointed out, and tracked. When looking at origins, your tool should be capable of displaying NTIA-minimum SBOM fields.

Geographical awareness. Some organizations require omittance of software that originates in some geographical regions. And in some cases, even if the product or its dependencies derive from a “safe” origin, it may be written by authors who do not. You need to be able to track this.

Authorship discovery. Let’s face it. There are developers known for their cavalier activities. Our governments track them, and so should you. Some SBOM tools have a clever way of uncovering developers’ techniques and writing styles. This level of attribution intelligence could be key to your organization honing in on possible threat actors that have identified apps in use at your organization and have decided to target your supply chain as their way in.

Tracking Software Improvements Over Time. A successful cyber supply chain management program is well in tune with tracking and monitoring the security posture of the apps it uses for business. As an information security professional, you will want to know how well your vendors discover security vulnerabilities and the level of responsiveness to said vulnerability discoveries. You’ll want to know if your vendors introduce new releases that are immediately faulty. You will want to know if your vendors introduce faulty patching. A great visual for this would be a trend graph that shows whether vulnerabilities are increasing/decreasing at each release. Remember, your business runs on risks, and you must know where and how to address them best.

Clear Information For Decision Making. The instrumental value of SBOM tooling is uncovering risks in your software supply chain. It should be capable of clearly defining which components are vulnerable, associated CVEs (where applicable), and where there are any clear steps for mitigation. A very nice value-add that your tool should include is a direct tie-in to the National Vulnerability Database and other industry-respected sources of threat intelligence. This addition allows a practitioner to swiftly gain access to a steady stream of vulnerability analysis and up-to-date findings of threat intelligence. With this information, a program manager can make an informed decision: reject, mitigate, accept, or transfer said risk.

CICD Pipeline Interfacing. When building software, you want to know where risks are in your build. No one intentionally wants to introduce risks to their intended audience in everyday scenarios. An SBOM tool with API capability would make this much easier to check. Granted, this is not the end-all-be-all for software security.

Fingerprinting. In all circumstances, you should track and demand all vendors to sign their software artifacts. Code signing ensures your ability to verify the origin and authenticity of each component along the way. My colleague and fellow Aquian, Mario Lunato, has written a fantastic article on Signing Software Artifacts with Cosign. In this article, Mario does an excellent job covering the importance of software signing.

A Pool For Forbidden Vendors And Contributors. Most mature information security programs (and government agencies) have a pressing need to exclude components that originate from known malicious contributors, organization-identified contributors, nation-states, etc. Keeping up with this can become a tall task, so it’s best not to be done manually. Allow your tool to flag components within your pool of forbidden origin.

Orchestration. Good security is music to our ears. We want our findings to be actionable. We want our tooling to be capable of interfacing with our business workflows. Wouldn’t it be great if the findings from our SBOM tool could relay information to our SIEM? How about integration with our favorite ticket/issue-tracking tools? And integration with AI/ML for batched or real-time analysis. And a built-in functionality to directly connect and stream intelligence into our data lakes. Of course! Having SBOM tooling that could allow us to automate actions could mean the difference between timely mitigation and disaster.

Reporting. Every good information security program should demand accurate and measurable reporting. Your SBOM tool should provide flexible reporting based on your needs. Reporting lets you quickly gain insights on metrics and the full gambit of discovered risks.

Continuous Monitoring. This process consists of (but is not limited to) real-time visibility, automated scans and assessments, threat intelligence integration, alerting, orchestration, compliance checking, and amelioration of decision-making. In addition, tooling should allow for the swift identification of assets that are affected by emergent threats. Your SBOM tool should typically assist with automating those mentioned above to ensure gaps are not sustained.

User Interface. No one wants a tool where you can eventually find what you need. Let’s walk through a few must-haves first, then we’ll get through nice additions. With regard to must-have user interface capabilities, we want our tool to quickly and nicely layout digestible and meaningful information. As it relates to SBOMs, we want to clearly and easily be able to pick up information that speaks to software components, vulnerabilities, suppliers, users, and risks. And from here, an ability to drill-down and gather expanded details, respectively. An additional value-add, this will benefit both large and small organizations, capabilities to group by vulnerability severity, sort by vulnerability count, filter by source, etc.

In addition to the items that I’ve highlighted above, the NSA has released a report with Recommendations for Software Bill of Materials (SBOM) Management that offers additional guidance on “General recommendations for software consumers.” This specific section serves as handy guidance to help ensure your suppliers are designing, developing, and delivering secure software.

In conclusion, the adoption and enhancement of a supply chain risk management program, specifically through the analysis of SBOMs, is not just a proactive measure but a necessity in today’s digital and interconnected landscape. The intricate web of dependencies inherent in software and hardware supply chains requires a sophisticated and multifaceted approach. The capabilities of SBOM tooling, as detailed above, are fundamental to identifying, assessing, and mitigating risks within your cyber supply chain. From trust and risk scoring, SBOM ingestion, and format compatibility to continuous monitoring and integration with business workflows, each feature plays a pivotal role in fortifying your information security program.

Remember, the objective is not just to identify risks but to understand them, measure their potential impact, and deploy strategies to reduce or manage these risks effectively.

If your organization requires professional services for software supply chain security, Aquia Inc. has a team of seasoned and publicly-praised professionals ready to add value to your information security program.

Did you enjoy this article? Connect with me on LinkedIn and get high-quality information security content - no fluff.

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.