Post

it definitely doesn’t force Rust, but for safety by design of a C-based system, an auditor should absolutely be requiring either (a) “we use Rust to process all untrusted inputs” or (b) a literal phonebook of other mitigations. Which should be a forcing function.

I really want everyone to use memory-safe languages, but for what the CRA requires, we’ll have to see how the phone book of other mitigations works out. Maybe it will be thorough and practical enough, maybe not. It’d be much more inspiring and fun if the CRA didn’t defer to the state of the art!

I think the Brussels folks will tell you that CRA's standards rise as state of the art rises, and if it had been in place 10 or 20 years ago, "secure by design" would have been a very different target. Open question whether that happens in practice or just gets ossified into 2027-era audit docs.

It still could. Lots of devil in the details.

0 reposts2 likes

that 'top level SBOM' thing is what makes me most twitchy but having thumbed through a couple of CE mark product booklets over the weekend making vendors do the same for digital products really feels like a shift in how orgs *have* to think about software and OSS even if they don't know it yet

when talking to normies, I explain that the law requires software vendors to have a list of ingredients, and the universal response is "you mean... they don't already have that?"

'you know that grease stained recipe you have pinned to the fridge door that you've changed a lot and you've only written down the first few changes because you remember the other ones and then your kid starts to follow it and it doesn't work AT ALL?'