ゲーム開発の安全性を高める第一歩〜Snyk導入のすすめ〜 #Snyk
おはようございます( ◜◡◝ )
ゲームソリューション部／業務効率化ソリューション部のきだぱんです。
本ブログはClassmethod SaaSで加速するゲーム開発 Advent Calendar 2025の3日目のブログとなります！ 以下のブログも併せてご覧下さい！
さて今回はSnykです！
最高に面白いゲームを作るために、クリエイターやエンジニアはギリギリまで調整を続けます。しかし、その一方で重みを増しているのが「セキュリティ」の課題です。
オンライン機能が当たり前となり、マイクロサービスやコンテナ技術を活用したバックエンド基盤が複雑化する中で、開発スピードを落とさずにどうやって安全性を担保するか。これは多くの技術責任者が抱える課題かと思います。
ゲーム業界においては、Unity や Sky Betting & Gaming においてSnykをご採用いただいています。
下記はUnityのシニアセキュリティソフトウェアエンジニアのシモ・プンノネン（Simo Punnonen）様からのコメントです。
「Snyk と仕事をした経験は素晴らしいものでした。当社のエコシステムにツールを導入する場合、エンドユーザーエクスペリエンスがシンプルであることが最も重要です。ドキュメントは整備されていますし、統一されたエクスペリエンスを共有できるので、スムーズに Snykの利用を開始できましたし、チーム間での重複作業を避けることができました。」
https://prtimes.jp/main/html/rd/p/000000025.000092857.htmlより
2021年Log4j
時計の針を少し戻しましょう。
2021年末、世界中のIT現場を震撼させた「Log4j」の脆弱性問題。
あるゲーム開発会社もまた、その対応に追われていました。
当時、彼らはコードやライブラリの管理を、プロジェクトごとの属人的な手法や、表計算ソフトでの管理に頼っていました。
そのため、脆弱性が発覚した際、「自社のどのタイトルの、どのサーバーに、問題のライブラリが含まれているか」を即座に特定することが困難でした。結果として、エンジニアたちは膨大なコードベースを目視で確認し、手動で対応するという、途方もない労力を払うことになったのです。
参照
4つの領域を「ひとつ」で守る
現代のゲーム開発は、クライアントサイドのコードを書くだけでは完結しません。
オープンソースライブラリ（OSS）を組み合わせ、コンテナでサーバーを構築し、IaC（Infrastructure as Code）でインフラを管理するこれらすべてが開発のスコープです。
しかし、多くの現場では、コード解析（SAST）、ライブラリ管理（SCA）、コンテナ診断、インフラ設定診断のために、それぞれ別のツールを導入してしまうこともあるかと思います。
Snykが選ばれる大きな理由の一つは、これら「Code」「Open Source」「Container」「IaC」という4つの主要な領域を、たった一つのプラットフォームでカバーできる点にあります。
開発者はあちこちのツールを行き来する必要がなく、セキュリティ担当者は全体のリスクを一元的に把握できる。この「統合された視点」こそが、複雑化するゲーム基盤を守る鍵となります。
「開発者の邪魔をしない」という絶対条件
しかし、どれほど高機能なセキュリティツールであっても、現場のエンジニアに使われなければ意味がありません。
特にクリエイティブな集中力が求められるゲーム開発において、動作が遅かったり、誤検知ばかりで作業を中断させるようなツールは、すぐに敬遠されてしまいます。
Snykは、エンジニアが普段使い慣れているIDEにシームレスに統合されます。
コードを書いているその瞬間に、「ここに脆弱性があります」と教えてくれるだけでなく、「こう書き換えれば直ります」という修正案まで提示してくれます。
Snykが開発現場で使われる主要な言語をカバーしています。
| 言語 / 技術 | Snyk Code (静的解析) |
Snyk Open Source (OSS) |
|---|---|---|
| C++ | ◎ | ◎ |
| Go | ◎ | ◎ |
| Python | ◎ | ◎ |
| Java / Kotlin | ◎ | ◎ |
| JavaScript | ◎ | ◎ |
Snykでスキャンしてみる
CLIでスキャンさせてみます。
まずはSnykのCLIツールをインストールします。
brew install snyk
インストールが終わったら、認証を行います。
snyk auth
これを実行するとブラウザが立ち上がり、Snykアカウント（GitHubやGoogleアカウントで無料作成可能）との連携が完了します。これだけで準備は整いました。
ライブラリの脆弱性をチェック (Snyk Open Source)
プロジェクトのルートディレクトリ（package.json などがある場所）に移動し、以下のコマンドを打ち込みます。
snyk test
プロジェクトが依存しているオープンソースライブラリの解析が始まります。結果がズラリと表示されます。
Testing /Users/.../..../.../..........
Tested 925 dependencies for known issues, found 113 issues, 298 vulnerable paths.
Issues to fix by upgrading:
Upgrade body-parser@1.19.1 to body-parser@1.20.3 to fix
✗ Asymmetric Resource Consumption (Amplification) [High Severity][https://security.snyk.io/vuln/SNYK-JS-BODYPARSER-7926860] in body-parser@1.19.1
introduced by body-parser@1.19.1 and 1 other path(s)
✗ Prototype Poisoning [High Severity][https://security.snyk.io/vuln/SNYK-JS-QS-3153490] in qs@6.9.6
introduced by body-parser@1.19.1 > qs@6.9.6 and 2 other path(s)
.
.
License issues:
✗ GPL-2.0 license [High Severity][https://snyk.io/vuln/snyk:lic:npm:fuzzball:GPL-2.0] in fuzzball@1.4.0
introduced by fuzzball@1.4.0
Organization: kidapan
- 何が見つかったか: 脆弱性の深刻度（Critical, High, Medium, Low）
- どこにあるか: どのライブラリが原因か（依存関係のツリー）
- どう直すべきか: 「バージョンX.X.Xにアップグレードすれば修正されます」という具体的なアドバイス
「脆弱性がある」と指摘されるだけでなく、「どうすれば直るか」まで教えてくれるのがSnykの大きな特徴です。
コードの品質をチェック (Snyk Code)
次に、自分たちが書いたソースコードのセキュリティ上の不備をチェックしてみましょう。
snyk code test
Testing /.../.../.../... ...
Open Issues
✗ [LOW] Use of Hardcoded Passwords
Path: test/api/userApiSpec.js, line 216
Info: Do not hardcode passwords in code. Found hardcoded password used in password.
✗ [LOW] Improper Type Validation
Path: routes/profileImageUrlUpload.js, line 27
Info: The type of this object, coming from body and the value of its split property can be controlled by the user. An attacker may craft the properties of the object to crash the application or bypass its logic. Consider checking the type of the object.
.
.
╭──────────────────────────────────╮
│ Test Summary │
│ │
│ Organization: kidapan │
│ Test type: Static code analysis │
│ Project path: /Users/kida.maiko/Documents/juice-shop-test │
│ │
│ Total issues: 211 │
│ Ignored issues: 0 [ 0 HIGH 0 MEDIUM 0 LOW ] │
│ Open issues: 211 [ 22 HIGH 19 MEDIUM 170 LOW ] │
╰──────────────────────────────────╯
💡 Tip
To view ignored issues, use the --include-ignores option.
他にもスキャン方法はあります！
ここでは基本となるCLIを紹介しましたが、実際の開発フローでは IDEプラグイン（VS Code, Visual Studio, IntelliJなど） を入れ、コードを書いている最中にリアルタイムで波線が表示され、その場で修正が可能になります。
また、GitHub / GitLab連携 を行えば、プルリクエストのたびに自動でスキャンが走り、脆弱なコードの混入を未然にブロックすることも可能です。
おわりに
Snykは、開発者の足を止めることなく、むしろその背中を押してくれるパートナーです。
過去のような混乱を二度と繰り返さないために、そして、世界中のプレイヤーに安心して楽しんでもらうために。今こそ、ゲーム開発の現場にSnykという選択肢を取り入れてみてはいかがでしょうか。
Snykに関するブログも沢山展開されていますので、是非こちらもご覧ください。
この記事がどなたかのお役に立てば幸いです。
以上、きだぱんでした。
