要旨

「開発委託先が誤ってソースコードをパブリックリポジトリに公開してしまった。そのコードにはデータベースのアクセスキーが含まれていた」——これはトヨタのT-Connect事案（2022年）の概要です。GitHubに公開されたソースコード内のアクセスキーが、2017年12月から2022年9月までの約5年間にわたって誰でも閲覧できる状態になっており、296,019件の顧客情報が流出リスクにさらされました[1]。

「CI/CDプラットフォームにシークレットを保存していた。そのプラットフォーム自体がマルウェアに感染し、すべてのシークレットが窃取された」——これはCircleCI事案（2023年1月）の概要です。環境変数として保存されていたAWSアクセスキー・APIトークン・SSHキーが組織横断で流出し、世界中の企業が緊急ローテーション対応に追われました[2]。

両事案に共通する根本原因は「長期間有効なアクセスキーを、コードや環境変数として扱ったこと」です。この問題を技術的な設計で根絶する手段がAWS OIDC（OpenID Connect）です。本記事では、事案の詳細を解剖した上で、GitHub Actions + AWS OIDC による「アクセスキーを生成しない」設計への完全移行手順を解説します。

注意事項：本記事は、教育目的のセキュリティ情報共有を目的としています。

記事本文

1. トヨタT-Connect事案——5年間気づかなかったアクセスキー露出

1-1. 何が起きたか

トヨタのコネクテッドカーサービス「T-Connect」の開発を担った委託先が、2017年12月にソースコードの一部を誤ってパブリックなGitHubリポジトリに公開しました。そのコードにはカスタマーデータベースへのアクセスキーがハードコードされていました[1]。

"In December 2017, a subcontractor inadvertently pushed portions of the T-Connect source code, including an access key to a customer database, to a public GitHub repository. The exposed repository was only discovered in September 2022, nearly five years later, when security researchers identified its public availability."
— NHIMG, "Toyota Breach" [1]
https://nhimg.org/toyota-breach

公開されていたリポジトリへのアクセスは無制限——つまり、悪意ある第三者がいつでもアクセスキーを取得し、顧客データにアクセスできる状態が1,734日間続いていたことになります。

1-2. タイムラインと被害規模

T-Connect 事案のタイムライン：

2014年       T-Connect サービス開始

2017年12月   開発委託先が誤ってソースコードを
             パブリック GitHub リポジトリに公開
             → アクセスキーがインターネット全体に露出

             ▼（4年9ヶ月間、誰も気づかない）

2022年9月15日 外部のセキュリティ研究者がリポジトリを発見
             → トヨタに通報
             → リポジトリを即日プライベート化

2022年9月17日 データベースのアクセスキーを変更・無効化

2022年10月7日 トヨタが公式発表・顧客へ謝罪
             「調査の結果、第三者によるアクセスは
             確認できなかったが、完全には否定できない」

公式発表によれば影響を受けたのは296,019件の顧客のメールアドレスと顧客管理番号です[3]。クレジットカード情報・氏名・住所・電話番号はそのサーバーに保存されていなかったため流出を免れましたが、のちに行われた調査でトヨタの別のクラウド設定ミスにより200万件の車両位置情報・走行データが約10年間流出していたことも判明しています[4]。

1-3. なぜ5年間気づかなかったのか

セキュリティ専門家はこの事案の本質的な問題を次のように指摘しています。

"Though security experts recommend periodic rotation of API keys, Toyota took a slightly different tactic and allowed the same key, the one exposed in source code, to be used for five years. From 2017 to 2022, that key dutifully provided administrative access to anyone that knew it."
— Jason Kent, Cequence Security（SiliconANGLE経由）[5]
https://siliconangle.com/2022/10/11/toyota-warns-possible-data-theft-access-key-left-exposed-github/

5年間気づかなかった理由は構造的なものです。「アクセスキーが漏洩した」というイベント通知は発生しません。コードはパブリックリポジトリに存在し続け、アクセスキーもその中に存在し続けました。悪用されたかどうかは、ログを見ても正規アクセスと区別できないのです。

GitGuardianによるこの事案の分析は、問題の普遍性を次のように描写しています。

"Data exposures on public Git repositories are a particularly troubling topic. This incident adds Toyota to the list of companies that have had similar exposures; a list that includes Samsung, Nvidia, and Twitch, just to name a few."
— GitGuardian Blog, "Toyota Accidentally Exposed a Secret Key Publicly on GitHub for Five Years" [6]
https://blog.gitguardian.com/toyota-accidently-exposed-a-secret-key-publicly-on-github-for-five-years/

2. CircleCI事案——CI/CDプラットフォーム経由の全シークレット流出

2-1. 何が起きたか

CircleCIは世界で100万人以上のエンジニアが利用するCI/CDプラットフォームです。2023年1月4日、同社は全顧客に対して「CircleCIに保存しているすべてのシークレットを即座にローテーションせよ」という緊急アラートを発出しました[7]。

CircleCI自身のインシデントレポートは攻撃の入り口をこう説明しています。

"An unauthorized third party leveraged malware deployed to a CircleCI engineer's laptop in order to steal a valid, 2FA-backed SSO session. This machine was compromised on December 16, 2022. The malware was not detected by our antivirus software."
— CircleCI, "Jan-4-2023 Incident Report" [2]
https://circleci.com/blog/jan-4-2023-incident-report

2-2. 攻撃チェーンの全体像

CircleCI 事案の攻撃チェーン：

2022年12月16日
  CircleCI エンジニアのノートPCにマルウェアが感染
  → アンチウイルスに検知されなかった

     ▼ マルウェアが 2FA 認証済みセッションクッキーを窃取

  攻撃者：窃取したセッションクッキーで 2FA をバイパスして
          エンジニアになりすまし、本番システムにアクセス

  このエンジニアは「本番アクセストークンの生成」権限を持っていた

     ▼ 本番システムの暗号化キーを含む
       すべてのシークレット（環境変数・API トークン）を窃取

     ▼ 顧客の CircleCI 環境変数として保存されていた
       AWS アクセスキー・GitHub OAuth トークン・SSH キーが
       暗号化されているにもかかわらず
       暗号化キーも窃取されたため事実上平文で露出

2022年12月29日
  顧客が GitHub の不審な OAuth アクティビティを発見
  → CircleCI に通報

2023年1月4日
  全顧客に緊急ローテーション要請を発出

"Secrets such as environment variables, API tokens, and SSH keys were exfiltrated. Integration credentials for platforms like GitHub and AWS were compromised. Although customer data was encrypted at rest, access to encryption keys rendered the protection ineffective."
— NHIMG, "CircleCI Breach" [8]
https://nhimg.org/circleci-breach

2-3. 「2FAをしていたのにやられた」という衝撃

このインシデントが特に重大な理由は「2FAをバイパスした」という点です。マルウェアはパスワードではなく認証済みセッションクッキーを盗んだため、2FAは機能しませんでした。「2FAをしているから安全」という認識が崩れた瞬間でした。

CircleCIが顧客に要求した緊急対応は苛酷なものでした——すべてのシークレット・環境変数・APIトークン・SSHキーを即座にローテーションすることです[9]。これだけで数百・数千のシークレットを管理していた企業の運用チームには数日〜数週間のインシデント対応が発生しました。

CI/CDプラットフォームが攻撃者にとって魅力的な理由を専門家はこう述べています。

"These tools have tokens that give access to code repositories. They have deployment tokens that affect production code, they have data access tokens. A successful breach of these CI/CD tools is almost like achieving single sign-on into an organization's entire ecosystem."
— Aakash Shah, oak9（Security Boulevard経由）[10]
https://securityboulevard.com/2023/01/circleci-rotates-github-oauth-tokens-after-security-incident/

3. 「長期間有効なアクセスキー」という設計上の欠陥

3-1. 問題の本質——「保存している」こと自体がリスク

両事案の根本原因を一言で表すなら「保存された長期間有効な認証情報」です。

長期間有効なアクセスキーが抱える構造的な問題：

① 流出経路が無数にある
  ├── コードへの直接埋め込み（T-Connect 事案）
  ├── CI/CD プラットフォームの環境変数（CircleCI 事案）
  ├── .env ファイルのコミット
  ├── コンソール画面のキャプチャ
  └── チーム Slack・チケット・ドキュメントへの貼り付け

② 有効期限がない（または非常に長い）
  → トヨタのキーは 5 年間有効だった
  → 流出しても「期限切れになるまで使い続けられる」

③ 流出してもすぐには気づかない
  → 正規アクセスと攻撃者のアクセスを
     ログだけでは区別できない

④ ローテーションのコストが高い
  → CircleCI 事案では全顧客が数日かけて手動ローテーション
  → ローテーション自体がサービス障害リスクになる

⑤ 爆発半径が広い
  → 1 つのキーで多くの権限が行使できる
  → 「最小権限」の実施が形骸化しやすい

GitGuardianの2026年版State of Secrets Sprawlレポートによれば、2025年にパブリックGitHubリポジトリに新たに追加された有効なシークレットは2,865万件（前年比34%増）。そのうち70%近くが2年以上経過してもなお有効なままです[6]。

3-2. 「環境変数で管理すれば安全」という誤解

「コードにハードコードせず、GitHub SecretsやCI/CDの環境変数で管理している」——これは確かにコードへの直接埋め込みよりは安全です。しかし CircleCI 事案はこの「一歩先の対策」すら突破されることを実証しました。

環境変数管理の限界：

通常の想定：
  アクセスキー
  → GitHub Secrets / CircleCI 環境変数 に保存
  → ワークフロー実行時のみ利用
  → コードには含まれない

CircleCI 事案が示した現実：
  アクセスキー
  → CircleCI 環境変数 に保存
  → CI/CD プラットフォーム自体が侵害される
  → 保存されたすべてのシークレットが流出

根本的な問題：
  「どこに保存するか」を工夫しても
  「長期間有効なアクセスキーが存在する」限り
  保存場所が侵害された瞬間にすべてが失われる

4. AWS OIDC——「アクセスキーを生成しない」という根本解決

4-1. OIDCとは何か

AWS OIDC（OpenID Connect）はGitHub Actionsがアクセスキーなしに一時的なAWSクレデンシャルを取得できる認証メカニズムです。GitHubがアイデンティティプロバイダー（IdP）として機能し、ワークフロー実行ごとに短命なJWT（JSON Web Token）を発行します。

"OpenID Connect (OIDC) allows your GitHub Actions workflows to access resources in Amazon Web Services (AWS), without needing to store the AWS credentials as long-lived GitHub secrets."
— GitHub Docs, "Configuring OpenID Connect in Amazon Web Services" [11]
https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services

4-2. 認証フローの全体像

AWS OIDC 認証フロー：

GitHub Actions ワークフローが起動
    │
    ▼
GitHub がワークフロー固有の JWT を生成
  JWT に含まれる主要クレーム：
  ・発行者（iss）: https://token.actions.githubusercontent.com
  ・対象（sub）: repo:myorg/myrepo:ref:refs/heads/main
  ・対象者（aud）: sts.amazonaws.com
  ・リポジトリ名・ブランチ名・ワークフロー名・環境名
  ・有効期限（exp）: ジョブ終了後に自動的に無効化
    │
    ▼
GitHub → AWS STS（Security Token Service）に JWT を送信
    │
    ▼
AWS が IAM 信頼ポリシーと JWT クレームを照合
  確認項目：
  ✅ 発行者が token.actions.githubusercontent.com か
  ✅ sub が許可されたリポジトリ/ブランチか
  ✅ 対象者が sts.amazonaws.com か
  ✅ JWT の署名が GitHub の公開鍵で検証できるか
    │
    ├── 一致しない → 拒否（403）
    │
    └── 一致する → 一時的クレデンシャルを発行
         ・有効期間：最大1時間（デフォルト）
         ・自動的に期限切れ・消滅
         ・保存もローテーションも不要
    │
    ▼
GitHub Actions がこの一時クレデンシャルで AWS にアクセス
    │
    ▼
ジョブ終了 → クレデンシャル自動消滅

"AWS never sees your GitHub credentials, and GitHub never sees your AWS credentials. The JWT is the only thing exchanged and it's signed, scoped, and short-lived."
— freeCodeCamp, "How to Set Up OpenID Connect (OIDC) in GitHub Actions for AWS" [12]
https://www.freecodecamp.org/news/how-to-set-up-openid-connect-oidc-in-github-actions-for-aws/

4-3. 旧来の方式との比較

観点	旧来（アクセスキー方式）	OIDC 方式
認証情報の保存場所	GitHub Secrets（半永久的）	存在しない
有効期限	デフォルト無期限	ジョブ終了後に自動消滅（最大1時間）
流出時のリスク	キーが有効な限り悪用可能	最大1時間で無効化
ローテーション	手動・サービス障害リスクあり	不要（自動）
CircleCI 事案での被害	AWS キーが窃取・悪用される	キーが存在しないため窃取できない
T-Connect 事案での被害	コード内のキーが5年間露出	コードにキーが存在しない
CloudTrail での追跡	AccessKeyId でフィルタ	想定ロール ARN で追跡可能

"The most immediate benefit is the removal of long-lived access keys from the CI/CD pipeline entirely. There are no secrets to store, rotate, or risk leaking. This addresses the single largest attack surface in traditional GitHub Actions-to-AWS authentication."
— Parsectix, "GitHub Actions and OIDC Integration with AWS" [13]
https://parsectix.com/insights/github-actions-oidc-aws-integration/

5. 設定手順の全体像——ゼロから始める AWS OIDC

OIDC導入に必要な作業は大きく「AWS側の設定」「GitHub Actions ワークフローの変更」「旧来キーの廃止」の3フェーズに分かれます。

フェーズ1：AWS 側の設定

必要な作業1：OIDCプロバイダーの登録

AWSコンソールまたは AWS CLI で、GitHubをOIDCプロバイダーとしてIAMに登録します。この作業はAWSアカウントに対して1回だけ実施すれば、そのアカウント内のすべてのリポジトリで共有できます。

登録に必要な情報は次の3つです。

プロバイダーURL：https://token.actions.githubusercontent.com
クライアントID：sts.amazonaws.com
サムプリント（GitHubのTLS証明書を識別する値）：6938fd4d98bab03faadb97b34396831e3780aea1

"The OIDC provider is created once per AWS account, not per repository. All your repositories share it."
— GitHub Actions OIDC Guide [14]
https://aloknecessary.github.io/blogs/github-actions-oidc/

必要な作業2：IAMロールの作成とトラストポリシーの設定

次に「GitHubワークフローが引き受けることができるIAMロール」を作成します。このロールの信頼ポリシー（Trust Policy）が「どのリポジトリ・どのブランチ・どの環境からのリクエストを許可するか」を定義するため、設計が最も重要なポイントです。

トラストポリシーで制限すべき条件：

トラストポリシーの条件設計：

必須の条件（すべてを指定）：
  ・audience (aud) = sts.amazonaws.com
  ・subject (sub) = repo:<org名>/<リポジトリ名>:ref:refs/heads/main
                   または
                   repo:<org名>/<リポジトリ名>:environment:production

推奨設定（最小権限の観点から）：
  ✅ 本番デプロイ：main ブランチ または production 環境のみ
  ✅ ステージングデプロイ：develop ブランチ または staging 環境のみ
  ✅ CI（テスト）：全ブランチからの読み取り専用
  ❌ NG例：sub 条件を * にする（すべてのリポジトリを許可してしまう）

"The trust policy must explicitly define GitHub's OIDC provider as a valid identity source. Access should be restricted based on repository name, workflow name, and branch to prevent unauthorized workflows from assuming IAM roles."
— Firefly, "Integrating OIDC with GitHub Actions for Terraform on AWS" [15]
https://www.firefly.ai/academy/integrating-oidc-with-github-action-to-manage-terraform-deployment-on-aws

必要な作業3：用途別IAMロールの分離設計

1つのロールにすべてのデプロイ権限を集約することは「爆発半径が大きくなる」設計ミスです。用途ごとにロールを分離し、最小権限を徹底します。

用途別ロールの設計例：

GitHubActions-CI-ReadOnly（CI・テスト用）
  └── 権限：S3バケットからテストデータを読み取りのみ
  └── 許可する sub：全ブランチ

GitHubActions-Staging-Deploy（ステージングデプロイ用）
  └── 権限：ステージング S3・CloudFront のみ操作可能
  └── 許可する sub：develop ブランチのみ

GitHubActions-Production-Deploy（本番デプロイ用）
  └── 権限：本番 S3・CloudFront のみ操作可能
  └── 許可する sub：main ブランチ または production 環境のみ

フェーズ2：GitHub Actions ワークフローの変更

ワークフロー YAML ファイルに必要な変更は2点のみです。

変更点1：パーミッションの追加

ワークフローファイルのトップレベルまたはジョブレベルに permissions: id-token: write を追加します。これがないとGitHubはOIDCトークンを発行しません。合わせてコードチェックアウトに必要な contents: read も明示します。

変更点2：aws-actions/configure-aws-credentials アクションの設定変更

従来は aws-access-key-id と aws-secret-access-key を指定していた箇所を、role-to-assume に作成したIAMロールのARNを指定するだけです。アクセスキー関連のパラメータはすべて不要になります。

"OpenID Connect (OIDC) solves this entirely. Instead of storing long-lived credentials, GitHub Actions requests a short-lived token directly from AWS every time your workflow runs. No secrets to rotate."
— OneUptime Blog [16]
https://oneuptime.com/blog/post/2026-01-25-github-actions-oidc-aws/view

2026年7月以降の推奨設定（Immutable Subject Claims）

"July 2026 change: For repositories created after July 15, 2026, or that have opted into immutable subject claims, the sub claim includes the numeric owner and repository IDs rather than the mutable names. This means a repository rename no longer breaks your trust policy — the ID is stable. New repositories should opt into this immediately."
— GitHub Actions OIDC Guide [14]
https://aloknecessary.github.io/blogs/github-actions-oidc/

2026年7月15日以降に作成されたリポジトリ、またはImmutable Subject Claimsを有効化したリポジトリでは、subクレームにリポジトリ名ではなく数値IDが含まれるようになりました。リポジトリをリネームしてもトラストポリシーが壊れなくなるため、既存リポジトリでも積極的に有効化することを推奨します。

フェーズ3：旧来のアクセスキーの廃止

移行後の廃止ステップ：

Step 1: OIDC に切り替えたワークフローが
        正常に動作することを1〜2週間確認

Step 2: GitHub Secrets から
        AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を削除

Step 3: IAM コンソールで旧来のアクセスキーを「無効化」
        （まず削除せず無効化して様子を見る）

Step 4: 1〜2週間異常がないことを確認後、アクセスキーを「削除」

Step 5: そのIAMユーザーが OIDC ロール引き受け専用に
        なっていた場合は IAM ユーザー自体を削除

注意：Step 3 と Step 4 の間に「削除したらワークフローが
      動かなくなった」というケースが稀にある。
      まず無効化→動作確認→削除という順序を守ること。

6. OIDC 導入後の監視設計

OIDC に移行すると「アクセスキーの漏洩リスク」は排除されますが、「不正なワークフローからのロール引き受け」というリスクは残ります。CloudTrail で継続的に監視します。

監視すべきCloudTrailイベント

OIDCによるロール引き受けは CloudTrail に AssumeRoleWithWebIdentity イベントとして記録されます。このイベントにはどのリポジトリ・ブランチ・ワークフローがロールを引き受けたかの情報が含まれているため、想定外のソースからの引き受けを検知できます。

CloudTrail で監視すべき兆候：

⚠️ 想定外のリポジトリからのロール引き受け
   → トラストポリシーの設定ミス、または fork リポジトリからの不正実行

⚠️ 深夜・休日の想定外のタイミングでのロール引き受け
   → 不正な scheduled ワークフローの可能性

⚠️ 同一ロールへの短時間での大量の引き受け試行
   → スキャンまたはブルートフォースの可能性

⚠️ 高権限操作（DeleteBucket・IAM変更など）の実行
   → 最小権限の原則が守られていない可能性

"Every call made using the temporary credentials is logged in CloudTrail under the assumed role ARN. This gives you a full audit trail of exactly what your workflow did in AWS."
— freeCodeCamp [12]
https://www.freecodecamp.org/news/how-to-set-up-openid-connect-oidc-in-github-actions-for-aws/

EventBridge + SNS によるリアルタイムアラート

CloudTrail のイベントを EventBridge ルールで監視し、想定外のロール引き受けが発生した際に SNS 経由で Slack や PagerDuty に通知する仕組みを構築します。これにより、トヨタ事案のような「18日間気づかない」状況を防げます。

7. Terraform による OIDC インフラのコード管理（推奨）

OIDC プロバイダーと IAM ロールの設定は、Terraform でコードとして管理することを強く推奨します。

Terraform 管理のメリット：

設定の変更履歴が Git で管理される
プルリクエストによるレビュープロセスを経られる
terraform plan で意図しない変更を事前に検出できる
複数の AWS アカウント（dev/staging/prod）への一貫したデプロイが可能
セキュリティ監査時に設定の根拠を説明しやすい

管理すべきリソース：

aws_iam_openid_connect_provider（GitHub OIDC プロバイダー）
aws_iam_role（用途別 IAM ロール）
aws_iam_role_policy または aws_iam_role_policy_attachment（最小権限ポリシー）

8. gitleaks による既存リポジトリのシークレット確認

OIDC に移行する前に、既存リポジトリの全コミット歴史にシークレットが混入していないかを確認します。T-Connect 事案が示したように、過去のコミットに混入したシークレットは現在のコードを見ても発見できません。

"Want to learn more about the problem of hardcoded credentials? Read our State of Secrets Sprawl 2023 report or request a complimentary audit of your secrets exposure."
— GitGuardian Blog [6]
https://blog.gitguardian.com/toyota-accidently-exposed-a-secret-key-publicly-on-github-for-five-years/

gitleaks は detect モードで全コミット歴史を走査し、protect モードで pre-commit フックとして機能します。CI/CD の pre-commit チェックとして組み込むことで、「コミット前の最後の防衛線」を自動化できます。

9. 実装チェックリスト

GitHub Actions × AWS OIDC 実装チェックリスト：

【AWS 側の設定】
  ✅ GitHub OIDC プロバイダーを IAM に登録（AWS アカウントに1回）
  ✅ 用途別（CI / ステージング / 本番）で IAM ロールを分離
  ✅ トラストポリシーの sub 条件で許可するリポジトリ/ブランチを明示
  ✅ IAM ロールの権限は必要最小限のみ（リソース ARN を具体的に指定）
  ✅ 2026年7月以降の新リポジトリは Immutable Subject Claims を有効化
  ✅ OIDCプロバイダーとIAMロールを Terraform でコード管理

【GitHub Actions ワークフローの設定】
  ✅ `permissions: id-token: write` を明示的に追加
  ✅ `aws-actions/configure-aws-credentials@v4` を使用
  ✅ `role-to-assume` に IAM ロール ARN を指定
  ✅ `role-session-name` に `run_id` を含める（CloudTrail 追跡用）
  ✅ GitHub Environments で本番デプロイに承認フローを設定

【移行と廃止】
  ✅ OIDC 移行後、GitHub Secrets の AWS キーを削除
  ✅ IAM ユーザーのアクセスキーを無効化→動作確認→削除の順で廃止
  ✅ 不要な IAM ユーザー自体を削除

【監視】
  ✅ CloudTrail で AssumeRoleWithWebIdentity を記録・監視
  ✅ EventBridge で想定外のロール引き受けにアラートを設定
  ✅ gitleaks を pre-commit フックと CI/CD に導入

【やってはいけないこと】
  ❌ トラストポリシーの sub 条件に `*` を使う（全リポジトリを許可してしまう）
  ❌ `ForAllValues:StringLike` を Allow 条件に使う（バイパスのリスクあり）
  ❌ OIDC 移行後も旧アクセスキーを残す（移行後は必ず削除）
  ❌ 1つのロールにすべての権限を集約（爆発半径が大きくなる）

10. まとめ——「キーを作らない」という設計哲学

トヨタT-Connect事案が示したのは「作成したアクセスキーは必ずどこかに存在し続け、気づかれないまま使われ続けるリスクがある」という事実です。CircleCI事案が示したのは「信頼したCI/CDプラットフォーム自体が侵害された場合、保存していたシークレットはすべて流出する」という現実です。

どちらの問題も、そもそもアクセスキーを生成・保存しない設計に移行すれば根本から解決できます。

"OpenID Connect eliminates long-lived CI/CD credentials at the architectural level."
— Parsectix [13]
https://parsectix.com/insights/github-actions-oidc-aws-integration/

OIDC への移行は、Terraform を使えば AWS 側の設定が30分、GitHub Actions ワークフローの変更が数行で完了します。移行後は「キーのローテーション」「キーの定期監査」「CircleCI 漏洩時の緊急対応」——これらの運用コストがゼロになります。

CircleCI 自身が事案後のレポートでこのように述べています。

"We plan to make it simpler and more convenient for our customers to create and maintain highly secure pipelines — including OIDC and IP ranges — enabling every advantage of the cloud while smartly managing risk."
— CircleCI, "Jan-4-2023 Incident Report" [2]
https://circleci.com/blog/jan-4-2023-incident-report

「今日から始められる最も費用対効果の高いセキュリティ改善」——それが AWS OIDC 移行です。

参考文献

[1] NHIMG. "Toyota Breach." 2022.
https://nhimg.org/toyota-breach

[2] CircleCI. "CircleCI incident report for January 4, 2023 security incident." January 13, 2023.
https://circleci.com/blog/jan-4-2023-incident-report

[3] BleepingComputer. "Toyota discloses data leak after access key exposed on GitHub." October 10, 2022.
https://www.bleepingcomputer.com/news/security/toyota-discloses-data-leak-after-access-key-exposed-on-github/

[4] CSHub. "Location data of 2 million customers exposed in Toyota data breach." 2023.
https://www.cshub.com/attacks/news/location-data-of-2-million-customers-exposed-in-toyota-data-breach

[5] SiliconANGLE. "Toyota warns of possible data theft after access key left exposed on GitHub." October 12, 2022.
https://siliconangle.com/2022/10/11/toyota-warns-possible-data-theft-access-key-left-exposed-github/

[6] GitGuardian Blog. "Toyota Accidentally Exposed a Secret Key Publicly on GitHub for Five Years." October 2022.
https://blog.gitguardian.com/toyota-accidently-exposed-a-secret-key-publicly-on-github-for-five-years/

[7] CircleCI. "January 4, 2023 Security Alert." January 4, 2023.
https://circleci.com/blog/january-4-2023-security-alert/

[8] NHIMG. "CircleCI Breach." January 2023.
https://nhimg.org/circleci-breach

[9] CircleCI Support Center. "Rotating Secrets for January 4th Incident." January 2023.
https://support.circleci.com/hc/en-us/articles/11816211460891-Rotating-Secrets-for-January-4th-Incident

[10] Security Boulevard. "CircleCI Rotates GitHub OAuth Tokens After Security Incident." January 10, 2023.
https://securityboulevard.com/2023/01/circleci-rotates-github-oauth-tokens-after-security-incident/

[11] GitHub Docs. "Configuring OpenID Connect in Amazon Web Services."
https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services

[12] freeCodeCamp. "How to Set Up OpenID Connect (OIDC) in GitHub Actions for AWS." April 29, 2026.
https://www.freecodecamp.org/news/how-to-set-up-openid-connect-oidc-in-github-actions-for-aws/

[13] Parsectix. "GitHub Actions and OIDC Integration with AWS: Why It Matters and How It Works." February 9, 2026.
https://parsectix.com/insights/github-actions-oidc-aws-integration/

[14] Alok. "GitHub Actions OIDC: Eliminating Long-Lived Credentials from Your CI/CD Pipeline." July 2026.
https://aloknecessary.github.io/blogs/github-actions-oidc/

[15] Firefly. "Integrating OIDC with GitHub Actions for Terraform on AWS."
https://www.firefly.ai/academy/integrating-oidc-with-github-action-to-manage-terraform-deployment-on-aws

[16] OneUptime. "How to Configure OIDC for AWS in GitHub Actions." January 25, 2026.
https://oneuptime.com/blog/post/2026-01-25-github-actions-oidc-aws/view

[17] aws-actions. "configure-aws-credentials — Configure AWS credential environment variables for use in other GitHub Actions." GitHub.
https://github.com/aws-actions/configure-aws-credentials

[18] SecurityWeek. "Toyota Discloses Data Breach Impacting Source Code, Customer Email Addresses." October 11, 2022.
https://www.securityweek.com/toyota-discloses-data-breach-impacting-source-code-customer-email-addresses/

[19] Malwarebytes. "CircleCI: Malware stole GitHub OAuth keys, bypassing 2FA." January 17, 2023.
https://www.malwarebytes.com/blog/news/2023/01/circleci-malware-stole-github-oauth-keys-bypassing-2fa

[20] AppOmni. "Unpacking (and Preventing) the CircleCI Data Breach." January 2023.
https://appomni.com/ao-labs/unpacking-preventing-circleci-data-breach/