【開発生産性カンファレンス 2025】開発スピードを落とさず、脆弱性に向き合う ─ Snyk導入で実現したセキュリティと開発生産性の両立

第1部：Snyk導入の意思決定と背景

松下：こんにちは、クレディセゾンの松下です。私はソフトウェアアーキテクトとして、主にレガシーアプリケーションのクラウドリフトや横断的な共通基盤の構築を担当しています。5年前にSI系の会社からクレディセゾンに転職し、組織の成長とともにセキュリティ要件の変化を肌で感じてきました。

私たちが所属するエンタープライズ開発センターは、もともと「テクノロジーセンター」という名前で2019年にCTO直下の小さなチームとして発足しました。当初は転職組のシニアプログラマーのみで構成され、マネージャーもいないフラットな組織でした。そこから段階的に組織を拡大し、内部人材の教育によるプログラマー育成、転職組の増加、新卒採用を進めながら、現在のエンタープライズ開発センターとして分離・発展してきました。

最初は比較的チャレンジングなサービスやアプリケーションの開発が中心でしたが、組織が大きくなるにつれて、より重要な業務システム、特にクレジットカード番号を扱うような機密性の高いシステムの内製化も手がけるようになりました。



2024年度の半ばから、私たちはSnykを67のリポジトリで継続利用しています。モノレポを含む大規模プロジェクトも多いため、実際のコード量としてはかなりの規模になります。

Snyk導入に至った背景には、組織拡大に伴う課題がありました。まず、組織が大きくなることで仕組みの改善が求められるようになりました。また、クレジットカード業界で必須のPCI DSS準拠プロセスへの対応も必要でした。

セキュリティ対策といっても、対象となる領域は多岐にわたります。プロセス横断的な課題もあれば、インフラ面ではコンテナの脆弱性、アプリケーション層では実装上の脆弱性、使用するライブラリの脆弱性、さらにクラウドの設定に関わる問題もあります。

何より大きな課題だったのは、セキュリティの強化と開発スピードの維持という、一見矛盾した要件を両立させる必要があったことです。私たちの存在意義は、既存のベンダーに負けない開発スピードにあります。社内からも「スピードが速いから面白いよね」という評価を受けていたため、セキュリティ要件が厳しくなっても開発スピードは落としたくありませんでした。

また、1人ひとりがセキュリティを自分事として考えてほしいという思いもありました。他の部署に任せるのではなく、開発者自身がセキュリティ意識を持って取り組める環境を作りたかったのです。



様々なセキュリティツールを検討する中で、最終的にSnykを選んだ理由は、開発者目線での設計思想にありました。他のツールは統制的な目線で作られているものが多く、開発者にとって使いにくいと感じることがありました。

Snykの場合、IDEとの連携機能、GitHubとのスムーズな統合、直感的に操作できるWebベースのUIなど、開発者が日常的に使いやすい設計になっていました。特に印象的だったのは、脆弱性について学べるコンテンツへ直接リンクで飛べる機能です。これは単に脆弱性を指摘するだけでなく、開発者の学習を支援する思想の表れだと感じました。

Snykの導入により、私たちはDevSecOpsとShift Leftを実現できました。開発から運用まで全フェーズでセキュリティを組み込み、できるだけ初期段階でセキュリティの設計やチェックを取り込むアプローチです。

結果として、適切な運用を行えば自動的にPCI DSS準拠を実現できるようになりました。これは業界のベストプラクティスを導入することで得られた大きなメリットです。

何より重要だったのは、Snykが「開発者を縛るのではなく、開発者がセキュアな開発をすることを支援・促進する」という思想を持っていたことです。これは私たちの組織文化と非常によくマッチしました。

正直に言うと、Snykは決して安価なツールではありません。しかし、開発プロセスツールの将来を考えると、必要な投資だと判断しました。

ライブラリやフレームワークの発展により、開発者1人ひとりの生産性は確実に向上しています。今後は人海戦術ではなく、少数精鋭で開発していくスタイルが主流になるでしょう。私たちもその方向を目指しており、セキュリティは必須の要件です。

開発者個人の生産性を最大化するツールとして、Snykは非常に有効だと実感しています。導入から現在まで継続して使用していますが、時間的に厳しいプロジェクトでも、Snykによるセキュリティチェックは確実に実行できており、安心感を得ています。

第2部：Snykの実践的活用とその効果

氏原：私は2020年12月にクレディセゾンに入社し、現在は課長とエンジニアを兼務しています。最近はマネージャー業務をしながらも、実際にコードを書く作業も続けています。

今回お話しする内容は、大きく4つに分けて構成しています。まず私たちの組織と取り組みについて、そして「なぜ脆弱性対応をするのか」という根本的な問題、実際に発生した課題とSnykを使ったアプローチ、最後にSnykの便利な機能をご紹介したいと思います。

私たちを象徴する言葉として「伴走型内製開発」があります。これは、作る側と望む側が完全に融合した開発スタイルです。



具体的には、ユーザーと非常に密接に連携して開発を進めています。例えば、週に1回、5時間程度の長時間打ち合わせを行うこともあります。ITの知識が全くない業務側の方々と、どんどん仕様をすり合わせながらシステムを作っていくというアプローチです。

なんで、脆弱性対応するの？

まず最初に、根本的な問いに答えたいと思います。なぜ脆弱性対応をするのか。これを一言でまとめると、「自分と自分の組織の信頼と事業継続を守るため」です。

昨今、生成AIの発展により、私たちを取り巻く脅威環境は大きく変化しています。このイベントでも生成AIを使った開発生産性向上の話が多く出ていますが、同時に生成AIを使った脆弱性への攻撃も激しくなってきているのが現実です。

日本においても、このリスクに対する認知が急速に拡大しています。IPA（情報処理推進機構）の「情報セキュリティ10大脅威2025」では、生成AI悪用が新たな重点テーマとして取り上げられました。

発生した課題とSnykを使用したアプローチ

実際に私たちの組織で発生していた課題をお話しします。まず、「脆弱性対応って何するの？」という根本的な問題がありました。

組織内でよくあったのが、こんなやりとりです。「システムAの対応なんですが、このXXの脆弱性の対応ってどうすればよいですか？」という質問が飛んできて、それに対して「XXは、YYは、ZZは......」と次々に質問が続く状況でした。

この背景には大きく3つの課題がありました。1つ目は、脆弱性対応をしたことがなく、やり方も何もわからないという知識・経験不足の問題。2つ目は、「じゃあ、わかる人に聞けば良いじゃん？」となっても、やったことがなければやり方もわからないことがあるという構造的な問題。そして3つ目は、できる人に対応が集中してしまい、どうにかしたい、標準化もしたいという組織的な課題でした。

これらの課題に対して、Snykは非常に体系的なアプローチを提供してくれました。大きく3つの観点で解決策を整理できます。

まず、「対応は何したらいいの？」という問題です。Snykでは、GitHubのリポジトリをインポートしたときに脆弱性が発見されると、画面上に明確に表示されます。例えば、Springフレームワークの脆弱性が見つかった場合、「これにしたらいいよ」という具体的な推奨バージョンが示されます。



さらに素晴らしいのは、右上のボタンを押すだけで、GitHubにプルリクエストを自動生成してくれることです。多くの方がやられていると思いますが、プルリクエストが出されたら自動的にテストが流れるようにしておけば、テストが通ってOKならそのままマージできるという、非常に効率的なフローが構築できます。

次に、「脆弱性を利用されたら何が起きるの？」という学習面の課題です。Snykの優秀な点は、単に脆弱性を指摘するだけでなく、豊富な学習コンテンツを提供していることです。

Snykでは、発見した脆弱性がどのようなものなのかを調査した詳細情報や、。この脆弱性の攻撃方法や分析結果を確認することができます。

例えば、SQLインジェクションについても、入力フォームにdrop table文を仕込むことでシステムを壊せるという具体的な解説が載っています。こうした教育コンテンツとして、Snykは非常に有用だと感じています。



最後に、「対応方針をどうしたらいいの？」という課題です。

従来はCVSSスコアの深刻度（Critical、High、Medium、Low）をベースに対応していることが多いと思いますが、それだとCriticalやHighが多すぎて、実は対応しなくても良さそうなものまで含まれてしまいます。

Snykが提供するプライオリティスコアとリスクスコアは、この判断を大幅に改善してくれます。面白い指標の一つに「ソーシャルトレンド」があります。これは、Xでエンジニアがどれだけ騒いでいるかを指標にしてリスクを評価するものです。

また、システム自体にどれだけのビジネスインパクトがあるのかを設定できます。クレジットカードのシステムであれば、攻撃されたら本当にまずいので、最高レベルに設定しておくことで、リスクスコアが上昇し、適切な対応方針を決められます。

さらに、「インサイト」機能では、「このような環境であれば、その脆弱性については悪用されない」といった具体的な判断材料も提供されます。これらの情報をベースに、組織として「CVSSがCriticalかつリスクスコアがこの数値だったら2週間以内に対応する」といった明確な指標を策定できるようになりました。



結果として、脆弱性を直す対応についてはSnykでプルリクエストが出せるようになり、どう直したら良いかも詳細に書かれています。悪用されたときの被害や影響範囲、作業者の教育については、Snykが提供しているコンテンツが優秀で、学びながら脆弱性対応ができるようになりました。

対応方針についても、様々なリスクを加味した上で、Snykがその判断材料を作ってくれるので、それをベースに組織でどうやって対応していくかというルールを決めることができます。

Snykのこれ便利！

ここからは、実際にSnykを使ってみて「これは便利だ！」と感じた機能をご紹介します。

まず最初にご紹介したいのが、自動プルリクエスト機能です。脆弱性が発見されたときに、Snykが自動的にプルリクエストを作成してくれます。先ほども触れましたが、これが本当に運用者にとっても開発者にとっても楽な機能です。



自動的にテストが流れるようになっていれば、テストが通った段階でそのままマージまで完了してしまいます。人的な作業を最小限に抑えながら、確実にセキュリティ対応ができるという点で、非常に価値の高い機能だと思います。

次に、IDEプラグインの存在です。先ほどからWeb画面をお見せしていましたが、IntelliJやVS Codeなどにも組み込めるプラグインがあります。

開発中に「こんな感じに直したらいいよ」というサジェストを出してくれるので、開発フローを止めることなく、セキュアなコードを書き続けることができます。私自身も日常的に使っていますが、非常に使いやすいと感じています。



3つ目は、プルリクエストのステータスチェック機能です。昨今、生成AIに「こんな感じの機能を作りたい」と聞くと、「このライブラリを入れたらいいよ」という回答や、ググって見つけた記事を参照してライブラリを導入することがあると思います。

そうした際に、脆弱性のあるライブラリや、脆弱性のあるバージョンを仕込んでしまうことが起こり得ます。プルリクエスト時にステータスチェックを行うことで、「この脆弱性のあるバージョンが含まれているよ」というアラートを出してくれます。これにより、開発中にもセキュリティを高めることができる、まさにDevSecOpsな使い方ができます。



4つ目は、依存関係がいい感じに表示される機能です。大規模なプロジェクトになっていくと、Springが依存しているライブラリ、さらにその先が依存しているライブラリと、どんどん複雑になって管理できなくなります。

Snykでは、そのシステムが依存しているライブラリを検索できます。例えば「Spring」で検索すると、どういうライブラリが使われているのかが一覧で表示されます。

特に便利なのが、プロジェクトを横断しての検索機能です。例えば、数年前に騒がれたlog4Jのような問題が発生した場合、Snykにプロジェクトを一括してインポートしておけば、「log4J」で検索することで対象のシステムを瞬時に特定できます。

従来であれば、セキュリティ部門から「log4Jを使っているシステムを調べてください」というメールやSlackが一斉配信され、各チームが手動で確認する必要がありました。しかし、Snykがあれば、そうした非効率的なプロセスを省くことができます。これは非常に楽だと感じています。



最後に、Dockerのベースイメージ比較です。これは少し忘れがちな部分ですが、やっておくと良い機能の一つです。

実は、アルファ版の段階では「使えないな」と思っていた機能もあったのですが、Snykのアップデートは結構頻繁で、使bえないと思っていた機能についても即座に対応してもらえました。これは個人的には非常に嬉しい体験でした。

第3部：まとめ

今回の発表を通してお伝えしたかったのは、開発・運用プロセスにセキュリティ対策を組み込んで、対応を当たり前にすることの重要性です。

問題が起こってから対応するのでは遅すぎます。特に生成AI時代においては、なおさら早い対応と標準化が求められています。攻撃者側が生成AIを使って攻撃手法を自動化・高速化している以上、防御側も同じスピードで対応していかなければなりません。

Snykを使うことで、セキュリティ・脆弱性対策を誰でも対応できる知識として組織に根付かせることができました。対応するだけではなく、対応する過程で学習もできるというのが、特に価値の高いポイントだと感じています。

私の場合、マネージャーから見ても、開発者視点で見ても、対応する中で学習できるコンテンツが豊富に用意されているので、各個人で自立的に対応してもらえるようになりました。これにより、特定の人に知識が集中するという課題も解決できています。

最終的に、なぜ脆弱性対応をするのかという最初の問いに戻りますが、やはり「自分と自分の組織の信頼と事業継続を守るため」です。

脆弱性が発生すること自体は避けられません。しかし、脆弱性が発見されたときに、どれだけ早くアプローチできるか、標準化されたプロセスで組織として無理のない形で対応できるかどうか。これによって、今後の戦略やビジネスのスピードに大きな影響が出てくると思います。

参加者の皆さんも、自分でシステムを作っている方、納品している方、SESでいろんなところに行っている方など、様々な立場があると思います。どのような立場であっても、自分の価値としてセキュリティ対策をしっかりしていくということを心に留めておいていただけると、私は非常に嬉しく思います。

私たちクレディセゾンでは、開発仲間を募集中です！今日お話しした内容に興味を持っていただいた方、一緒にセキュアで高速な開発に取り組んでみたいという方は、ぜひお声がけください。ご清聴ありがとうございました。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です