Notifications
Clear all
Topic starter
19/08/2026 3:42 pm
TL;DR: Java.time bugs often compile, pass tests, and still return silently wrong answers, especially when LocalDateTime is used across timezones or when tests call now() without an injected Clock, according to Sonar. The risk is not just correctness drift but downstream billing, SLA, and scheduling errors that look plausible enough to survive review.
NHIMG editorial — based on content published by Sonar: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams handle time-based logic in token expiry and session controls?
A: Use explicit, zone-aware time types and inject a controllable Clock into any logic that governs expiry, renewal, or revocation.
Q: Why do local timestamps create risk in identity and access systems?
A: Local timestamps record wall-clock values without timezone context, so elapsed-time calculations can look correct while still being wrong.
Q: What do teams get wrong about comparing Java value-based types?
A: They often compare references instead of values, which makes code appear to work in tests and fail in production.
Practitioner guidance
- Convert elapsed-time logic to zone-aware types Review every duration calculation that uses LocalDateTime or similar local types.
- Inject a controllable Clock into security logic Require an explicit Clock in services that decide expiry, renewal, or access revocation.
- Ban identity comparisons on value-based types Add static analysis rules and code review checks for == and System.identityHashCode() on Instant, Optional, and wrapper types.
What's in the full article
Sonar’s full analysis covers the rule mechanics and code patterns this post intentionally leaves at a higher level:
- Rule-by-rule examples for detecting timezone-blind duration math and non-deterministic clock usage
- SonarQube Cloud and Server rollout details for the eight java.time rules
- False-positive handling notes for test code and assertion patterns
- The exact static analysis patterns used to catch identity comparisons on value-based types
👉 Read Sonar’s analysis of silent java.time bugs and the new rule set →
LocalDateTime arithmetic: what it means for reliable time handling?
Explore further
19/08/2026 4:21 pm
Silent temporal drift is a governance problem, not a formatting bug. The article shows how LocalDateTime can produce plausible but incorrect results that survive review and unit tests. That matters to IAM and NHI governance because token expiry, session validity, and access windows all depend on trustworthy time semantics. If a control decision is time-based, the clock source and timezone model are part of the control design, not an implementation detail.
A question worth separating out:
Q: How do you know if time handling is safe enough for security decisions?
A: The best signal is repeatable behaviour under fixed clocks and multiple zones. If tests only pass when they depend on the system clock, or if access and expiry logic changes under timezone shifts, the implementation is not yet safe for security-critical use.
👉 Read our full editorial: Silent time bugs in java.time expose the limits of local dates
