Commit timezone consistent with stated geography
A dev identity & insider risk factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor analyzes the distribution of commit timestamps in the protocol's public repository and checks whether the commit-hour distribution is consistent with the team's publicly stated geography and time zone. A strong clustering of commits outside the stated time zone — for instance, a US-based team with the majority of commits landing between 01:00–06:00 UTC (consistent with East Asian working hours) — is a weak signal of time-zone misrepresentation associated with DPRK developer-implant tactics. Measurement is programmatic via GitHub API commit timestamp analysis. Category 7 context: time-zone anomaly is an explicit weak signal in DPRK developer-implant profiling.
Why it matters
DPRK IT workers operating under false identities typically work on schedules consistent with North Korean Standard Time (UTC+9) or adjacent zones, regardless of the geography claimed in their public profiles. Trail of Bits and Unit42 research on DPRK developer infiltration documented time-zone mismatches as one of several behavioral indicators. The signal is weak in isolation and generates false positives for teams with distributed contributors across multiple zones. However, when combined with other Cat 7 indicators (pseudonymous identity, mixer funding, short contributor tenure), the time-zone anomaly pattern strengthens the insider-risk assessment.
Green / Yellow / Red
Green is scored when commit-hour distribution is broadly consistent with the stated geography (within a two-hour tolerance band accounting for late/early work). Yellow applies when commit-time distribution has a bimodal pattern consistent with a distributed team across multiple zones, even if one cluster is in a high-risk zone — the bimodality itself suggests legitimate distribution. Red is scored when greater than 70% of commits land in a time window inconsistent with the stated geography and consistent with known DPRK working hours, with no plausible distributed-team explanation.
Common gray cases
Gray is assigned when the repository is private or has fewer than 50 commits in the trailing 90 days, making statistical analysis unreliable.
Notable historical examples
No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for#
Determine whether the distribution of commit hours in the repo is consistent with the team's publicly stated geography (anomaly flag for DPRK-precursor pattern).