Lessons from the Money Forward GitHub Incident — Source Code Leak Audits Essential for Custom Development in 2026

In late April 2026, an article titled "Analyzing the Money Forward GitHub unauthorized access incident from an engineer's perspective — Why production credit card information and authentication keys were in the source code" trended on Zenn for an extended period. While attention often focuses on the sensational entry point of unauthorized access to private repositories, the core issue is that "catastrophic secrets were hardcoded directly into the source code"—a risk that is all too relevant in custom development.

Our company always performs a "secret audit" before and after delivering systems built for clients. Using the lessons extracted from the Money Forward incident as a starting point, this article details essential repository management standards, inspection tools, and pricing ranges for custom development.

Why "production credentials in source code" happen

While technical details of the incident are covered thoroughly in the aforementioned Zenn article, the patterns leading to identical incidents in client development boil down to the following.

In particular, secrets remaining only within Git history are troublesome and can never be discovered through reviews that inspect only the latest HEAD. Because they are exposed the moment an attacker runs git log -p once, it creates a structure where you are done for the instant an archive of the leaked repository circulates.

Four lessons to draw from the Money Forward incident

Based on the published incident response details and external commentary, the lessons that should be incorporated into custom development can be organized into the following four points.

Lesson 1: Enforce "never put secrets in Git" at the physical layer

Because human error inevitably occurs, protect systems with mechanisms ensuring that "even if someone accidentally commits them, they never reach Git." Specifically, this involves a three-tier setup:

1. Block before commit with pre-commit hooks (gitleaks / trufflehog)
2. Block before push with GitHub Push Protection (GitHub Advanced Security)
3. Block contamination into the main branch with full scans in CI

Lesson 2: Keep production card details and identity verification info "outside the system"

The standard architecture for payment and identity verification data is to never store them in internal systems. By routing through tokenization via providers such as Stripe, GMO, or Square, sensitive information remains strictly with the payment provider. When a custom development requirement asks to "store credit card numbers in the database," the first step is to challenge this during design reviews to see if tokenization suffices instead.

Lesson 3: Establish operations to monitor repository "access logs"

Unauthorized access to private GitHub repositories is logged as "normal access from authorized accounts." To detect this, your only choice is to configure alerts for anomalies in audit logs (such as late-night activity, overseas IPs, or large-volume clones in short windows). GitHub Enterprise Audit Log Streaming paired with a SIEM serves as the standard solution.

Lesson 4: Drill the "first 30 minutes" of incident response

It has become common knowledge that when an incident occurs, actions taken in the first 30 minutes determine the scope of damage. Even for systems built in custom development, you should always attach an "Initial Response Runbook for Suspected Secret Leaks (30-Minute Edition)" upon delivery. This corresponds to the initial response guide for the overall repository security assessment covered in GitHub Code Security Risk Assessment.

Procedures for secret audits that must always be performed in custom development

We share the standard secret audit procedures our company executes before and after delivery in custom development projects.

[Phase 1] HEAD スキャン（1〜2 時間）
  ├─ gitleaks detect --source . -v
  ├─ trufflehog filesystem . --json > truffle-head.json
  └─ 検出されたシークレットを台帳に記録

[Phase 2] Git 全履歴スキャン（2〜6 時間、リポジトリ規模次第）
  ├─ trufflehog git file://. --json > truffle-history.json
  ├─ git log -p で目視確認すべきコミット範囲を特定
  └─ 過去にコミットされて削除済みのシークレットも漏れなく拾う

[Phase 3] 検出シークレットの "生死判定"（1〜2 日）
  ├─ AWS / GCP / Stripe など発行元 API で当該キーが有効か確認
  ├─ 有効なら即時失効依頼 + 顧客報告
  └─ 失効済みでも台帳化（再発防止策の根拠資料）

[Phase 4] 履歴クリーニング（必要時、半日〜2 日）
  ├─ git filter-repo / BFG Repo-Cleaner で履歴から除去
  ├─ 全コラボレーターに force-push 後の手順を周知
  └─ 旧クローンの破棄を顧客側に依頼

[Phase 5] 再発防止策の実装（1〜3 日）
  ├─ pre-commit + Push Protection + CI スキャンの 3 段重ね
  ├─ シークレット管理基盤（AWS Secrets Manager / GCP Secret Manager / Vault）
  └─ ランブック（漏洩疑い時 30 分初動）の納品

The key point is the "validity check" in Phase 3. Even if a secret remains in Git history, the damage is zero if it has already been revoked; however, if an unrevoked key lies dormant in the history, there is a risk it is being actively exploited right at this very moment should the repository have been leaked previously. The operational priority is to "first verify whether it is active" rather than to "remove it from history for now."

Five secret operations items to standardize in custom development

Here is an overview of five secret operations items that should be agreed upon with clients during project handoff in custom development.

The rule to commit only .env.example is especially powerful, bringing the secondary benefit of formalizing the exact steps for new onboarding members to create their .env. This represents the basic workflow of centralized secret management covered in Secret Management in the Agent Era with HashiCorp Vault 2.

Inspection tool comparison — practical options for custom development

While numerous secret detection tools exist, we compare those that offer great usability in custom development environments.

Our standard is a three-layer architecture: gitleaks (pre-commit) + trufflehog (at delivery) + GitHub Secret Scanning (operations), and this is the setup we most frequently propose first.

Delivery checklist — 12 immediately usable items for custom development

Finally, here is a 12-item checklist that can be used as-is when handing over custom development projects.

• gitleaks detect is clean across all commits on main
• trufflehog git file://. is clean across all history (or contains only known, revoked keys)
• .env / .env.local etc. are included in .gitignore
• .env.example is committed and clearly lists all required keys
• All secrets are consolidated in Secrets Manager / Vault, etc.
• Pre-commit hooks are bundled in the distribution package
• Secret scanning is configured as a mandatory check in CI
• GitHub Push Protection is enabled (if under a GHAS contract)
• Audit Log Streaming + alert settings are active
• Initial response runbook for suspected leaks is included in deliverables
• API key rotation cycles are documented
• 90-day post-delivery support terms are explicitly stated in the SOW

This corresponds to the data-layer version of the "guardrail philosophy" described in Design Patterns for Converting Existing APIs into MCP Servers and Production DB Deletion Guardrails for AI Agents. In the era of AI agents, physical blocking on the machine side has become even more critical under the assumption that agents, not just humans, might mistakenly make commits.

Conclusion — embedding "designs that prevent incidents" into custom development rather than "reacting after incidents occur"

The Money Forward incident served as a wake-up call for the entire industry, which had taken the convenience of Git for granted. To ensure that systems built through custom development never compromise client trust, we believe it is the contractor's responsibility to embed secret audits into standard processes both before and after delivery.

If you want to conduct a comprehensive inventory of secret contamination in existing repositories or rebuild recurrence prevention measures alongside your development partner, please feel free to reach out via our contact form.

Sources

• Analyzing the Money Forward GitHub Unauthorized Access Incident from an Engineer's Perspective (Zenn)
• gitleaks（GitHub）
• trufflehog（GitHub）
• GitHub Secret Scanning Documentation