この記事は Hacobu Advent Calendar 2025 の 7日目の記事です。
1. はじめに
こんにちは。Hacobuでバックエンドエンジニアをしているichisukeです。
Hacobuでは今年からプロダクトセキュリティWGを立ち上げて活動をしています。
活動開始から半年が経ったので、これまでの取り組みを振り返り、得られた成果と今後の課題を紹介します。
2. なぜプロダクトセキュリティWGを立ち上げたのか
物流DX企業として成長を続けるHacobuでは、お客様の成長や満足度向上に直結する施策を日々開発しリリースしています。それと同時に、お客様の重要なデータを扱う責任が日々増しています。
昨今はサプライチェーン攻撃も増加しており、お客様の大切なデータを守り信頼を維持していくことが必要不可欠となっています。
しかし、組織には専任のセキュリティチームがなく、各チームがそれぞれ対応していたため、脆弱性対応の優先度付けや運用が属人的になり、対応スピードや判断基準にばらつきが出ていました。
そこで、「プロダクト開発とセキュリティ対策の両輪を回せる状態にする」ために、組織横断でプロダクトセキュリティWGを立ち上げました。
3. WGの活動の記録
3.1 ベースラインの決定とツール選定
私を含む数名で活動を開始し、まずは現状を把握したうえで基本方針を策定しました。
まずプロダクト横断で Dependabot Alerts を確認し、利用ライブラリの既知の脆弱性状況を棚卸ししました。
そのうえで、セキュアな開発ライフサイクル（SSDL）を実現するために、以下の 3 つは全プロダクトのベースラインとして導入するのが有用だと判断し、ツール調査を始めました。
- SCA
- プロダクトが使ってるライブラリ等の既知の脆弱性を把握・管理したい
- SAST
- 静的解析によりコードベースの脆弱性を継続的に検出できる状態にしたい
- DAST
- アプリケーション動作における脆弱性を把握・管理したい
- 外部の手動診断に加え、開発ライフサイクルの早い段階でフィードバックできる自動診断も欲しかった
既存の開発フローへの組み込みやすさ、使いやすさ、検知精度等を重視し、SCAにはSnyk, DASTはShisho Cloudを選定しました。
SASTについては、いくつかのツールを評価しましたが、検知精度の点で必須ではなさそうと判断しました。しかしちょうどセキュリティAIエージェントのTakumiのリリースがあったため、専任のセキュリティエンジニアを開発チームに配置するイメージで導入することにしました。
3.2 セキュリティワークショップ
さらに、開発組織全体に向けてセキュリティ教育施策として、脅威モデリングを題材としたセキュリティワークショップを実施しました。
各プロダクトごとに分かれて、STRIDEフレームワークを使って自分たちのプロダクトにおける脅威の把握や分析、議論をしてもらい、チームごとに発表する形を取りました。
ワークショップの様子はこちらにまとめています。
3.3 体制の拡大
選定したツールの導入や、活動ロードマップを整備した後は、組織全体へ展開していくフェーズに移りました。
各プロダクトチームとのハブ・推進役として1名ずつ参加してもらいました。
定例ミーティングを開催し、進捗共有や相談の場を設けることで、ツールの導入を促進していきました。
4. 具体的な取り組みと成果
4.1 ベースライン導入の実施内容
-
Snyk(SCA)
- ライブラリの脆弱性を自動検出。OSS依存の脆弱性を自動検出し、検知状況の可視化までできるようになりました。
- GitHub ActionsでSnykによるスキャンを実施することで、新規に脆弱性が混入するのを防いでいます。
- プロダクトごとにレポート管理が可能で、経営層へ対応状況を報告するのに役立っています。
-
Shisho Cloud(DAST)
- 日次やオンデマンドでWebアプリケーション診断の実施を実現しました。
- 典型的な脆弱性診断以外にも、認可（Authorization）の抜け漏れも含めて診断できています。
- Shisho Cloud の活用事例は Findy Tools の記事でも紹介されています。
-
Takumi(SAST)
- セキュリティAIエージェントの強みを活かし、従来のSASTでは拾いづらいロジック系の脆弱性も調査できるようになりました。
- また、開発中に出たセキュリティ懸念を気軽に相談・診断できる窓口としても活用しています。
- 開発者が気軽にSlackからセキュリティについて質問したり、ソースコードベースで診断できる環境を提供しています。
4.2 導入による”見える化”の成果
上記のツールを導入したことにより、開発チームが脆弱性状況を継続的に把握できるようになりました。
まずはインパクトの大きい領域に集中するため、 「Critical / High の脆弱性を 0 件にする」 ことを最初のゴールに設定しました。
このゴールを共通指標にすることで、優先度判断と対応の意思決定が揃いやすくなりました。
その結果、経営層へのレポートも以前より非常にしやすくなっています。
以下はSnykにおける実際のレポートです。
初期はトリアージと修正が必要で解決までに時間を要していますが、直近のオープンIssueは0件で、新しいIssueが出てきても、即座に修正できていることがわかります。
以下はShisho Cloudにおけるレポートです。
Severityごとに検出されている脆弱性を確認が可能です。
トリアージに必要な情報もレポートしてくれるため、開発者へのフィードバックサイクルも早く回すことができます。
5. 直面した課題と現在進行形の取り組み
運用の持続性
- 課題
- 兼務のためWG活動の優先度が下がりやすく、活動が属人化・停滞しやすい
- 取り組み
- 定例ミーティングでタスクを棚卸しし、進捗と担当を可視化して継続性を担保
- 脆弱性の集中対応期間（セキュリティスプリント）を検討し、対応の短期加速
新規の脆弱性への対応
- 課題
- 組織横断のトリアージ基準がなく、優先度判断がチームごとにばらつく
- 取り組み
- Critical/High を最優先にする方針を土台に、ベースラインのトリアージ基準（例：SLA/対応期限や例外ルール）を策定中。各プロダクトで運用に落とし込み、判断基準の統一
セキュリティ知識のばらつき
- 課題
- チームごとにセキュリティの経験値・関心に差があり、対策の質とスピードにムラが出る
- 取り組み
- セキュリティTipsの定期的な共有や、脆弱性を題材としたWSの開催など教育施策の継続検討
新規プロダクトへの対応
- 課題
- 新規プロダクト立ち上げ時にセキュリティ要件の抜け漏れが起きやすい
- 取り組み
- Product Readiness Checklist を整備し、リリース前の必須チェックとして組み込む
これらの課題に対して、まずは運用の仕組み化と判断基準の統一を優先し、プロダクトチーム自身でセキュリティ対応を自走できる状態を目指しています。並行して、教育とチェックリスト整備により、立ち上げフェーズからセキュリティが自然に組み込まれる形を作っていきます。
6. おわりに
Hacobuのプロダクトセキュリティの取り組みは、まだ道半ばです。課題も多く、試行錯誤の連続ですが、少しずつ開発組織全体のセキュリティレベルが向上していることを実感しています。
専任のセキュリティチームがない企業でも、 「やれることから始める」「チーム全体で取り組む」 という姿勢があれば、プロダクトセキュリティは前に進みます。
この記事が、これからプロダクトセキュリティに取り組もうとしている企業の一助になれば幸いです。
Discussion