How do you calculate risk on software age alone?

How in the heck can you calculate risk if your only input is the chronological age of a software system? An ancient development meme referred to as "bit decay" might give a bit of insight. This says that "any piece of software, if left to itself, will eventually fail to work". Implied was the idea that the software may not change, but the surrounding factors do; e.g. a tape-based system works fine until someone replaces the tape drive with a slightly different model, forcing idiosyncratic code to fail where it depended upon idiosyncratic features of the hardware that were factored out in the next engineering change. People try to avoid this with software change, but it rarely works -- hard to motivate people to check old code exhaustively. Perhaps a simple rule of thumb -- "nobody does it that way anymore" should take precedence over "it was good enough for grandpappy and we haven't depreciated that asset and nobody died from it yet". Perhaps I'm just growing cynical -- but that's better (by my reckoning) than growing stale. But I know that rule of thumb has traction among the development community, who generally know better -- it's their pond we're swimming in, folks, irrespective of what the business case concludes.