[HN Gopher] Firmware Software Bill of Materials (SBoM) Proposal
___________________________________________________________________
Firmware Software Bill of Materials (SBoM) Proposal
Author : rwmj
Score : 88 points
Date : 2023-11-13 10:23 UTC (1 days ago)
(HTM) web link (uefi.org)
(TXT) w3m dump (uefi.org)
| narinxas wrote:
| oh the lengths they go through to avoid open source
|
| in this case the length is about "11-14 minutes" of text
| CharlesW wrote:
| Given that this describes a binary deliverable, what about this
| is anti-open source? Even their examples point to
| https://spdx.org/licenses/LGPL-2.0.html.
| bee_rider wrote:
| I don't think SBoM is solved by Open Source necessarily. It
| makes the problem easier maybe, but it doesn't really solve it.
|
| If you want to use Open Source code in an environment, it is
| necessary to validate all of the code (or know who validated
| it), including all the dependencies. The maintainers don't have
| any obligation to help you, and it is a tedious job that they
| might not be interested in (or maybe you are in the policing or
| defense sectors any the maintainers find your application
| objectionable).
| kube-system wrote:
| Because the topic has nothing to do with software licensing.
| The SBOM requirements being discussed apply to software of any
| license type.
| narinxas wrote:
| open source also applies to hardware designs
|
| but where does the software end and the hardware begin
| anyways?
| kube-system wrote:
| > open source also applies to hardware designs
|
| Okay? Neither hardware nor license type has any relevance
| to an SBOM. On an SBOM, you list all of your software
| dependencies, regardless of license.
|
| > but where does the software end and the hardware begin
| anyways?
|
| Hardware is the physically tangible part of the computer.
| Software is the instructions that run on it. For those
| compiling an SBOM, I think that's probably an easily
| answered question.
| narinxas wrote:
| so let me rephrase my original comment using more text
|
| I see them "bending over backwards" to protect their
| right to keep an advantage to use, if they deem it
| necessary, _against_ any one else.
|
| this is why they go to such lengths to avoid publishing
| what they consider to be "the secret sauce".
|
| as I see things, that they even came up with the notion
| of a "software bill of materials" is a bit disingenious
| from my perspective. already the concept is obscure and
| lends itself (in my opinion) to shading, hiding, and
| occulting the software source code and (or) the hardware
| designs (as appropiate)
|
| finally, I consider that the concept of "SBOM" (which TIL
| existed) is _designed_ with the intentions I already
| mentioned: to occult information (anti-open) for the sake
| of keeping a perceived advantage (pro-centralization)
| kube-system wrote:
| I'm honestly having trouble understanding your comment.
| SBOMs are just a list of dependences. Creating such a
| list is not a new concept, but it is one that is gaining
| traction recently. This is useful for people who use
| software, for example, if they learn that a particular
| dependency has a vulnerability in it, they can quickly
| determine if they are affected.
|
| I'll give you an example of what they're intended to be
| useful for:
|
| Let's say you're an organization and you use, say, 500
| different pieces of software made by 100 different
| companies. If you learn that there's a vulnerability in a
| particular dependency, what do you do? In the past, there
| was no standard way that vendors communicated this
| information, so the answer is that you would go through
| your list of 500 software programs, and email 100
| different vendors asking about each one. This is not a
| good process.
|
| If, instead, everyone provided an SBOM with their
| software, all you need to do is run a query against
| whatever inventory management system you're using and you
| have the answer in seconds.
| aftbit wrote:
| I don't quite understand SBoM. How does this help with something
| like the Solarwinds attack or a general CI compromise? Or is
| there another type of attack this helps mitigate or detect?
|
| Their example entry basically just says (very simplified) "Intel
| both built and supplied the microcode for your Intel CPU". But it
| says nothing like "Intel used Jenkins version x.y.z which bundled
| log4j version a.b.c" so you still can't tell if your binary blob
| was built by a compromised system or not, even once you learn
| about the potential attack.
| bee_rider wrote:
| If nothing else it tells you that Intel is responsible for
| whatever version of log4j they decided to include in their
| dependencies.
| onei wrote:
| It won't tell you about malware. It just means when my
| customers have questions about well publicised vulnerabilities
| in open source dependencies, they can audit themselves for the
| presence of that dependency with a set of standard tooling.
|
| That said, my company is moving towards having SBOMs, but seems
| to be making them available on request only. Which in my mind
| defeats the point of having them.
| lars_francke wrote:
| The things you mentioned are not solved by a typical "SBOM" but
| e.g. CycloneDX has extra fields to record provenance and
| pedigree and things like in-toto (https://in-toto.io/) or SLSA
| (https://slsa.dev/) also aim to work in this field.
|
| I've spent the last six months in this field and people will
| tell you that this or that is an industry best practice or "a
| standard" but in my experience none of that is true. Everyone
| is still trying to figure out how best to protect the software
| supply chain security and things are still very much in flux.
| deepsun wrote:
| I always thought SBoMs _can_ link to all the dependencies a
| build used, which user can later securely resolve to all the
| transitive binaries/dependencies like log4j version a.b.c.
| gepeto42 wrote:
| I really dislike when people say SBoM could help with the
| Solarwinds scenario, because it would not.
|
| Once the CI/CD environment is compromised, how would the SBoM
| be trustworthy anyway?
| blopker wrote:
| Maybe a bit off topic, but has anyone had success using LLMs to
| reverse engineer firmware assembly code? If they aren't going to
| release it open source, maybe that's the next best thing.
| stavros wrote:
| Why use LLMs when you have a disassembler?
| kikoreis wrote:
| I think "[automated] disassembly" has a different implication
| than reverse-engineering; the latter usually involves more
| depth in the analysis of the binary, usually including more
| semantic-level considerations (i.e. this block is meant to do
| this, or this function is used from these different
| callsites). The best examples of this type of analysis seem
| to exist in the security community when going into the detail
| of zero-days, exploits, etc. I think LLMs either already can
| or will soon enter that space.
| thewanderer1983 wrote:
| Spoken like someone who has never done reverse engineering of
| binaries.
|
| Here are some examples of people using Ghidra.
| https://github.com/evyatar9/GptHidra
| https://github.com/likvidera/GhidraChatGPT
| https://github.com/tenable/ghidra_tools/tree/main/g3po
|
| I suspect there are better ones being worked on though.
| cibyr wrote:
| Surely this would be a Firmware Bill of Materials (FBoM,
| pronounced "F-bomb")
| the_panopticon wrote:
| Yes, "Firmware Bill of Materials"
| https://uefi.org/sites/default/files/resources/Traceable%20F...
| has been used.
| deviantbit wrote:
| "For US companies, Executive Order 14028, "Improving the Nation's
| Cybersecurity" now makes providing a SBoM a legal obligation for
| many companies."
|
| Yea, this is not true. There is NO legal obligation. Be careful
| with what you read on the internet.
|
| Guidance and law are two very different things.
| mardef wrote:
| Until you are providing software to the US government, in which
| case it is their requirement.
|
| Or at least that was my experience while working on sovereign
| cloud stuff in big tech.
| sheepshear wrote:
| They're notifying companies that do regulated work to check if
| their compliance obligations have changed. It's not an address
| to the general public telling us that our gadgets will be
| different now.
| kube-system wrote:
| Obligations under regulatory law are correctly called "legal
| obligations". They might not apply to _you_ , but they may
| still exist for "many" others.
| genmud wrote:
| If you sell software to the government you do. Which happens to
| be the biggest purchaser of software and touches others by
| proxy. E.G. you might provide software to Boeing who sells to
| the government, therefore Boeing has a legal obligation and
| requires all its suppliers to provide SBoMs. Or Dell, or HPE,
| or Cisco or literally every software / service provider.
| c-linkage wrote:
| Back in the day, we used to embed strings into the translation
| units that would report the original name and version of the
| file. One could use the 'strings' command to get detailed
| information about what files were used in a binary and which
| version! DVCS (git) broke that, so most people don't remember.
|
| Knowing know which version of a file made it into a binary still
| doesn't really help you, though. The compiler used (if any), the
| version of the compiler and linker, and even the settings / flags
| used affect the output and -- in some cases -- could convert an
| otherwise secure program into something exploitable.
|
| A Software BoM sounds like a "first step" towards documenting a
| supply chain, but I'm not sure it's in the right direction.
|
| This feels like this might actually be a use-case for a
| blockchain or a Merkle Tree.
|
| Consider: A file exists in a git repository under a hash, which
| theoretically (excluding hash collisions) uniquely identifies a
| file. Embed the file hashes in the executable along with a
| repository URL and you essentially know which files were used to
| build a file. Sign the executable to ensure it's not tampered
| with, then upload the hash of the executable to a block chain.
|
| If your executable is a compiler, then when someone else builds
| an executable then they can embed the hash of the compiler into
| the executable to link the binary back to the specific compiler
| build that made the binary. The compiler could even include into
| the binary the flags used to modify the compiler behavior.
| dj_mc_merlin wrote:
| How do you identify if log4j was one of your dependencies then?
| You'd just have a hash of the pom.xml or whatever and you'd
| still need a tool to check it.
|
| edit: or do you mean that your hypothetical tool would generate
| the repository URLs + file hashes for its dependencies as well
| and bundle those with its own?
| c-linkage wrote:
| log4j is usually included as a binary component in a .jar
| file, so it should be obvious that it is a dependency. If
| you're using log4j with a remote logger, that's a
| configuration that probably wouldn't be captured by a hash.
| However, that fact that a specific version of log4j client
| library is included in your distribution should be easy to
| identify.
| jjnoakes wrote:
| > Back in the day, we used to embed strings into the
| translation units that would report the original name and
| version of the file.
|
| We still do this today. We rely on some tooling-added
| information and add our own custom information on top (git
| hash, hash of direct dependencies, compiler version and flags,
| etc).
| treyd wrote:
| > This feels like this might actually be a use-case for a
| blockchain or a Merkle Tree.
|
| Merkle trees sure but you _do not_ need a blockchain to store
| /manage hashes of sources and build products. Just have
| trustworthy parties attest that source commits yield particular
| binaries by their hashes and publish those signatures
| somewhere. Even Bitcoin Core does something like this using
| PGP.
| c-linkage wrote:
| The only reason for suggesting a block chain is that the
| information should be publicly available without having to
| visit a specific vendor's web site for confirmation.
|
| But maybe it's not necessary.
|
| DNS Root Zones, for example, are publicly accessible and well
| managed (maybe not the _registrars_ , but the _registry_ ) so
| perhaps a well-funded third party could establish a trusted,
| global, registry for supply chain Merkle Trees.
| evanjrowley wrote:
| >This feels like this might actually be a use-case for a
| blockchain or a Merkle Tree.
|
| A few years ago, a similar idea for firmware binary security[0]
| had been explored by Google as a possible application of their
| Trillian[1] distributed ledger, which is based on Merkle Trees.
|
| I don't know if they've advanced adoption of Trillian for
| firmware, however, the website lists Go packaging[2],
| Certificate Transparency[3], and SigStore[4] as current
| applications.
|
| have used Trillian as the basis for their Certificate
| Transparency implementation.[2]
|
| [0] https://github.com/google/trillian-
| examples/tree/master/bina...
|
| [1] https://transparency.dev/
|
| [2]
| https://go.googlesource.com/proposal/+/master/design/25530-s...
|
| [3] https://certificate.transparency.dev/
|
| [4] https://www.sigstore.dev/
| westurner wrote:
| Sigstore artifact signature verification may be part of a
| SLSA secure software supply chain workflow.
|
| slsa-framework/slsa-github-generator > Generate [signed]
| provenance metadata : https://github.com/slsa-framework/slsa-
| github-generator#gene... :
|
| > Supply chain Levels for Software Artifacts, or SLSA
| (salsa), _is a security framework, a check-list of standards
| and controls to prevent tampering, improve integrity, and
| secure packages and infrastructure in your projects,
| businesses or enterprises._
|
| > _SLSA defines an incrementally-adoptable set of levels
| which are defined in terms of increasing compliance and
| assurance. SLSA levels are like a common language to talk
| about how secure software, supply chains and their component
| parts really are._
| sega_sai wrote:
| Wouldn't that require also including the hash of every dynamic
| library in the system, the environment variables, configs etc,
| as all that can affect the resulting file ?
| Someone wrote:
| > The compiler could even include into the binary the flags
| used to modify the compiler behavior.
|
| There may be multiple sets of compiler flags and even multiple
| compilers (can there even be multiple linkers?)
|
| In addition, having to pick between multiple functions called
| _foo_ , a linker may pick either of them, and may not always
| pick the same one (parallel linkers often aren't
| deterministic), even if their implementations are different.
|
| There also is a decent chance you'll have to document your OS,
| for example if the compiler dynamically links to a system
| library, or if the OS has FPU support in software, or if the OS
| tweaks some obscure CPU flags (and of course, you'll have to
| document the specific CPU and CPU revision, as those can affect
| things like constant folding.
| throw555chip wrote:
| In the Java world, we rely heavily on Maven which uses the BOM
| concept.
___________________________________________________________________
(page generated 2023-11-14 23:00 UTC)