Pseudo-random generators and pitfalls
First, If the source isn’t explicitly labeled as “secure” or “crypto” in its name, you must assume it is insecure.

For example, in C#, the System.Random is insecure while System.Security.Cryptography.RandomNumberGenerator is obviously intended to be a secure RNG.

Second, you’ll need to actually do some research to ensure that it is, in fact, going to be a secure RNG in the version you are using, and in the target deployment environment. Will you have an entropy source when it is deployed?

Most languages let you access the operating system’s secure RNG in some way; these should be preferred over any user-space generators to ensure fork()-safety. User-space RNGs are also far more likely to have bugs or their state compromised by bugs in user-space applications, which history shows are innumerable.

For example, Pythons os.urandom() doesn’t mention security in its name, but it does call the operating systems secure RNG directly (/dev/urandom on Linux and CryptGenRandom on Windows). When you use the OS generator you also don’t need to evaluate the security of a particular language’s generator user-space algorithm choices or implementation quality.

The OS generator on any recent mainstream OS can be trusted, unless you’re deploying into an environment with no entropy source (such as an embedded Linux device with no user inputs and no hardware RNG).