Not a bug in the software itself.
That is independent of testing the software, but still a distribution issue.
* "signed with the wrong cert" should mean the software package is rejected before it it is installed.
* software upgrades are tricky and there should be at least 2 versions available so that fallback to the previous is possible and automatic in case of issues.
Or is multiple signed packages and one is wrong.
Or the test cars accept prod and test certs.
Or some combo of the above.
There are lots of ways this could have broken that doesn't amount to rivian not being able to write software
That being said, "signed wrong", including all your hypotheses, that results in a bricked unit is definitely a serious oversight in general.
This also might highlight why production tests should be run on exactly production units. No tweaks allowed.
Talking about those is much more interesting than just asserting that everything should be a certain way, without any consideration for real world constraints, like cost of units, etc.
It would be interesting if you could develop about what you mean by real world constraints and how cost of units affect what I wrote, which I did from real world experience.
You included nothing about how costs affect anything. You simply assert that you should always test prod on pristine production units.
There are plenty of times outside of software where production units cost millions or you can only produce them so quickly, or both, and where your extreme take would result in remarkable cost or a competitor eating your lunch.
Which is precisely why its not done, and in the real world tradeoffs are made between what really needs 100% assurance and not. Spending money or losing customers for 5 9s of reliability through testing when two are needed is not a best practice, and is often explicitly called out as such.
In the case of rivian, maintaining a significant fleet of expensive, pristine, exact customer spec (ie not debuggable) cars just to try to get 100% prod ota success assurance is unlikely to provide value vs getting 98% assurance and not doing that (by rough calculation, it stands at 98% after this incident).
In fact you are trying to spin what I wrote to an extreme to make your point.
By the way, it is not about 100% success assurance but assurance that failure does not brick the unit. This is an assurance that should be, and can be, close to 100%, indeed a good number of 9s because, obviously you cannot brick 2 cars out of 100 for every software upgrade!
This would not cause the updater to fail unless it verified the certs of all the binaries in the package, which most don't
It's easy to imagine a central SoC receiving the update, verifying its signature against a local key and then reprogramming some MCU over an internal interface. But then after resetting the MCU, you realize that the image you just flashed isn't compatible with the boot security keys burned into that MCU. It's not uncommon for a device performing the OTA update to not have access to the "source of truth" keys / certificates used to verify the updated image at boot time.
Not that this is a great excuse. If you add OTA updates to a product that has this design, you should really be confident in your recovery solution.