おはようございます。セキュリティ本部セキュリティエンジニアの soh です。
当社セキュリティ本部では、プロダクトセキュリティとコーポレートセキュリティを分けることなく、他部署の協力を得ながら各種対応を行っています。
さて、一口に「セキュリティエンジニア」といっても、担当する責任範囲は各社さまざまだと思います。
当社でも積極的に採用を進めていますが、面談や面接の際には「どこまで担当できるのか」「求められることは何か」が気になる方が多いのではないでしょうか。
そこで本記事では、当社におけるセキュリティエンジニアの取り組みや、私がセキュリティベンダーから転職した際に感じたギャップなどを紹介します。
当社の現状
2025年現在、セキュリティ本部は少人数のメンバーおよびマネージャー（うち兼務1名）で構成され、技術推進本部やIT本部など近い部署と連携しながら活動しています。担当範囲は前述のとおり、プロダクトセキュリティとコーポレートセキュリティの全領域に及びます。
- 脆弱性診断（プラットフォーム、Webアプリ、スマホアプリ診断など）
- 一部脆弱性の修正を含む
- 新規サービスや機能のセキュリティ設計レビュー
- 一部PRレビューなどを含む
- 新規セキュリティ関連機能の提案など
- 各サービスドメインの DMARC ポリシー移行
- ISO27001 認証、PCI DSS 準拠維持のプロジェクト推進
- AI 利用に向けたセキュリティチェックやガイドライン整備、メンテナンス
- 個人情報の取り扱いに関するセキュリティ強化
- セキュリティインシデントに関するハンドリングおよび助言
上記は一例であり、実際にはセキュリティに関する業務のほとんどがセキュリティ本部の担当範囲です。これらをチームメンバーで協力しながら対応しています。
以下では、その中から一例として、脆弱性診断とその修正、そして施策推進について取り上げます。
脆弱性診断とその修正
セキュリティ本部では、以下記事に示す通り、すでに脆弱性診断の内製化を行っています。
当社ではエンジニアが業務上必要な範囲で各リポジトリにアクセス可能であり、適切な承認のもと、PRを提出することができます（統制は適切に実施しており、各種環境でのテストや考慮事項の整理を行ったうえで、開発側によるレビューを実施しています）
そのため、本人の希望およびリソースに応じて以下のようなことが実施できます。
- ホワイトボックスでの診断
- ローカル環境を構築し自由に触ること
- 自分が発見した脆弱性を自ら修正すること
- または、修正のための具体的なコードをそのプロダクトの構成に応じて提案すること
特に「自身が診断で発見した脆弱性を自ら修正できる環境」は個人的に非常に重要だと考えています。 私自身、一種のチャレンジとして、実際に何件か脆弱性やユーザビリティに関連する修正を行っていますが、これには以下のようなメリットがあります。
- セキュリティエンジニアがプロダクトをより深く理解できる
- 修正過程で、未発見の脆弱性を発見・修正できる場合がある
- 脆弱性が長期間放置されることを防げる
- プロダクトのトイル（苦労）を自分事として解決できる
もちろん、すべてのセキュリティ上の推奨事項をすぐに対応できるのが理想ですが、実際には開発を行うエンジニアのリソースが必要です。特に新規機能開発を伴う場合は、大きなリソースを確保する必要があります。
また、セキュリティの問題は事業継続に影響しうる一方、機能開発も事業成長のために不可欠で、期日が決まっていることが多いものです。
これらは双方重要であるため、セキュリティエンジニアが脆弱性の解決を担うことで、事業成長を止めずに対応が可能となります。
また、自身でPRを提出することで、開発を行うエンジニアへセキュリティ上の方向性を示し、カジュアルに相談しやすい環境をつくることにもつながりますし、これを実施すると、たまにセキュリティに関連するPRのReviewerに追加してくださることもあります。
私が行ったことはプロダクト開発を生業としている方にとって非常に小さな変更だと率直に思いますが、それでも脆弱性やトイルが存在するよりも早く解決されるほうが価値があるはずです。
これには「（触ったことのない言語やフレームワークだとしても）自身が書いたコードがお客様が直接触るものとなる」という責任も伴いますが、Reviewerの皆さんも率直にレビューしてくださるため、必要以上に心理的なハードルが高くなることはありませんでした。 また、コードリーディングの結果、プロダクト理解もより進むこととなりました。*1
また、蛇足ですが、脆弱性診断に携わるセキュリティエンジニアは、多くの自社プロダクトにおいて全機能を触る機会があります。その中で気づいた改善点やトイルを自ら修正することで、プロダクトはより使いやすいものになるはずです。 現代ではAIの台頭により、その仕様理解や修正のハードルはより下がっていると感じます。*2
このように、当社では一般的な定義にとらわれず、自身の役割を超えた取り組みを行うことが可能です。
施策推進
現状のチーム構成では、必要な施策の検討から推進までをメンバー主体で行っています。また、必要予算の見積もりと調整なども、一定の権限がメンバーへ移譲されています。
他部署やマネージャー、経営層からの相談を受けて進める施策もありますが、個々人やチームが必要と判断した取り組みについては、重要度に応じて自由に提案・推進できます。
これには様々な感覚を持つ方が居るかもしれませんが、セキュリティ本部では少なくとも現時点では基本的に「マネージャーのみで考えた施策や目標をメンバーに割り振る」という構造にはなっていません。 そのため、経験にかかわらず各人が施策を提案しそれを進めていくことができます。
同時に、その方法が本当に現状の STORES にとって最適か、またその有効性を自ら説明できることが重要です。施策推進においては、経営層へ必要性を説明したり、他部署のリソースを活用するうえで納得を得るための説明が求められます。 （ただし、少なくとも私は当社において必要性の説明に苦心した経験はほとんどありません。どちらかというと投資対効果という一般的な観点として合理的な説明が必要、という意味合いです）
施策は自身や部署の目標達成のためではなく、セキュリティ向上、ひいてはお客様および当社のために推進するものであるはずです。 そのため、自身が目指す組織像や状態を描き、それに向けて本質的な対応を行うことが事業継続・事業成長に寄与すると考えています。
セキュリティベンダーから事業会社に転職した際のギャップ
セキュリティベンダーから事業会社へ転職すると、いくつかの違いがあります。
前提として両者は役割が異なり、どちらが優れているという話ではありません。私自身、セキュリティベンダーでの経験は非常に得難いものでした。
以下に、その一部を紹介します。なお、これらすべてをこなす能力をもっていなければならないという意味ではありません。人にはその経験などに応じて得手不得手があるので、その点はマネージャーおよびメンバー全員がより良い方向性を考えるべきだと思っています。
短期的な視点ではなく、長期的な視点をもってセキュリティに向き合っていく必要がある
事業会社のセキュリティエンジニアは特に、物事を点ではなく線として捉える必要があります。
現在から見て1年後、5年後、10年後、あるいは事業フェーズが変化した場合を見据え、長期的にリスクを把握し、優先順位を考えながら対応することが求められます。
少し広めの視点だと、例えばn年後の事業規模では、現状と比較してどのように脅威とそのレベルが変化するかなどを考慮したうえで、先行して各種セキュリティ対策を実施する必要があります。
また、狭い観点では、セキュアコーディングガイドラインやエンジニア研修、SAST導入なども、作成・導入そのものが目的ではありません。どう受講してもらうか、どう楽しく学べる資料を作るか、どう更新し、必要に応じてどのように効果測定するかが重要です。
セキュリティベンダーで脆弱性診断をメインに行っているセキュリティエンジニアでは、一回限りの診断であったり、年にn回の定期診断など、ある種スポット的に多様な環境での診断を経験することが多いかと思います。これは多くの人々がセキュリティ上の被害に遭うのを防ぐことが出来るという価値があります。また、セキュリティベンダーでなければ向き合うことが難しい技術も存在するはずです。
一方で、内製化を行っている場合や担当領域が決まっている場合、長期間同じシステムの対応や脆弱性診断を行い、そのプロダクトに長期間向き合い続けることができます。
これは、セキュリティベンダーでの診断のような、様々なシステムに触れることで気持ちを切り替える、ということが難しい側面もあると思いますが、自身の手でそれぞれのプロダクトの状況を線として把握し、自ら改善を行うことができるという経験になりますし、その組織の状況やプロダクトの性質、歴史的背景を考慮したうえでのトリアージや対応を一貫して行うことができます。
このように、一定方向性の異なる苦労は存在するものの、自社プロダクトのセキュリティに向き合いたいという方には良い経験になるかと思います。
経験にかかわらず、自身が「セキュリティに関する全範囲のエキスパート」になる必要がある
セキュリティベンダーでは周りにアプリケーションやインフラなど特定領域のセキュリティに非常に強い専門家がいたかもしれません。 その同僚とニッチなセキュリティ談義を行うことは非常に刺激的ですし、学びになることも多かった記憶があります。（例えばリバースエンジニアリングやIoT、物理セキュリティの話など...）
しかし、事業会社では「セキュリティを専門的に学んできた人」は少数であることが一般的です。
また、特に経験領域がニッチな場合、自身が最も得意なスキルを使う機会が少ない事も考えられます。
そのため、たとえ自分がプログラミングを知らなかったり、各種監査への理解が浅かったり、どのようにシステムが繋がっているかわからなかったとしても、何らかの方法で自ら積極的にキャッチアップしていく必要があります。 また、適切な部署に連携を行う意味でも、個人情報保護法等の基本的な法令理解が求められる場面もあります。
セキュリティエンジニアとして、これらを学び、それらの理解に基づいてもっとも合った提案を行うことが非常に重要です。
少し話はズレますが、私は入社後すぐにPCI DSSの監査担当になりました。このように、未経験の領域にも挑戦できる環境は非常に魅力的だと感じていますが、全く経験したことがなかったため、キャッチアップに苦労しています。とはいえ、めぐり合わせがなければそう簡単に経験できるようなポジションではないため、良い経験をしているなと思うことが大半です。
当然ですが、わからないことややりたくないことに対して本人の希望を無視して無理にアサインしたり、サポートなしで進めるということではありません。
マネージャーや他メンバーのサポートのもと、「知っていること」を自ら増やしていくことが、その後の社内からの信頼獲得などにつながると考えています。
なお、セキュリティベンダーにはセキュリティに強い専門家が多数いると記載した一方で、事業会社では非常に広い領域にエキスパートが存在します。
ビジネスのエキスパートであったり、法務のエキスパート、エンジニアリングにおけるエキスパートが在籍していますし、当社では言語開発そのものを業務として行っている方もいます。
彼ら/彼女らと相談・協業しながら業務を進めていける、ということは自身のキャリアや仕事観という意味でも非常に刺激になりますし、得難い経験になっていると感じています。
「事業成長」と「事業継続」を両立する必要がある
前提として、セキュリティは事業継続上非常に重要な要素の一つです。
一方で、誤解を恐れずにお伝えすると、組織におけるセキュリティの個別事項に関する優先度は、その施策で回避できるリスクの大きさと、導入において必要となる対応コストによって、大きく変動します。
例えば、なにかのセキュリティ対策を導入することで「一般的に100点だと考えられているセキュリティ」が実現できるとします。 ただし、その対策を行うことで多くのリソースを必要としたり、業務フローが煩雑化する場合には、その提案は何らかの改善が必要となることがあります。
これは言い換えると、「セキュリティとビジネスのバランスを取る」ということであると理解しています。
これはどちらかを捨てるという意味ではありません。セキュリティエンジニアであれば、おそらく理想のセキュリティ像があるはずですし、そうあってほしいと思っています。
ただし、あくまでも「事業を前提としてのセキュリティ」であり、バランスをとったうえで、職業倫理のもと、リスクを示し、その組織にとって今取りうる「最適」なセキュリティ対策を提案・推進することが事業会社のセキュリティエンジニアに最も求められることだと考えています。
終わりに
少しテックブログという枠組みから外れた記事となってしまいましたが、 STORES におけるセキュリティ本部の取り組みについて紹介しました。
STORES のセキュリティ本部は、独立した上位部署としてではなく、エンジニアやビジネスサイドと協業し、ガバナンスを維持しつつ事業継続と成長を支える部署でありたいと考えています。
プロダクトが増え、開発スピードも速いというカオスな状況ではありますが、役割を固定せず、未経験の事象でも臆せず、施策を一気通貫で推進したい、長期的に組織に向き合いたいという方にとって、非常に楽しい環境だと思います。
最後に、現在セキュリティ本部では積極的に採用活動を行っています。本記事に興味を持ってくださった方は、ぜひお気軽にご連絡いただけますと幸いです。
