Product Security Engineer

一言でいうと

自社が外部に提供するWebアプリケーション・スマホアプリ・APIの安全性に責任を持ち、設計段階から開発チームに入って脆弱性が作り込まれない状態をつくる職種です。

この職種の出自と登場時期

出発点は、セキュリティを開発工程に組み込むという考え方です。2009年に OWASP が SAMM（Software Assurance Maturity Model）を公開し、ソフトウェア開発のなかでセキュリティをどう成熟させるかを、設計・実装・検証・運用の各段階の指標として整理しました。それまで主流だった「完成後に診断する」形から、開発プロセスそのものに手を入れる形へ重心が移ります。

国内で「プロダクトセキュリティ」という言葉が職務名として定着したのは2020年前後です。SaaS企業とWeb系の事業会社で、社内IT環境を守る担当とは別に、自社プロダクトを守る担当を置く動きが広がりました。2023年には各業界の開発・セキュリティエンジニアへの取材記事が組まれ、国内の実務者コミュニティとして扱われる規模になっています。

背景には、脆弱性の指摘が事業に直接跳ね返るようになったことがあります。SaaSでは顧客のセキュリティチェックシートが受注条件になり、プロダクトの安全性が売上に関わる要素として扱われます。

ミッション

責任の中心は、提供しているプロダクトに致命的な脆弱性が残らない状態を保つことです。診断で見つけて直すことだけでなく、同じ種類の欠陥が繰り返し生まれない仕組みまでが範囲になります。

そのため、開発を止めない形での実現が前提になります。リリース速度を落とさずに安全性を上げることが要求され、検出した脆弱性の修正までの時間、重大度別の残存件数、開発フローへの組み込み状況が指標になります。

主な業務範囲

• 設計レビューと脅威モデリング。新機能の設計段階で、悪用される経路を洗い出す
• セキュアコーディングの支援。危険な実装パターンを共有し、レビュー観点として定着させる
• 脆弱性診断とペネトレーションテストの実施または外注管理。結果を修正まで追う
• 開発パイプラインへの組み込み。SAST・DAST・依存パッケージの脆弱性検査をCIに載せる
• 脆弱性報告への対応。外部からの報告窓口を運用し、切り分けと修正の優先度を決める

求められる能力

技術面では、Webアプリケーションの攻撃手法を知っていることと、対象プロダクトの実装を読めることの両方が問われます。認証認可の設計、暗号の扱い、クラウドの権限設計が中心で、開発経験があると実務の速度が上がります。

もう一つ求められるのが、開発チームと同じ目線で優先度を議論する力です。すべての指摘を最優先で直させると開発が止まるため、リスクと開発コストを並べて判断できる説明力が求められます。

この職種に就く人のキャリア経路

多いのは開発エンジニアからの移行です。バックエンド開発の経験を持つ人が、セキュリティ設計を担当するうちに専任になる流れが増えています。セキュリティベンダーで診断を担当してきた人が、事業会社の内製側へ移るケースも一般的です。

そこから先は、プロダクトセキュリティの責任者、セキュリティ組織全体を見る立場、CISOへ進む道があります。開発側へ戻ってアーキテクトを担当する経路もあります。

隣接職種との違い

採用担当の見極めポイント

• 求人票では、診断中心か開発プロセスへの組み込み中心かを明記してください。同じ職種名でも、求められる開発力が変わります
• 職務経歴書では、指摘した脆弱性が修正まで到達したかを確認してください。報告書を出すところまでの経験と、開発チームを動かした経験は別に評価する必要があります
• 開発チームがセキュリティ指摘を受け入れる用意があるかを、募集前に確認してください。優先度を決める権限がないまま採ると、指摘が滞留します

求人・市場の傾向

国内の母集団は薄く、開発経験とセキュリティ経験を両方持つ層はさらに限られます。診断経験のみの候補者と、開発から移ってきた候補者では入社後の役割が変わるため、どちらを求めるかを先に決めておく必要があります。

求人票では、プロダクトの規模、既存のセキュリティ体制、診断の実施状況を書くと、候補者が着任後の初動を判断できます。

関連キーワード

OWASP / 脅威モデリング / セキュアコーディング / SAST / DAST / 脆弱性診断 / シフトレフト / 認証認可