7 ms·
Firmware Software Bill of Materials (SBoM) Proposal
- narinxas 3y agooh the lengths they go through to avoid open source in this case the length is about "11–14 minutes" of text
- deleted 3y ago[deleted]
- CharlesW 3y agoGiven 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 https://spdx.org/licenses/LGPL-2.0.html.
- bee_rider 3y agoI 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 3y agoBecause the topic has nothing to do with software licensing. The SBOM requirements being discussed apply to software of any license type.
- narinxas 3y agoopen source also applies to hardware designs but where does the software end and the hardware begin anyways?
- kube-system 3y ago> 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 3y agoso 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 3y agoI'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 3y agoI 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 3y agoIf nothing else it tells you that Intel is responsible for whatever version of log4j they decided to include in their dependencies.
- onei 3y agoIt 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 3y agoThe 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/ https://in-toto.io/) or SLSA (https://slsa.dev/ 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 3y agoI 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.
- blopker 3y agoMaybe 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 3y agoWhy use LLMs when you have a disassembler?
- kikoreis 3y agoI 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 3y agoSpoken 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/evyatar9/GptHidra https://github.com/likvidera/GhidraChatGPT https://github.com/likvidera/GhidraChatGPT https://github.com/tenable/ghidra_tools/tree/main/g3po https://github.com/tenable/ghidra_tools/tree/main/g3po I suspect there are better ones being worked on though.
- blopker 3y agoThanks for this. I've been using Binary Ninja, but may have to try out Ghidra. I was surprised how little I found online about it, none of the major vendors seem to have first class support yet.
- crotchfire 3y agoI am extremely interested in this. The utter silence in the literature around this is a bit odd, frankly. Not LLMs specifically, but transformers more generally, ought to be extremely good at this task. Another one I wonder about a lot is execution traces. Something that isn't mentioned often enough is that transformer models can do previous-token completion just as easily as next-token completion. So you can train the model on paired program/exectrace (training data is trivial to generate here -- just execute it on a CPU!) and then ask the model to work backwards from a desired machine-state you want to reach.
- cibyr 3y agoSurely this would be a Firmware Bill of Materials (FBoM, pronounced "F-bomb")
- the_panopticon 3y agoYes, "Firmware Bill of Materials" https://uefi.org/sites/default/files/resources/Traceable%20Firmware%20Bill%20of%20Materials%20-%2020211207%20-%20007.pdf https://uefi.org/sites/default/files/resources/Traceable%20F... has been used.
- deleted 3y ago[deleted]
- deviantbit 3y ago"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 3y agoUntil 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 3y agoThey'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 3y agoObligations under regulatory law are correctly called "legal obligations". They might not apply to you, but they may still exist for "many" others.
- deviantbit 3y agoAgain. Not true.
- kube-system 3y agoYes, it is true. https://en.wikipedia.org/wiki/Regulatory_law https://en.wikipedia.org/wiki/Regulatory_law And EO 14028 does it: https://www.gsa.gov/technology/it-contract-vehicles-and-purchasing-programs/information-technology-category/it-security/executive-order-14028 https://www.gsa.gov/technology/it-contract-vehicles-and-purc...
- genmud 3y agoIf 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 3y agoBack 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.
- 616c 3y agoRe Merkle trees, that is what emerging IETF specific citations in the SCITT working group are about. https://scitt.io/ https://scitt.io/
- dj_mc_merlin 3y agoHow 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 3y agolog4j 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.
- throw555chip 3y agoIn the Java world, we rely heavily on Maven which uses the BOM concept.
- deleted 3y ago[deleted]
- xvilka 3y agoIt's important to support not only PE format, that's only used by UEFI, but also ELF and some others.
- b20000 3y agoand how are small solo founder companies making devices going to carry and pay for this burden? i’m pretty annoyed that stuff like these requirements just makes it into law without getting small companies or startups to have a say in whether they want this or not.
- oneepic 3y agoYeah, even if it doesn't become a legal requirement, I could imagine companies asking for FSBoM's from their suppliers -- so it ends up being a requirement anyway if you want to compete with big co's.
- b20000 3y agowhich is why we don’t want this as it will make it harder to compete
- Ekaros 3y agoIf it really goes through. It is just adding extra standard step or tool to CI/CD chain. Problem now is that there is not good enough tools, but it is not unsolvable problem when enough people get involved.
- yjftsjthsd-h 3y agoAs opposed to what, getting a free pass to ignore security because you're small? (And really, it's a "burden" to track what you're shipping? That's all a BoM is; a standardized format to stamp a binary with a list of ingredients.) Do you think mom 'n pop diners should be exempt from health inspectors?
- hedora 3y agoIf it isn’t machine checkable, it is a complete waste of time. There are plenty of examples of people at the actual vendor behaving maliciously; often under government orders. However, there’s a pretty simple way to make sure the bill of materials can be checked by machine: Require the firmware blob to be reproducibly buildable from source, and mandate distribution of the source code of the firmware. Doing this doesn’t preclude signing the result of the build and then distributing the signature instead of the signing key. I’d personally prefer it if vendors also had to distribute signing keys, but that’s a separate question.
- rollcat 3y ago> I’d personally prefer it if vendors also had to distribute signing keys, but that’s a separate question. This would completely and entirely defeat the purpose of signing. Once a private (signing) key is no longer private, it's useless.
- hedora 3y agoExactly! I think that'd be great. You can disagree, and it is unlikely that you'll change my mind. A nice compromise is what my old Acer laptop does. You can disable the windows public key, and put your own in place if you want to run a CA, or you can just tell it to trust whatever boot loader is currently installed (and lock it to that boot loader, so now it won't boot Windows or even Ubuntu, but it will boot the Linux or BSD you installed). You can also disable the security checks if you want to.
- rollcat 3y ago> You can disagree, and it is unlikely that you'll change my mind. I'm not looking to change your mind, merely pointing out how absolutely pointless is signing if private keys are public. At that point just don't sign, and don't add the silicon/firmware that verifies the signatures - less cost designing/testing/manufacturing/supporting the hardware. The point of signing the firmware/bootloader is to make it more difficult to employ boot chain exploits. If you don't care that anything that even briefly gains root on your machine (curl|sudo bash) can proceed to permanently backdoor your OS in a way that's undetectable from the inside, just disable signing. /shrug > A nice compromise is what my old Acer laptop does. You can disable the windows public key, and put your own in place if you want to run a CA, or you can just tell it to trust whatever boot loader is currently installed [...]. Either Microsoft, or the EFI standards body (under MS's direction; can't remember the details here) mandates that users must be able to enroll their own signing keys, at least on x86. I haven't run into PC hardware that doesn't allow you to do this, but then I'm not dealing with a lot of PC hardware regularly. The story is a bit different with Arm EFI - Microsoft tried to ape Apple and make it mandatory to NOT be able to enroll new first-party keys; meanwhile Apple skipped EFI on Arm Macs, and just allowed third-party OS's like they did on Intel. I'm not sure what's the story with signing a third-party OS on the Arm Macs, but I wouldn't like to run one unsigned.
- infogulch 3y agoCan we just do it like oxide does it and make all code that executes to make an appliance function -- including firmware -- all open source? This should be the minimum bar to even start the sbom conversation.
- yjftsjthsd-h 3y agoYou'd still want a way to trace exactly what versions of what components went into the binary that actually got flashed to your device. I 100% support FOSS firmware, just I think it's orthogonal to this.