The biggest risks nowadays comprise not just software, but parts too. My risk list is:
o Company instability, including mergers/acquisitions, bankruptcy or illiquidity.
o EOL'd parts
o Subscription- or time-limited software with either phone home or date/time lookup - AVOID if at all possible!
o Deprecated features, and quicksand software (frequent development-driven agile half-finished releases with shoddy QA [there is a definite correlation!])
I've been directly affected by all of these. At my worst point, I found myself having to completely redesign a product after a fabless supplier went bust, frustratingly with 1/4 million devices idly sitting at their fab assembler, but inaccessible due to the liquidator not releasing them. A year later I had a call asking me if I wanted any, but I'd already redesigned the product. Liquidators are stupid sometimes, I'd originally offered them £70k for the lot, they turned me down, and wouldn't release any at all: a year later they were worth bugger all, as all their customers, like me, had moved on.
EOL'd parts happen for me on pretty much a monthly basis, it's part of life. Often they're just jelly bean passives but for some parts you have to do a substantial re-characterisation. There's not a lot of practical difference between EOL or an out of stock item, you still have to re-test. For some parts there is an MOQ, which ties up capital for an extended period depending on your run rate, and that in itself has risk. While it's a reasonable practice to select more generic parts, it's not always practical, it's the usual set of balancing engineering requirements and priorities, and compromising appropriately.
Maintaining software builds are frustrating, particularly in mothball scenarios, and my solution is a frozen VMWare VM, but even that is not fool proof if you have phone home or subscription time limited dependencies. Even fiddling dates/times nowadays has its risks as it breaks things like Kerberos and certificates.
Deprecated software or quicksand software can be mitigated against with VMs, but there is a remaining problem in that you need to maintain currency on older technology, and its quirks. Personally I prefer that, to having to continually maintain dozens and dozens of mothballed environments.
The benefits of a VM over physical hardware for build environments is that the HALs are consistent, you can archive them more easily, and you can move them around. you can also fiddle dates and times, but this is becoming less easy to do. The downside is that if you have some older stuff that has dependencies on physical COM or LPT ports, and they're targeted directly, you're often out of luck.