Should organisations block merges for every non cryptographically secure random use in application code?

When a merge block is justified, and when it is too blunt

Not every use of randomness carries the same security weight. A merge gate is justified when the code path affects authentication, token generation, secrets, session identifiers, anti-CSRF values, nonces, or any other value that must be unpredictable to prevent abuse. In low-risk cases, such as UI shuffling or non-sensitive sampling, a softer response often preserves developer velocity without reducing protection.

The decision point is not whether the function is cryptographically strong in the abstract, but whether an attacker could benefit from predicting the output. If predictability would create a realistic abuse path, the issue belongs in the block-and-fix category. If the output is merely convenience data, a warning or follow-up may be enough.

Use of non-cryptographic randomness becomes more serious when it crosses into credentials or secrets handling, because insecure values can be guessed, replayed, or correlated across sessions. That is the same class of problem that appears in secrets sprawl and hard-coded credential exposure, where the control failure is not randomness itself but the downstream ability to impersonate or reuse trust material. Guide to the Secret Sprawl Challenge is a useful companion for understanding how weak handling of trust material becomes an operational risk.

Why the policy should be risk-based, not function-based

A function-only rule creates false positives. Developers quickly stop trusting alerts when the same hard stop appears for a dice roll in a game, a randomized animation, and a session token. A risk-based rule is more durable because it reserves escalation for code where randomness materially affects confidentiality, integrity, or access control.

That distinction also matters for review quality. A merge block should imply, "this needs a security decision," not, "this pattern is always forbidden." The best policy is one that asks reviewers to classify the business impact of predictability, then choose the lightest control that still prevents meaningful abuse. In practice, that often means code owners can approve low-consequence cases while security teams review anything that touches authentication, authorization, or secret generation.

For stronger guidance on where unpredictability matters in application security, the OWASP ASVS and OWASP Top 10 provide a useful frame for reviewing whether the random value is protecting a sensitive control path rather than just supporting application behaviour.

One practical signal is whether the value is observable or reusable outside the intended request. If the answer is yes, treat the finding as security-relevant until proven otherwise. If the value never leaves a local, non-sensitive computation, automatic blocking is usually disproportionate.

How to tune the workflow without weakening security

A workable policy usually has three tiers: block, notify, and ignore. Block only when weak randomness can enable account takeover, token forgery, session fixation, replay, or similar abuse. Notify security when the use is ambiguous, when the value is exposed beyond the process boundary, or when it is difficult to prove that predictability is harmless. Ignore only when the use is clearly non-sensitive and the output has no trust implication.

Teams should also review the replacement path. If a merge is blocked, developers need an obvious remediation route, such as swapping in a cryptographically secure generator, re-scoping the value so it is no longer security-sensitive, or documenting the exception with an expiry date. The goal is not to punish non-compliance, but to make the secure choice the least expensive choice.

The biggest mistake is treating "non-cryptographic" as an automatically severe finding in every context. The right threshold is exploitability, not purity. When organisations calibrate the policy to real attack paths, they get fewer noisy alerts, better remediation, and stronger support from engineering teams.

Practitioner Guidance

What to prioritise: First classify whether the random value influences authentication, session integrity, secrets, tokens, or any other trust boundary. Those are the cases where predictable output can become a real security defect rather than a style issue.

Decision rule: If an attacker could gain access, impersonate a user, or replay a value by predicting the output, block the merge. If the value cannot affect a trust decision, prefer notification or backlog tracking over a hard stop.

What to verify: Review the full data flow, not just the call site. A harmless-looking random value can become sensitive later if it is embedded into URLs, identifiers, recovery links, caches, or stateful workflows.

Practitioner takeaway: The best policy is selective enforcement, because the security value comes from stopping exploitable predictability, not from banning every non-crypto random call.

Related resources from NHI Mgmt Group

• How should engineering teams use secure guardrails to reduce XSS risk in application code?
• Why do APIs create identity risk even when the application code is secure?
• When should organisations block an AI agent instead of letting teams use it?
• Should organisations scan Docker images for secrets if they already secure the source code?