At the @NTIAgov multistakeholder process on software component transparency. Expecting sparks here today. ntia.doc.gov/SoftwareTransp…
Auditing a single application with 100M Lines of Code: 300+ 3rd party components, from 150+ sources, 25% are individuals' names with little more detail.
This is a hard problem for tracking, it's a bigger issue for security and quality.
This is a hard problem for tracking, it's a bigger issue for security and quality.
Oracle: We shouldn't abandon transparency, we should address the challenges that exist so we can be better.
Siemens: SBOM assumptions we should challenge about manufacturers:
-Have all info needed to share SBOM
-Want to share this info to customers
-Understand some of the use cases
-Understand requirements/challenges to implementations
-Have all info needed to share SBOM
-Want to share this info to customers
-Understand some of the use cases
-Understand requirements/challenges to implementations
Siemens: SBOM has a 3D solution space:
-Depth - which components, how much recursion
-Breadth - level of detail per item, revisions/patch levels, whether it's exploitable
-Time - update frequency
-Depth - which components, how much recursion
-Breadth - level of detail per item, revisions/patch levels, whether it's exploitable
-Time - update frequency
Veracode: National Vulnerability Database (NVD) coverage is about 2/3 of all vulnerabilities, compared against their internal databases.
Veracode: Less than 5% of time, does inclusion of a vulnerable component make the application vulnerable. Others state "less than 10%".
PTC/@iamthecavalry: This is really about an ingredients list, not some of the secondary/tertiary uses of SBOM. Comparisons against NVD, for instance, is high noise:signal ratio.
PTC/@iamthecavalry: False beliefs exist that this can't be done, or can't be done at the version level. But some manufacturers already do, for license compliance.
PTC/@iamthecavalry: @US_FDA is kicking off an internal task force to evaluate SBOM in healthcare delivery. Other parts of US Government is also increasingly concerned about known, but unmitigated vulnerabilities, and looking at SBOM for a way forward.
NY Presbyterian Hospital: "Software remains our single biggest issue," beyond what can be done with IDS and other controls. We are requiring all of our vendors to provide SBOM - as are many other healthcare providers.
NY Presbyterian Hospital: Software vulnerabilities are such a critical issue that we want to know the 5% that ARE exploitable so we can address them.
NY Presbyterian Hospital: Hospitals didn't always care about fire safety. It took 2 apocryphal fires to get hospitals to care about fire safety. And it led to large amounts of government regulation - now there's a lot of effort put into compliance rather than direct fire safety.
NY Presbyterian Hospital: If you're selling to certain industries, like defense industrial base, you're already providing SBOM and going much farther.
NY Presbyterian Hospital: A lot of the reasons NOT to do this are overblown. The auto industry argued that putting seatbelts in cars would make people drive more recklessly. [Beau: Even if it does, and there's evidence that it might, seatbelts still measurably save lives!]
Oracle: Publishing ingredients and vulnerabilities, equps the bad guys.
Defense industry attendee: It's absurd to assume that attackers don't already know about these vulnerabilities.
Financial services attendee: I want defenders to have the same advantages as attackers.
Defense industry attendee: It's absurd to assume that attackers don't already know about these vulnerabilities.
Financial services attendee: I want defenders to have the same advantages as attackers.
PTC/@iamthecavalry: Software makers have been doing this for years, to decrease cost and time to remediate. It's not that it can't be done - it is - it's about how can the practice traverse a commercial transaction?
DHS: If some can already easily generate SBOM, and it's hard for others, what needs to be done to instrument the software development lifecycle so that this becomes easy?
McAfee: Open source software requires companies that use projects to list them. Revealing this shouldn't raise intellectual property concerns for anyone.
Luta: Microsoft introduced exploitability index years ago, in order to give patch prioritization. Organizations didn't use that, they went by overall criticality rating.
Lots of talk about exploitability vs. unexploitable software components.
IDEA: A field in SBOM where the manufacturer can tell customers what's exploitable and what's not exploitable. Seems that would solve most objections.
IDEA: A field in SBOM where the manufacturer can tell customers what's exploitable and what's not exploitable. Seems that would solve most objections.
Financial Service: When one of our teams can produce a SBOM, it indicates the team is highly efficient. It's a symptom of better practices.
Financial Services: SBOM can enable capability for immunity/herd effect when we know of system-wide vulnerability and exposure. Whether that function resides in Gov or industry.
Thread seems to have broken. Pick it up here.
So those other tweets aren't lost...
Errata Security: There are several hard problems for software makers to know which components are in their products, let alone to provide it in some kind of standardizable format.
PTC/@iamthecavalry: Emergent processes can address several of the hard problems in producing a SBOM. Those that are already producing SBOMs use those practices.
Luta: Food ingredients is an imperfect analogy that oversimplifies the complexity of the problem. It's analogous to knowing what cow our food came from.
Others: Don't we want to know the cow/farm that our food came from?
Others: Don't we want to know the cow/farm that our food came from?
Breaking for lunch. Will be back in about an hour.
Microsoft: All companies are stakeholders in our customers' success. The SBOM multistakeholder process is critical in that. Information about software composition empowers customers to identify potential risks, strategies, and better actions. Even beyond security concerns.
...and we're back. Now looking at the 3D framework Siemens put out there.
PTC/@iamthecavalry Of these dimensions, some may be industry-wide standards, some may be commercial differentiators. Also would be worth understanding which altitude CURRENT practices get us to.
PTC/@iamthecavalry: Some manufacturers update SBOM at build time (when software is compiled/pushed to devices), then release quarterly updates on exploitable vulnerabilities. Column 1, then column 3.
Rapid7: Can SBOM be published similar to release notes, when new software versions are made available?
Oracle: We should distinguish whether we're talking about on-premise software or cloud/services. For cloud, it should be possible to have an API that can be queried that will give SBOM on demand.
OWASP project lead: SBOM success is tied to its simplicity and usability.
Commenter: Hardware can also be vulnerable.
Audience: We're not going to start using the term HBOM.
Hm... How about Software, Hardware, and IT Bill of Materials? Acronym is left to the reader to discern.
Audience: We're not going to start using the term HBOM.
Hm... How about Software, Hardware, and IT Bill of Materials? Acronym is left to the reader to discern.
Sonatype: If the point of SBOM is to give buyers and others the ability to take action, it may make Cloud/SaaS SBOM irrelevant because operations are in nearly sole control of the Cloud/SaaS provider.
Commenter by phone: For *some* use cases, end consumer may not need to know that their head unit might be vulnerable. Manufacturers certainly need to know it's vulnerable, and decide how to act!
Financial Industry: Some use cases get very complex. For instance, who buys food and who eats food isn't always the same. One benefits more from ingredients list than others.
Another complex SBOM use case is healthcare, where a _hospital_ may buy devices, that _caregivers_ use, for the benefit of _patients_, reimbursed by _insurers_. Four different parties in the mix, some of whom can action SBOM, some can't.
Sonatype: Customers asking manufacturers to fix vulnerabilities that aren't even in their products takes resources, as does answering questions about whether a vulnerability in a software component is exploitable.
PTC/@iamthecavalry: Worth pointing out that some coding languages and development environments make it harder vs easier to generate SBOM.
Luta: Some vulnerabilities are not exploitable by default, but the component can be enabled. There's value in revealing this distinction when communicating to customers, yet doing so manually becomes overwhelming (for both sides) at scale.
NTIA: Financial services and automotive have expressed strong interest in SBOM. A roadshow with those stakeholder groups might be useful.
Link to @zmanion slides.
FDA: We are happy to work with anyone on what a SBOM might look like, what its pitfalls might be, etc. to help hospitals and others defend their systems. NH-ISAC is working on this, and @SGottliebFDA has tweeted about it. Let's be safer, sooner, together.
A clarification on an earlier tweet.
Luta: In doing SBOM pilots, evaluate the time and resources for all parties in the chain in order to sustain this work - not just a single proof of concept. This isn't just a report, it's an ongoing operational workflow.
PTC/@iamthecavalry: Agree with this approach. In financial services, where they've had a 6-year running "pilot", they have required/generated SBOM in order to have a cost *savings*. So yes, let's track all the costs/resources.
PTC/@iamthecavalry: The idea of a SBOM has been around a while. There are some common misconceptions and missteps. How can we capture those and address the problems that are hard, not just the ones that seem hard?
Cisco: Yes, and.... how do you flag the objections that are real, that are hard, and get past them?
Sonatype: We still see thousands of organizations downloading known-vulnerable versions of Apache Struts. The more incentives that can be aligned toward selecting less vulnerable alternatives, the fewer security issues will persist in systems.
Erratasec: Many security practices generate a high noise:signal ratio. What is the noise ratio in a SBOM, filtered through a vulnerability database?
Financial Services: What's missing is a threat model. We are all vulnerable to ebola, yet we are unlikely to be exposed to it in this room. That threat model is critical to acting appropriately, and the buyer/operator is in the best position.
Discussion: Large disconnect between batch (point-in-time) and continuous processes. Batching vulnerabilities may delay awareness by defenders, where adversaries known sooner.
Oracle: It will take time to normalize understanding and to mature operational capabilities among defenders, to use this information for advantage.
Erratasec: Greater levels of detail tends to provide much greater confidence in security models, or reveal insecurities that can be addressed sooner.
Erratasec: We've already decided in our community that greater transparency is better. Though there may be other issues that decrease value of transparency.
Cisco: Where there are examples that prove out the SBOM model, we should analyze those, as well as models that don't work well.
NY Presbyterian Hospital: Standing up security programs of any kind is messy. It gets efficient over time. Let's not delay getting started because it might be messy, let's work together to get to efficiency faster.
...and that's a wrap. For today. Next meetings:
-Week of 9/17 - Virtual
-November 6 - In person, in DC
-Mid-January - Virtual
-April 2 - In person, in DC
Track/follow this multistakeholder process and join one of the groups to contribute. ntia.doc.gov/SoftwareTransp…
-Week of 9/17 - Virtual
-November 6 - In person, in DC
-Mid-January - Virtual
-April 2 - In person, in DC
Track/follow this multistakeholder process and join one of the groups to contribute. ntia.doc.gov/SoftwareTransp…
