こんにちは、アンドパッドセキュリティチームの小野寺です。
近年、ソフトウェア開発のエコシステムを狙ったソフトウェアサプライチェーン攻撃が大きな脅威となっており、開発環境や CI/CD パイプラインにおけるセキュリティの強化が急務となっています。
アンドパッドでは、以前のブログでご紹介した EDR によるサプライチェーン攻撃対策とあわせて、より多層的な防御策の導入を進めています。
本記事では、弊社が直近で取り組んだソフトウェアサプライチェーン攻撃に対する具体的な対策について、実践的なアプローチと実運用にのせる上での工夫や課題を交えてご紹介します。
Takumi Guard の導入
Takumi Guard は GMO Flatt Security 社が提供する、悪意のあるパッケージをブロックするレジストリプロキシです。
アンドパッドでは Takumi Guard を以下の方法で利用しています。
- 開発者端末全台に Takumi Guard のプロキシを設定
- Node.js のパッケージもしくは Python ライブラリをインストールする GitHub Actions で、Takumi Guard をレジストリプロキシに設定
- 2026年4月22日に RubyGems にも対応されたため、追加で対応を検討しています！
EDR によるサプライチェーン攻撃対策とあわせて、ソフトウェアサプライチェーン攻撃の入り口となりやすい開発者端末への悪意あるパッケージの混入を防いでいます。 加えて、攻撃対象となりやすい CI/CD パイプラインへ Takumi Guard を導入し、サプライチェーン全体のセキュリティ強化を図っています。
既に多くの開発者の方がブログで触れられているため、機能や導入手順の詳細なご紹介は割愛しますが、導入の容易さが考慮された設計となっていることもあり、アンドパッドでも大きな問題が発生することなく、スムーズに開発サイクルへ組み込むことができました。
その中でも、実運用にのせる上でいくつか注意が必要な事項がありましたので、この場でご紹介します。
GitHub Copilot Coding Agent の Firewall に Custom allow list が必要となる場合がある
GitHub Copilot Coding Agent を利用している開発組織も多いと思いますが、その場合には注意が必要です。GitHub Copilot Coding Agent は既定で Firewall が構成されており、有効になっている許可リスト以外への通信はブロックされます。
そのため、以下の条件に合致する場合には、GitHub Copilot Coding Agent から *.flatt.tech レジストリへの通信が弾かれてしまいます。
- リポジトリの
.npmrcに*.flatt.techレジストリが追加されている - GitHub Copilot Coding Agent がパッケージのインストールを伴う作業を実施する
上記のようなケースでは、個別に GitHub Copilot Coding Agent の Custom allow list に *.flatt.tech を追加する必要があります。
導入時点では、この Custom allow list はリポジトリ単位で個別に設定をする必要がありました。
しかし、2026年4月のアップデートにより Organization レベルで設定ができるようになり、リポジトリごとの設定の手間は不要になっています。
他のジョブによって .npmrc がコミットされてしまう
GitHub Actions で Takumi Guard をレジストリプロキシに設定するステップを追加した場合、同一ワークフローの後続ステップによって .npmrc の変更が自動コミットされてしまうケースがありました。
弊社では GitHub にコードを push すると、自動でコード整形（フォーマット）およびコミットを行う CI を利用しています。このステップの前に Takumi Guard を設定する処理を追加したところ、書き換えられた .npmrc まで一緒に自動コミットされてしまう事象が発生しました。
これを避けるために、npm install 実行後に明示的に git checkout -- .npmrc のステップを追加し、.npmrc の変更を元に戻すことで自動コミットを回避可能です。
利用方法に応じたレートリミット
Takumi Guard は、利用方法（匿名利用や認証利用など）によって複数のレートリミットが設定されています。それぞれの値については以下をご参照ください。
弊社では直近のサプライチェーン攻撃への対策として、決定から開発者端末への導入までを短期間で実施したため、一部の環境・ユーザーにおいてレートリミットに達してしまうケースが発生しました。
特に「匿名利用」の場合、制限単位が IP アドレス単位となります。そのため、オフィス出社時など複数人が同一のグローバル IP を利用する環境下では、匿名利用モードではなく、メール認証を行うなどレートリミットを意識した導入方法の検討が必要になると考えます。
現在は、よりレートリミットの閾値が高い組織ユーザートークンや Bot トークンでの導入も可能になっているため、そちらの利用を検討いただくのがおすすめです。
以上、組織や開発環境単位で大規模に導入するにあたって、気を付けていただくと良い点を紹介しました。
現在は、組織単位での感染可能性の通知など、集中管理を意識した様々な機能のリリースが発表されています。今後もセキュアな開発環境の構築に向けて、継続的に改善していきます。
外部 Action の SHA 固定による不変性の担保
GitHub Actions で外部 Action を利用する際、タグ指定ではなく SHA で固定することが公式ドキュメントで推奨されています。 SHA 固定が推奨される理由は以下の通りです。
- 参照している外部 Action が侵害された場合、タグはそのままで悪意のあるコードに差し替えられるリスクがある
- Git のタグは後から別のコミットに付け替え可能
- Immutable-releases を利用したタグは除く
- SHA は不変（変更不可能）なため特定コミットを確実に参照し、意図しないコードの混入を防ぐことが可能
社内のワークフローの SHA 固定状況にバラツキがあったため、全てのワークフローで SHA 固定する対応を実施しました。
SHA 固定への書き換えはルールが明確なため自動化と相性が良く、pinact 等のツールを使うことで大きな問題なく対応が可能でした。
併せて今後のワークフロー追加・変更に対応するため、Enforce SHA Pinningの利用を検討しました。Enforce SHA Pinning は Organization、リポジトリレベルで SHA 固定を強制できる機能です。
この機能は自分たちのワークフローだけでなく、使用している外部 Action で呼び出されている Action も含め、依存先を再帰的にチェックします。そのため、コントロール外のところでエラーが発生する可能性があり、今回の短期対策では使用を見送りました。
外部 Action で SHA 固定されていない箇所があると、そこから侵害の影響を受ける可能性があるため、外部 Action を精査して Enforce SHA Pinning を有効化したいと考えています。
GitHub Actions の permissions 最小化
GitHub Actions では permissions を明示的に指定することで、GITHUB_TOKEN に付与される権限を最小に絞ることが可能です。
公式ドキュメントでも最小限の権限を付与することが推奨されています。権限の最小化によりサプライチェーン攻撃を防ぐことはできませんが、万が一ワークフローが侵害された場合に被害を最小限に抑えるためにも重要な対策となります。
2023年2月から Read repository contents permission がデフォルトになりましたが、それ以前に作成された Organization、リポジトリでは Read and write permissions がデフォルトになっています。
弊社の Organization は上記変更以前から存在しているため Read and write permissions が設定されており、permissions が明示的に指定されていないワークフローも存在することから、全ワークフローに permissions を追加しました。
AIエージェントを活用した対応
SHA 固定の対応では pinact を使用することで自動的に修正できました。
一方、permissions の最小化では、必要な権限をワークフローの記述だけで判断できず、利用している Action のソースコードや GitHub API のドキュメントまで確認して初めて明らかになるケースも多く、同様の自動化は困難でした。自動化ツールも存在しますが、対応している Action のカバレッジに限界があります。
そこで、AIエージェントを活用した permissions 指定を併用することにしました。ワークフローファイルを読み込ませ、外部 Action のソースコードや GitHub API のドキュメントを参照しながら各ステップに必要な権限を推定させることで、人手で行う場合と比べて大幅に効率よく対応できました。また、contents: read をデフォルトとし、それ以上の権限が必要な場合のみ明示するという方針をあらかじめ与えることで、必要最小限の権限のみを付与するようにしています。
まとめ
今回は、アンドパッドでのサプライチェーン攻撃対策の取り組みについて紹介しました。 攻撃が活発に行われているエコシステムを対象に、開発チームへの負担を抑えながら実施できる優先度の高い対策から着手しました。
今回の対策はあくまで出発点であり、今後継続して侵害の予防・早期検知・迅速な対応の強化に取り組んでいく予定です。 具体的には、より広範なエコシステムへの対応、CI/CD の外部通信の制御・ログの可視化等を検討しています。
サプライチェーン攻撃は特定の組織だけの問題ではなく、ソフトウェア開発全体に関わるリスクです。本記事が、同様の課題に取り組むエンジニアの参考になれば幸いです。
We are hiring!
セキュリティチームでは、ANDPADのセキュリティをより強固なものにする仲間を募集しています！少しでも興味を持った方は以下採用ページをご確認ください。
