259
Let's blame the dev who pressed "Deploy" - by Dmitry Kudryavtsev
(yieldcode.blog)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
If only we had terms for environments that were ment for testing, staging, early release and then move over to our servers that are critical...
I know it's crazy, really a new system that only I came up with (or at least I can sell that to CrowdStrike as it seems)
Check Crowdstrike's blurb about the 1-10-60 rule.
You can bet that they have a KPI that says they can deliver a patch in under 15m; that can preclude testing.
Although that would have caught it, what happened here is that 40k of nuls got signed and delivered as config. Which means that unparseable config on the path from CnC to ring0 could cause a crash and was never covered by a test.
It's a hell of a miss, even if you're prepared to accept the argument about testing on the critical path.
(There is an argument that in some cases you want security aystems to fail closed; however that's an extreme case - PoS systems don't fall into that - and you want to opt into that explicitly, not due to a test omission.)
That's the crazy thing. This config can't ever been booted on a win10/11 machine before it was deployed to the entire world.
Not once, during development of the new rule, or in any sort of testing CS does. Then once again, never booted by MS during whatever verification process they (should) have before signing.
The first win11/10 to execute this code in the way it was intended to be used, was a customer's machine.
Insane.
Possibly the thing that was intended to be deployed was. What got pushed out was 40kB of all zeroes. Could've been corrupted some way down the CI chain.
Which definitely wouldn't have been a single developer's fault.
Developers aren't the ones at fault here.
Not the most at fault, but if you sign off on a shitty process, you are still partially responsible
That depends entirely on the ability to execute change. CTO is the role that should be driving this.