3 ms·

I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is (if anything I'd sa

by lmm 2y ago

I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is (if anything I'd say it should count for the other side - cost of exploitation divided by cost of remediation is a reasonable measure of how "bad" the bug was, because the cost of remediation is generally proportionate to the cost that was being saved in the first place). Heartbleed has the most expensive case of actual exploitation I can think of - the $73M JP Morgan hack. So far I haven't heard of any attackers actually using the log4j vulnerability. > Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed) How are you counting that? There are definitely embedded systems out there running old versions of OpenSSL that will never be patched. Because there's no standard package management and vendoring dependencies is more common in the C world, it's probably less easy to get a list of vulnerable systems, but that doesn't mean the vulnerability isn't there.

lelanthran 2y ago
> I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks. Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies. In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway. To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.

by lmm 2y ago

lelanthran 2y ago

> I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks. Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies. In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway. To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.