6 ms·

Open source supply chain security at Google [video]

126 points by mfrw 3y ago

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
robszumski 3y ago
I attended/presented at this event and loved this keynote. I want to push back on the idea that there is no consensus on what an SBOM is — there are two very popular specs! Yes, quality, content and completeness does vary. And every SBOM does need to be enriched with vulnerability and runtime context. But those don’t need to be in the file itself (and aren’t static anyways).
- pipingdog 3y ago
  The lack of consensus is on what an SBOM is for. Even the NIST recommendation which came out of Executive Order 14028 had little guidance on how to apply SBOM . At any sort of scale, it isn't clear how an SBOM shipped with each package can be consumed to any great effect. A central database of all dependencies, on which queries and analysis can be performed, however, can be very useful, and in a large software shop, I've seen it used to rapidly get a very real sense of the company's exposure to events like the Log4j debacle.
  - candiddevmike 3y ago
    Additionally, from what I can tell a lot of SBOM tooling is manual/honor based, and the automated ones don't recurse dependencies well. Trusting the current state of SBOMs seems sketchy
  - eichin 3y ago
    A Debian/Ubuntu status file is a good start (of course you need to dig further for build depends) and helpful enough for "provenance" that I've found it useful at a couple of startups to deploy code as debs packages specifically to be part of that graph - obviously not perfect, but often good enough to go automatically from CVE -> USM -> upstream package -> what part of our code cares about that - someone still has to think about the vulnerability, but it reduces a lot of obvious noise and helps drill down quicker.
  - Veserv 3y ago
    A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. The sort of engineering 101 processes that almost all software development lacks. It is about making it possible, though not necessarily easy, for somebody to know what they are making. The next step is exhaustiveness and automated production. At this point it will be accurate and exhaustive, but not necessarily easy to use. This is about making it possible, though not necessarily easy, for the consumer to know what they are getting. The next step is then regularity and consistency to make it easy for the consumer to know what they are getting since it follows common, standard rules. After that point we may get to a full reproducible build/linking manifest that allows automated validation that the SBOM matches the delivery. But this step has a good chance of fizzling out as a standard practice in general industry. The first three are clearly where this is all going and constitute a very minor cost relative to a very outsized benefit. We might not even get to the third step, but even then at least general software development would have reached engineering 101 process sophistication which is a massive improvement over the status quo.
    - ploxiln 3y ago
      > A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. > The next step is exhaustiveness and automated production. There are lots of vendors selling automated SBOM generation tools/services, my company's security team is using it. Is the output correct? I don't know, they don't know, nobody looks at it. But we have SBOMs [checkmark]
      - Veserv 3y ago
        Yep, that is the point of the first phase. The next phase is going to be attaching liability for incomplete SBOMs. The way it will likely play out is that if you were breached due to a undisclosed component in a purchased product the product will either be deemed defective or the vendor will be liable. If CISA succeeds at pushing that you will see the SBOMs becoming correct and exhaustive real fast, though likely excessive due to ass-covering. But at this point the goal is clearly just establishing a paper trail so that it can eventually be audited for consequences. Maybe they will fail at the next step due to industry pushback against actual consequences for shoddy work, but that is clearly where it is trying to go.
  - beams_of_light 3y ago
    https://security.googleblog.com/2022/06/sbom-in-action-finding-vulnerabilities.html?m=1 https://security.googleblog.com/2022/06/sbom-in-action-findi...
- chatmasta 3y ago
  For anyone else who has thusfar avoided hearing the acronym "SBOM": > A “software bill of materials” (SBOM)... is a nested inventory, a list of ingredients that make up software components. https://www.cisa.gov/sbom https://www.cisa.gov/sbom
not2b 3y ago
Interesting. I didn't realize that the Air Force security analysis of Multics in the 1970s contained a description of what we call the Thompson attack (have the compiler insert a back door, and because the compiler for the language is written in the language, have the attack persist even when the compiler is recompiled), and this was almost a decade before Thompson's lecture.
- eichin 3y ago
  I'm pretty sure he's credited the air force report before but I believe the actual report only resurfaced recently (maybe some time in the last year?)
  - bentley 3y ago
    Yes, the credit is in the original Reflections on Trusting Trust. > Acknowledgment. I first read of the possibility of such a Trojan horse in an Air Force critique of the security of an early implementation of Multics. I cannot find a more specific reference to this document. I would appreciate it if anyone who can supply this reference would let me know.
- deleted 3y ago
  [deleted]
eesmith 3y ago
Any idea of the minimum amount needed to bribe an open source developer to add nefarious code which will be used in a trusted program? Is there legal liability for making that change, even when the license says NO WARRANTY including for FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT? It's not even like the developer even delivers the software to anyone else. Or is it only social standing? If so, I think $2 million would be enough to retire on. It would seem that this attack vector is relevant for supply chain management. How is it currently evaluated and managed? Also, at 8:27 (https://youtu.be/6H-V-0oQvCA?t=507 https://youtu.be/6H-V-0oQvCA?t=507), "Supply chain security has to be an industry-wide effort." Would an unpaid FOSS developer, perhaps doing this as a retirement hobby, really be considered a part of industry? (For example, a statistician who continues to develop and distribute some very useful analysis software developed over her career, simply because she is interested in the approach.) If so, what if they refuse to follow the demands of for-profit corporations demanding a SBOM and reproducible builds? If not, what should companies should they depend on that FOSS software?
- Veserv 3y ago
  Like literally every other engineering discipline, it should be considered software engineering malpractice to use a component that is not guaranteed to be fit for purpose or that you have not audited to be fit for purpose. If that means you can not use some whizbang library because you do not know if it works and you are too lazy to figure that out for certain, tough. But I want to use the random steel sheets of unknown quality I found lying around to make a airplane is not a acceptable position. But, this does not mean you need to use aircraft grade steel everywhere. You just need to use things at a appropriate level for your purpose. If they really must use software that guarantees nothing, then they must verify it works for their purpose or pay somebody to make it fit for their purpose, simple as that.
  - eesmith 3y ago
    So, no Python, no gcc, no R, ... even Visual Studio says "The software is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions. To the extent permitted under your local laws, Microsoft excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement." and limits direct damages to $5.00. What software do you use which is guaranteed to be fit for purpose and/or have fully audited?

126 points by mfrw 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

robszumski 3y ago

I attended/presented at this event and loved this keynote. I want to push back on the idea that there is no consensus on what an SBOM is — there are two very popular specs! Yes, quality, content and completeness does vary. And every SBOM does need to be enriched with vulnerability and runtime context. But those don’t need to be in the file itself (and aren’t static anyways).

pipingdog 3y ago
The lack of consensus is on what an SBOM is for. Even the NIST recommendation which came out of Executive Order 14028 had little guidance on how to apply SBOM . At any sort of scale, it isn't clear how an SBOM shipped with each package can be consumed to any great effect. A central database of all dependencies, on which queries and analysis can be performed, however, can be very useful, and in a large software shop, I've seen it used to rapidly get a very real sense of the company's exposure to events like the Log4j debacle.
- candiddevmike 3y ago
  Additionally, from what I can tell a lot of SBOM tooling is manual/honor based, and the automated ones don't recurse dependencies well. Trusting the current state of SBOMs seems sketchy
- eichin 3y ago
  A Debian/Ubuntu status file is a good start (of course you need to dig further for build depends) and helpful enough for "provenance" that I've found it useful at a couple of startups to deploy code as debs packages specifically to be part of that graph - obviously not perfect, but often good enough to go automatically from CVE -> USM -> upstream package -> what part of our code cares about that - someone still has to think about the vulnerability, but it reduces a lot of obvious noise and helps drill down quicker.
- Veserv 3y ago
  A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. The sort of engineering 101 processes that almost all software development lacks. It is about making it possible, though not necessarily easy, for somebody to know what they are making. The next step is exhaustiveness and automated production. At this point it will be accurate and exhaustive, but not necessarily easy to use. This is about making it possible, though not necessarily easy, for the consumer to know what they are getting. The next step is then regularity and consistency to make it easy for the consumer to know what they are getting since it follows common, standard rules. After that point we may get to a full reproducible build/linking manifest that allows automated validation that the SBOM matches the delivery. But this step has a good chance of fizzling out as a standard practice in general industry. The first three are clearly where this is all going and constitute a very minor cost relative to a very outsized benefit. We might not even get to the third step, but even then at least general software development would have reached engineering 101 process sophistication which is a massive improvement over the status quo.
  - ploxiln 3y ago
    > A SBOM is for the producer at this time, not the consumer. It is about requiring the producers to at least try to figure out what they put into your soup. > The next step is exhaustiveness and automated production. There are lots of vendors selling automated SBOM generation tools/services, my company's security team is using it. Is the output correct? I don't know, they don't know, nobody looks at it. But we have SBOMs [checkmark]
    - Veserv 3y ago
      Yep, that is the point of the first phase. The next phase is going to be attaching liability for incomplete SBOMs. The way it will likely play out is that if you were breached due to a undisclosed component in a purchased product the product will either be deemed defective or the vendor will be liable. If CISA succeeds at pushing that you will see the SBOMs becoming correct and exhaustive real fast, though likely excessive due to ass-covering. But at this point the goal is clearly just establishing a paper trail so that it can eventually be audited for consequences. Maybe they will fail at the next step due to industry pushback against actual consequences for shoddy work, but that is clearly where it is trying to go.
- beams_of_light 3y ago
  https://security.googleblog.com/2022/06/sbom-in-action-finding-vulnerabilities.html?m=1 https://security.googleblog.com/2022/06/sbom-in-action-findi...
chatmasta 3y ago
For anyone else who has thusfar avoided hearing the acronym "SBOM": > A “software bill of materials” (SBOM)... is a nested inventory, a list of ingredients that make up software components. https://www.cisa.gov/sbom https://www.cisa.gov/sbom

not2b 3y ago

Interesting. I didn't realize that the Air Force security analysis of Multics in the 1970s contained a description of what we call the Thompson attack (have the compiler insert a back door, and because the compiler for the language is written in the language, have the attack persist even when the compiler is recompiled), and this was almost a decade before Thompson's lecture.

eichin 3y ago
I'm pretty sure he's credited the air force report before but I believe the actual report only resurfaced recently (maybe some time in the last year?)
- bentley 3y ago
  Yes, the credit is in the original Reflections on Trusting Trust. > Acknowledgment. I first read of the possibility of such a Trojan horse in an Air Force critique of the security of an early implementation of Multics. I cannot find a more specific reference to this document. I would appreciate it if anyone who can supply this reference would let me know.
deleted 3y ago
[deleted]

eesmith 3y ago

Any idea of the minimum amount needed to bribe an open source developer to add nefarious code which will be used in a trusted program? Is there legal liability for making that change, even when the license says NO WARRANTY including for FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT? It's not even like the developer even delivers the software to anyone else. Or is it only social standing? If so, I think $2 million would be enough to retire on. It would seem that this attack vector is relevant for supply chain management. How is it currently evaluated and managed? Also, at 8:27 (https://youtu.be/6H-V-0oQvCA?t=507 https://youtu.be/6H-V-0oQvCA?t=507), "Supply chain security has to be an industry-wide effort." Would an unpaid FOSS developer, perhaps doing this as a retirement hobby, really be considered a part of industry? (For example, a statistician who continues to develop and distribute some very useful analysis software developed over her career, simply because she is interested in the approach.) If so, what if they refuse to follow the demands of for-profit corporations demanding a SBOM and reproducible builds? If not, what should companies should they depend on that FOSS software?

Veserv 3y ago
Like literally every other engineering discipline, it should be considered software engineering malpractice to use a component that is not guaranteed to be fit for purpose or that you have not audited to be fit for purpose. If that means you can not use some whizbang library because you do not know if it works and you are too lazy to figure that out for certain, tough. But I want to use the random steel sheets of unknown quality I found lying around to make a airplane is not a acceptable position. But, this does not mean you need to use aircraft grade steel everywhere. You just need to use things at a appropriate level for your purpose. If they really must use software that guarantees nothing, then they must verify it works for their purpose or pay somebody to make it fit for their purpose, simple as that.
- eesmith 3y ago
  So, no Python, no gcc, no R, ... even Visual Studio says "The software is licensed “as-is.” You bear the risk of using it. Microsoft gives no express warranties, guarantees or conditions. To the extent permitted under your local laws, Microsoft excludes the implied warranties of merchantability, fitness for a particular purpose and non-infringement." and limits direct damages to $5.00. What software do you use which is guaranteed to be fit for purpose and/or have fully audited?