Operating systems provide one, seeded from hardware entropy: getrandom(2) and /dev/urandom on Linux, getentropy and arc4random on macOS and BSDs, BCryptGenRandom on Windows. Language APIs wrap them: crypto.getRandomValues() in browsers (at most 65,536 bytes per call), crypto.randomBytes in Node.js, Python's secrets, Go's crypto/rand, Java's SecureRandom. Math.random(), Python's random and similar general-purpose generators are predictable and must never produce secrets.
NIST SP 800-90A Rev. 1 specifies the approved deterministic generators (Hash_DRBG, HMAC_DRBG and CTR_DRBG), SP 800-90B the entropy sources and SP 800-90C how to combine them; FIPS 140-3 modules must use them. The withdrawn Dual_EC_DRBG is the textbook example of a generator with a suspected backdoor.
Most real-world RNG failures are about seeding, not algorithms: embedded devices generating keys before enough entropy is available, cloned virtual machines resuming with the same state, and forked processes sharing a generator. ECDSA is especially sensitive because a predictable nonce exposes the key; deterministic or hedged nonces remove that dependency.