A common requirement for all development projects is that the involved people must always keep their brains active and not assume things. Every thing they do must pass through some form of screening: What exactly are the requirements for this tiny little insignificant piece of the software? Do I fulfill the requirements, even if they may seem insignificant?

Whenever people make the unconcious decision that they can write code, test it and release it and that a bit of testing is enough, bad things will happen. Testing can find errors. But can never prove the nonexistence of errors. So every single line of source code must be the result of explicit decisions after explicit considerations about requirements.

Often, the decisions are too small to make it into a design document. But that's why we have source code comments. To tell why we do things. And often also why we don't do something else.

One assumption often made is that pseudo-random is "almost like random" so that it will be "almost always acceptable" to use for random data.

Many "secure" systems may have generated 128-bit "secure" session identifiers for keeping track of users who have logged in. Or maybe 128-bit "secure" AES crypto keys for secure communication. And they have generated their "secure" data based on extremely bad assumptions. For example using a pid() and timeofday as seed for a pseudorandom generator. If the OS have 30k pid numbers and you know when the user logged in +/- 10 seconds, then an attacker only have 600000 seed values to try to recreate that 128-bit "secure" session id. Oops. 2^128 suddenly became less than 2^20.

The pseudorandom generators may also have a bell curve if you just look at all produced numbers, but may have very large alias between consecutive values. Some pseudorandom generators can produce very strange results if every second value is used as x and every second value as y and the points then plotted.

Not to mention what happens when people do one of the most common things: take the integer value from rand() and apply modulo to produce a smaller numeric range.

What happens with a 16-bit pseudorandom generator when used with modulo 1000? 0..65535 means that 0..535 have 66 chances to get selected, while 566..999 have only 65 chances. Still, this error exists in thousands, if not millions of programs written by people who thinks the pseudorandom generator is quite good.

Not to mention people who have a "coin" that isn't balanced and use this "coin" to produce a random value without normalizing the result. So they get exessive numbers of zero or one.