Just a couple of days ago, a friend and I discussed this very issue. We were wondering why did Go not have a dependency manager for such a long time? As it turns out, according to a conference explanation, at Google, the policy was to download a library, meticulously review it line by line, and then copy it into their repository. This policy made them believe there was no need for a dependency manager in their toolchain. After some consideration, we concluded that there isn't an absolute workflow that can guarantee complete security. There will always be a certain point where you have to assume someone is trustworthy. However, when you start looking at it from this perspective, it can become a bit unsettling, like living in a world where you constantly question if you can trust someone. This feeling can lead to fatigue, resulting in reckless behaviour, such as overlooking security measures or missing essential steps. Thank you for sharing this insightful video!
Even with that policy I would want something to tell me where that code came from originally, at which version, what changes have been made locally, when and what changes have been made upstream, etc. Basically git submodules I guess, but the experience there is pretty rough to use raw and doesn't really deal with transitive dependencies the way you would want.
Just loved how you connected dots with spending time diving deep into various topics during your PhD and being good at your job now. Any recommendation for people who aren’t in academia, but want to build a strong foundation for the future while having a day job?
Supermicro story by Bloomberg was disputed - article mentioned that Apple ans AWS cut relations with Supermicro because of the "secret chip", but both Apple CEO and AWS CEO said that while they did cut relations, the "secret chip" story is 100% false.
Software bill of material, a crucial tool for software security. Represented in the sometimes secure serialization format 😅 Interesting talk, I can’t help but think SBOM should be the responsibility of some existing part of the SDLC but every time I think of a component the scope of the SBOM just gets wider. My question would have been “where do we stop, hardware?”. It’s a silly open ended question but great to extract an opinion out of someone who seems interested in the topic!
Hardware is a problem too unfortunately! See for example the Supermicro compromise scare from 2021. This is what I was getting at for "turtles all the way down". You have to stop at trust anchors, which means you have to figure out what/who your trust anchors are.
30:00 I'm thinking Nix as a solution to knowing your dependencies. Nixpkgs is nowhere close to an actual solution, since it just fetches a ton of sources/binaries and can build them (also need to validate nixpkgs source itself!). Just an interesting case study of reproducible builds, with metadata on build and runtime dependencies.
As a library or tool author what should an SBOM include for dependencies where all you require is a minimum version? Is the entry useful without a hash, or should I include a hash for every possible version?
Hey Miso, did you know that there has been an almost 800% annual increase in the number of supply chain attacks over the past 3 years? No?
"Well, now you know"
Just a couple of days ago, a friend and I discussed this very issue. We were wondering why did Go not have a dependency manager for such a long time? As it turns out, according to a conference explanation, at Google, the policy was to download a library, meticulously review it line by line, and then copy it into their repository. This policy made them believe there was no need for a dependency manager in their toolchain.
After some consideration, we concluded that there isn't an absolute workflow that can guarantee complete security. There will always be a certain point where you have to assume someone is trustworthy. However, when you start looking at it from this perspective, it can become a bit unsettling, like living in a world where you constantly question if you can trust someone. This feeling can lead to fatigue, resulting in reckless behaviour, such as overlooking security measures or missing essential steps.
Thank you for sharing this insightful video!
Even with that policy I would want something to tell me where that code came from originally, at which version, what changes have been made locally, when and what changes have been made upstream, etc. Basically git submodules I guess, but the experience there is pretty rough to use raw and doesn't really deal with transitive dependencies the way you would want.
Just loved how you connected dots with spending time diving deep into various topics during your PhD and being good at your job now.
Any recommendation for people who aren’t in academia, but want to build a strong foundation for the future while having a day job?
Read "Reflections on Trusting Trust" by Ken Thompson, if you want to learn about a classic supply chain attack.
Next up: how can we trust the computer hardware that we are using. That supply chain is really vulnerable (ref the super micro scare).
Supermicro story by Bloomberg was disputed - article mentioned that Apple ans AWS cut relations with Supermicro because of the "secret chip", but both Apple CEO and AWS CEO said that while they did cut relations, the "secret chip" story is 100% false.
Software bill of material, a crucial tool for software security. Represented in the sometimes secure serialization format 😅
Interesting talk, I can’t help but think SBOM should be the responsibility of some existing part of the SDLC but every time I think of a component the scope of the SBOM just gets wider.
My question would have been “where do we stop, hardware?”. It’s a silly open ended question but great to extract an opinion out of someone who seems interested in the topic!
Hardware is a problem too unfortunately! See for example the Supermicro compromise scare from 2021. This is what I was getting at for "turtles all the way down". You have to stop at trust anchors, which means you have to figure out what/who your trust anchors are.
Yep, and then there is firmware and microcode...
Great, thanks. Would love to hear more about security of the build process.
Recent events reminded me of this talk... how prescient
41:19 Dude called the libz hack nearly a year before they tried to pull it off
30:00 I'm thinking Nix as a solution to knowing your dependencies.
Nixpkgs is nowhere close to an actual solution, since it just fetches a ton of sources/binaries and can build them (also need to validate nixpkgs source itself!).
Just an interesting case study of reproducible builds, with metadata on build and runtime dependencies.
Devenv ❤
As a library or tool author what should an SBOM include for dependencies where all you require is a minimum version? Is the entry useful without a hash, or should I include a hash for every possible version?
neovim ftw😂
Maybe that way the guys that work with hardware will finally get good software for managing BOMS! 😆