こんにちは。テクノロジーマネジメント本部でプロダクトセキュリティエンジニアをしているsasakki-です。
2025年1月にプロダクト全体のセキュリティ向上に責任を持つPSIRT（Product Security Incident Response Team）を立ち上げてから、1年が経過しました。
立ち上げ当初のPSIRT立ち上げ時の取り組みを紹介した記事では、プロダクトセキュリティを組織的に強化するための仕組みづくりとして、To-Be / As-Is の整理やプロダクトセキュリティガイドラインの整備、横断的な支援体制の構築に取り組んでいくことをご紹介しました。
本記事では、その1年後の現在地として、進められなかったこと・進められたこと、そしてそこから得られた学びをお伝えします。
初年度の体制
PSIRTはテクノロジーマネジメント本部というプロダクト組織の一チームとして設立しました。一方で、クラウド基盤の統制やコーポレートセキュリティを担う情報セキュリティ部も、これまでも部分的にプロダクトセキュリティに関わってきました。
そのため、初年度は情報セキュリティ部と兼任する形で1名体制でスタートしました。
立ち上げ当初から「1年かけて段階的に体制を整える」こともミッションの一部としており、まずは助走期間として活動してきました。
進められなかったこと
はじめに、2025年中の完了を計画していたものの、2025年内に進めきれなかった取り組みについて紹介します。
プロダクトセキュリティガイドラインの整備
立ち上げ時に掲げていた重要施策の一つが、プロダクトのセキュリティ水準を言語化したプロダクトセキュリティガイドラインの整備でした。
2026年からPSIRTに軸足を移す計画だったため、2025年中にガイドラインを完成させる予定でした。それを基盤として翌年以降の施策を進める想定でしたが、結果としてリリースには至りませんでした。
当初は、セキュアなWebアプリの要件を定義したOWASP ASVS（Application Security Verification Standard）や、開発におけるセキュリティプラクティスをまとめたNIST SSDF（Secure Software Development Framework）などを参照し、網羅的なガイドラインにすることを重視してセキュリティ要件を列挙していく形で整理していました。また、要件ごとに複数の実現方法を提示する形で検討を進めていました。
しかし、検討を重ねる中で、設計として見直すべき点が見えてきました。 読み手であるプロダクトエンジニアにとって重要なのは、「何を満たせばよいのか」が分かることです。しかし当初の構成では、抽象的な要件に対して実現方法が並び、何をすべきかが直感的に伝わりにくい状態になっていました。
また、実現方法が複数提示されることで、判断の責任が現場に委ねられすぎてしまう可能性もありました。
2025年後半にガイドライン全体の構成を見直すことを決め、現在は「やるべきこと／やらないでほしいこと」を軸に再構成しています。開発のスピードを損なわず、日常の意思決定を支えられるガイドラインを目指し、草稿をレビューフェーズに移しています。2026年前半のリリースを目標としています。
進められたこと
次に、この1年間で進めることができた取り組みを紹介します。
日々の対応を通じた認知の広がり
制度やガイドラインの整備に先立ち、相談窓口としての役割や、横断的にセキュリティを扱う組織としての認知が少しずつ広がってきていると感じています。明確な指標があるわけではありませんが、社内での相談や連携の機会は着実に増えてきました。
SmartHRでは200名を超えるエンジニアが在籍しており、PSIRTだけですべての情報を拾い上げることは現実的ではありません。そのため、まずは「相談できる存在」として認知されることが重要だと考えています。
正直なところ、認知獲得を目的とした取り組みを積極的に行えているわけではありません。しかし、npmのエコシステムを狙ったサプライチェーン攻撃や、React Server Componentsの脆弱性といった全体で対応すべき事案への対応を主導してきました。こうした積み重ねが、結果としてPSIRTの認知につながってきているのではないかと思います。
特別な取り組みを行ってきたわけではありませんが、マルチプロダクトを展開している中で、影響の把握から方針整理、各チームへの共有までを横断的に行う流れができたことは、この1年で生まれた変化の一つです。
中央で統制するのではなく、判断材料を整理し、各チームが主体的に対応できる状態を整える。こうした対応は、FIRST（Forum of Incident Response and Security Teams）が公開しているPSIRT Services Frameworkで示されている「分散モデル」におけるPSIRTの役割を体現できていたのではないかと捉えています。
基盤面での整備
基盤面では、Google CloudのPrivileged Access Management（PAM）を活用し、全体のアクセス権管理の見直しを行いました。
PAMにより、本番環境などへの権限昇格を申請・承認・監査のフローで管理可能になりました。それまでもトラストサービス基準やGoogle Cloudのセキュリティベストプラクティスを元に安全な運用をしていましたが、不要な常時権限を抑制し、インシデント発生時の影響範囲を把握しやすい状態へと改善しています。
兼任していた業務の一つであるクラウド基盤管理者として進めた取り組みの一環ではありますが、PSIRTの視点からもアクセス統制を改めて整理する機会となりました。
プロダクトチームが安心して開発に集中できる環境を整える上で、重要な土台づくりだったと考えています。
専任体制への前進
段階的な体制整備の一環として、コーポレートセキュリティチームの立ち上げと業務移管を進めました。
これまでPSIRTと兼務していたコーポレートセキュリティ領域を独立したチームへ移管したことで、役割の整理が進み、PSIRTはプロダクトセキュリティにより集中できる体制へと移行しています。
専任体制への移行はゴールではありませんが、組織として責任を明確にした一つの節目でした。
一年を振り返って
PSIRT立ち上げ当初はセキュリティを向上させることを至上命題としていましたが、改めて振り返ると「セキュリティをどう機能させるか」ということが重要でした。
ガイドラインの整備を例に挙げると、当初参照していたOWASP ASVSやNIST SSDFは網羅性の高い資料ですが、「開発者が日常の意思決定に使うガイドライン」とは目的が根本的に異なります。立ち上げ初期にその区別を意識し、誰がどの場面で何を判断するために使うかを定義できていれば、手戻りは少なかったと思います。
また、制度やドキュメントより先に「相談できる存在」として認知されることが、PSIRTの土台になると感じています。脆弱性対応や横断的なインシデント対応を通じた積み重ねが、後の施策を推進する上での基盤になります。
「立ち上げること」と「機能させ続けること」は別の課題です。特に初年度は兼務体制になりやすく、緊急度の高い業務に優先順位を奪われがちです。中長期の施策を前進させるには、専任体制への移行を早期にロードマップへ組み込み、組織として合意しておくことが重要だと感じました。
次の1年に向けて
2026年からは、PSIRTへ軸足を移し、以下の優先テーマに沿って取り組んでいきます。
前半（1〜6月）
プロダクトセキュリティガイドラインのリリースと浸透、セキュリティ教育によるエンジニアのベースライン構築、脆弱性状況の可視化、脆弱性対応フローの高度化を進めます。
後半（7〜12月）
ガイドラインを開発環境・インフラ領域へ拡張し、網羅性を高めていきます。並行して、AIを活用したセキュリティレビューの自動化や、CI上でのセキュリティテスト強化を進め、シフトレフトを軸にセキュリティ水準を仕組みとして引き上げます。あわせて、インシデント対応体制の強化にも取り組みます。
最後に
この1年は、大きな成果よりも、体制と基盤を整える期間でした。
進められなかった施策もありますが、役割の整理と基盤整備、そして横断的に判断を整理できる体制づくりを通じて、次の段階へ進む土台は整いつつあります。
「進められなかったこと」として本文では触れませんでしたが、体制強化については大きな前進はなく、現在も1人体制が続いています。
そのため、土台は整いつつあるものの、取り組みたい課題に対して十分な推進力を持てているとは言えず、継続して体制強化に取り組んでいきたいと思います。
We are hiring
SmartHRのプロダクトセキュリティを強化していく仕組みづくりをしていく仲間を募集しています！ この記事を読んで少しでもSmartHRのPSIRTに興味をお持ちいただけた方は、是非カジュアル面談のお申し込みからよろしくお願いします！
