[HN Gopher] Open source supply chain security at Google [video]
___________________________________________________________________
Open source supply chain security at Google [video]
Author : mfrw
Score : 105 points
Date : 2023-11-30 09:26 UTC (13 hours ago)
(HTM) web link (research.swtch.com)
(TXT) w3m dump (research.swtch.com)
| robszumski wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| chatmasta wrote:
| 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
| not2b wrote:
| 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 wrote:
| 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?)
| eesmith wrote:
| 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), "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 wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-30 23:01 UTC)