Product Security Engineer

Product Security Engineer

Description

## 「直しました」ではなく、「ここまでは安心してよい」と言える状態をつくる。

脆弱性を見つけて直すだけでは、プロダクトセキュリティは前に進みません。何を今やり、何を今はやらないのか。残るリスクを誰が引き受けるのか。その判断の材料を整え、決まったことを開発組織の中で最後までやり切る。

**Bring OutのProduct Security Engineerは、CTOの直下で、プロダクトセキュリティの計画を立て、開発組織の中で実行を回し、経営が判断できる形で現在地を伝えるエンジニアです。**

診断結果をチケットにして渡す役割ではありません。自分でコードとインフラを読み、リスクを測り、優先順位を提案して、開発の計画に載せる。対応済みのリスク、未対応のリスク、その影響と対応計画を明示し、経営がリスクの受容可否を判断できる状態をつくる仕事です。

セキュリティを開発のブレーキにするのではなく、安全な設計と実装を開発者が自然に選べる状態をつくります。CTOとともに優先順位を決めながら、専門性と実装力で複数チームに影響を与える、ハンズオンのシニアエンジニアのポジションです。

## なぜ今、このポジションなのか

Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。

顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、権限やデータの分離に求められる水準も、顧客の規模とともに上がっていきます。エンタープライズの顧客からは、導入の前にも後にも、セキュリティ審査で厳しい質問を受けます。

Bring Outは現在、SOC 2 Type 2報告書の取得に向けて取り組んでいます。CIS Controls v8に沿った自己評価も行い、どこに課題があるかは見えています。一方で、見えた課題を開発の計画に載せ、完了まで追い切る専任の担い手がいませんでした。開発組織のリーダーと業務委託のメンバーが対応を進めてきましたが、何から手を付け、何を今はやらないのかを決めて回し続ける役割が、組織として空いていた状態です。

そこでBring Outは、プロダクトセキュリティの予算とリソースをCTOの直下に置くことを経営として決め、その実行の中心を担う専任のProduct Security Engineerを迎えます。外部のペネトレーションテスト（Web・iOSアプリ・デスクトップアプリ）や、必要なツールの導入もあわせて進めます。完成した体制を引き継ぐのではなく、Bring Outのプロダクトセキュリティの進め方そのものをつくっていただきます。

## お任せしたいこと

入社初期は、既知の課題とリスクを棚卸しし、対応計画と責任分担を定め、優先度の高い課題を完了まで進めることに集中していただきます。あわせて、現在地を経営に伝える仕組みと、インシデント発生時の技術対応を主導できる備えを整えます。

重大な脆弱性への対応、顧客審査・監査、重要な設計レビューは、必要に応じて並行して進めます。AI固有のリスク評価、CIへの検出ツールの導入、開発者の自走を支える仕組みは、リスクに応じて順次整備し、必要であれば初期から前倒しします。

残余リスクの受容と、チーム間で解消できない優先順位の衝突は、CTOが最終判断します。Product Security Engineerは、判断材料を整え、承認を得た計画の実行・進捗管理・継続的な見直しに責任を持ちます。

### 計画と優先順位づけ

- 既知の課題とリスクを棚卸しし、影響と対応コストをものさしにして優先順位を付ける

- 何を今やり、何を今はやらないのかをリスクと対応コストから提案し、残余リスクの受容についてCTOの判断・承認を得る

- 新しく見つかった脆弱性を、重大度ごとに定めた対応期限の中で処理できる流れをつくる

### 開発組織の中での実行

- 各開発チームのリーダーと担当・工数・期限を合意し、対応をロードマップに組み込んで、完了まで進捗を管理する

- 開発の優先順位とぶつかったときは、リスクと事業への影響を整理してチームのリーダーと調整し、解消できない場合はCTOの判断を仰ぐ

- 自分でコードとインフラ構成を読み、脆弱性を見つけ、修正方針を示す。必要なら自らも手を動かす

「チケットは切ったが、閉じていない」を終わらせることが、最初のゴールです。

### 設計段階からのセキュリティ

- 新機能や重要な設計変更について、開発者とともに脅威モデリングやセキュリティ設計レビューを行い、実装前にリスクと対策を明確にする

- 認証・認可、テナント間のデータ分離、API、機密データの取り扱いを重点的に評価し、必要に応じてコードレビューや検証を行う

- 開発速度を不必要に落とす承認ゲートではなく、設計指針、チェックリスト、再利用可能な仕組みを整え、開発者が自ら安全性を判断できる状態をつくる

### AIプロダクト固有のリスクへの対応

- 会話・文字起こしデータが、取得、保存、検索、LLMへの送信、出力までの過程で適切に保護されているかを評価する

- プロンプトインジェクション、機密情報の漏えい、LLMや外部ツールの不適切な呼び出しなどの脅威を、開発チームとともに検証し、現実的な対策を設計する

- AI機能や外部モデル・サービスを導入する際、データの送信先、権限境界、ログへの機密情報混入などのリスクを整理する

### 経営への報告と判断材料づくり

経営に対する説明責任はCTOが持ちます。Product Security Engineerは、CTOが決めるための材料をつくり、経営会議では同席して説明を担います。

- プロダクトセキュリティの現在地を、定点で報告できる形にする

- 「どこまでやれば十分か」の線引きを、選択肢と残るリスクを並べて提案する

- 非エンジニアの経営陣がそのまま判断に使える資料をつくる

### 外部からの要求への対応

- 顧客のセキュリティ審査の質問票に、技術的な裏付けを持って回答する

- 外部のペネトレーションテストや診断の範囲を設計し、指摘の妥当性・重複・影響を検証して、開発チームと対応方針を整理する

- SOC 2などの監査に向け、プロダクトと開発プロセスに関する統制の整備・改善、運用証跡の準備、技術的な説明を主導する。全社監査の取りまとめは主担当に含めず、取りまとめを担う担当者と連携する

### 有事の備えと技術対応

- CTOや関係部門とともにインシデント対応の役割分担とエスカレーション基準を整え、発生時には影響調査、封じ込め、復旧、再発防止の技術対応を主導する

- 顧客への連絡や事業上の判断はCTO・関係部門が責任を持ち、その判断に必要な技術的事実と影響範囲を整理する

- 対応手順や訓練を通じて、開発チームが有事に動ける状態をつくる

### プロダクトと開発を支える統制

プロダクトと開発に関する技術的な統制の設計・改善を主導します。実装と日常運用は、開発・インフラなどの担当者と分担を合意して進めます。社内ITの運用は主担当に含めず、コーポレートセキュリティの担当と連携します。

- 業務委託先を含め、本番環境やデータへの人のアクセスを、付与から棚卸しまで管理できる状態にする

- 調査と説明に必要なログが、必要な期間、改ざんされずに残る状態をつくる

- CIS Controls等に沿った内部アセスメントを定期的に回し、結果を計画に戻す

- コーポレートセキュリティの担当と連携し、社内ITとプロダクトの境界で抜けが出ないようにする

### リスクに応じて整備・拡充する領域

初期の重点課題と並行し、リスクと事業上の必要性に応じて、次のテーマにも取り組んでいただきます。既知の課題が減るまで一律に待つのではなく、必要なものは初期から前倒しします。

- **開発の流れへの組み込み**：SAST・SCA・シークレット検出などをCIに組み込み、誤検知を減らし、依存ライブラリやソフトウェアサプライチェーンのリスクも含めて、開発者が自分で対応できる状態にする

- **認証・規格への対応判断**：顧客の業界から求められる規格（金融機関向けのFISC安全対策基準など）に、どこまで、どの順で対応するかを提案する

- **経営判断への意見**：新しい機能や事業の判断に、セキュリティの立場から早い段階で意見を出す

将来的には、Bring Outのセキュリティ全体を統括する役割（CISO）を置くことも考えています。この役割で経験を積んでその立場を担っていただく道も、CISOとともにプロダクトセキュリティを率いる道もあります。

## 大切にしたい指標

プロダクトセキュリティは、見つけた脆弱性の数では測れません。優先度に応じてリスクを低減できていることと、残るリスクの影響・対応計画が明示され、経営が受容可否を判断できることを重視します。

- **優先度に応じた課題対応の進捗**：優先度の高い課題から、計画どおりの対応完了、またはCTOの承認によるリスク受容まで到達しているか

- **新規の脆弱性の期限内対応率**：重大度ごとの対応期限を守れているか

- **残るリスクの見える化**：今はやらないと決めたものが、理由と合意とともに記録されているか

- **外部要求への対応**：顧客審査や監査の指摘に、根拠を持って期限内に応えられているか

- **開発者が自走できる範囲**：設計時のリスク確認から検出・修正まで、Product Security Engineerを経由せずに回る範囲が増えているか

具体的な目標は、入社後に現状を確認したうえで一緒に設定します。

## 向き合う技術

| 領域 | 技術 |

| プロダクト | Webアプリケーション / iOSアプリ / デスクトップアプリ |

| バックエンド | Node.js / TypeScript / Python / GraphQL |

| データストア | PostgreSQL / AWS S3 / DynamoDB |

| インフラ | AWS / Terraform / Docker / GitHub Actions |

| 可観測性 | Datadog等 |

| AI処理 | LLM API、文字起こし用GPU |

| セキュリティツール | SAST・SCA・シークレット検出等（選定・導入はこのポジションの担当領域） |

すべての技術に最初から精通している必要はありません。自分でコードと構成を読み、リスクを根拠とともに説明できることを重視します。

Requirements

## 「直しました」ではなく、「ここまでは安心してよい」と言える状態をつくる。

脆弱性を見つけて直すだけでは、プロダクトセキュリティは前に進みません。何を今やり、何を今はやらないのか。残るリスクを誰が引き受けるのか。その判断の材料を整え、決まったことを開発組織の中で最後までやり切る。

**Bring OutのProduct Security Engineerは、CTOの直下で、プロダクトセキュリティの計画を立て、開発組織の中で実行を回し、経営が判断できる形で現在地を伝えるエンジニアです。**

診断結果をチケットにして渡す役割ではありません。自分でコードとインフラを読み、リスクを測り、優先順位を提案して、開発の計画に載せる。対応済みのリスク、未対応のリスク、その影響と対応計画を明示し、経営がリスクの受容可否を判断できる状態をつくる仕事です。

セキュリティを開発のブレーキにするのではなく、安全な設計と実装を開発者が自然に選べる状態をつくります。CTOとともに優先順位を決めながら、専門性と実装力で複数チームに影響を与える、ハンズオンのシニアエンジニアのポジションです。

## なぜ今、このポジションなのか

Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。

顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、権限やデータの分離に求められる水準も、顧客の規模とともに上がっていきます。エンタープライズの顧客からは、導入の前にも後にも、セキュリティ審査で厳しい質問を受けます。

Bring Outは現在、SOC 2 Type 2報告書の取得に向けて取り組んでいます。CIS Controls v8に沿った自己評価も行い、どこに課題があるかは見えています。一方で、見えた課題を開発の計画に載せ、完了まで追い切る専任の担い手がいませんでした。開発組織のリーダーと業務委託のメンバーが対応を進めてきましたが、何から手を付け、何を今はやらないのかを決めて回し続ける役割が、組織として空いていた状態です。

そこでBring Outは、プロダクトセキュリティの予算とリソースをCTOの直下に置くことを経営として決め、その実行の中心を担う専任のProduct Security Engineerを迎えます。外部のペネトレーションテスト（Web・iOSアプリ・デスクトップアプリ）や、必要なツールの導入もあわせて進めます。完成した体制を引き継ぐのではなく、Bring Outのプロダクトセキュリティの進め方そのものをつくっていただきます。

## お任せしたいこと

入社初期は、既知の課題とリスクを棚卸しし、対応計画と責任分担を定め、優先度の高い課題を完了まで進めることに集中していただきます。あわせて、現在地を経営に伝える仕組みと、インシデント発生時の技術対応を主導できる備えを整えます。

重大な脆弱性への対応、顧客審査・監査、重要な設計レビューは、必要に応じて並行して進めます。AI固有のリスク評価、CIへの検出ツールの導入、開発者の自走を支える仕組みは、リスクに応じて順次整備し、必要であれば初期から前倒しします。

残余リスクの受容と、チーム間で解消できない優先順位の衝突は、CTOが最終判断します。Product Security Engineerは、判断材料を整え、承認を得た計画の実行・進捗管理・継続的な見直しに責任を持ちます。

### 計画と優先順位づけ

- 既知の課題とリスクを棚卸しし、影響と対応コストをものさしにして優先順位を付ける

- 何を今やり、何を今はやらないのかをリスクと対応コストから提案し、残余リスクの受容についてCTOの判断・承認を得る

- 新しく見つかった脆弱性を、重大度ごとに定めた対応期限の中で処理できる流れをつくる

### 開発組織の中での実行

- 各開発チームのリーダーと担当・工数・期限を合意し、対応をロードマップに組み込んで、完了まで進捗を管理する

- 開発の優先順位とぶつかったときは、リスクと事業への影響を整理してチームのリーダーと調整し、解消できない場合はCTOの判断を仰ぐ

- 自分でコードとインフラ構成を読み、脆弱性を見つけ、修正方針を示す。必要なら自らも手を動かす

「チケットは切ったが、閉じていない」を終わらせることが、最初のゴールです。

### 設計段階からのセキュリティ

- 新機能や重要な設計変更について、開発者とともに脅威モデリングやセキュリティ設計レビューを行い、実装前にリスクと対策を明確にする

- 認証・認可、テナント間のデータ分離、API、機密データの取り扱いを重点的に評価し、必要に応じてコードレビューや検証を行う

- 開発速度を不必要に落とす承認ゲートではなく、設計指針、チェックリスト、再利用可能な仕組みを整え、開発者が自ら安全性を判断できる状態をつくる

### AIプロダクト固有のリスクへの対応

- 会話・文字起こしデータが、取得、保存、検索、LLMへの送信、出力までの過程で適切に保護されているかを評価する

- プロンプトインジェクション、機密情報の漏えい、LLMや外部ツールの不適切な呼び出しなどの脅威を、開発チームとともに検証し、現実的な対策を設計する

- AI機能や外部モデル・サービスを導入する際、データの送信先、権限境界、ログへの機密情報混入などのリスクを整理する

### 経営への報告と判断材料づくり

経営に対する説明責任はCTOが持ちます。Product Security Engineerは、CTOが決めるための材料をつくり、経営会議では同席して説明を担います。

- プロダクトセキュリティの現在地を、定点で報告できる形にする

- 「どこまでやれば十分か」の線引きを、選択肢と残るリスクを並べて提案する

- 非エンジニアの経営陣がそのまま判断に使える資料をつくる

### 外部からの要求への対応

- 顧客のセキュリティ審査の質問票に、技術的な裏付けを持って回答する

- 外部のペネトレーションテストや診断の範囲を設計し、指摘の妥当性・重複・影響を検証して、開発チームと対応方針を整理する

- SOC 2などの監査に向け、プロダクトと開発プロセスに関する統制の整備・改善、運用証跡の準備、技術的な説明を主導する。全社監査の取りまとめは主担当に含めず、取りまとめを担う担当者と連携する

### 有事の備えと技術対応

- CTOや関係部門とともにインシデント対応の役割分担とエスカレーション基準を整え、発生時には影響調査、封じ込め、復旧、再発防止の技術対応を主導する

- 顧客への連絡や事業上の判断はCTO・関係部門が責任を持ち、その判断に必要な技術的事実と影響範囲を整理する

- 対応手順や訓練を通じて、開発チームが有事に動ける状態をつくる

### プロダクトと開発を支える統制

プロダクトと開発に関する技術的な統制の設計・改善を主導します。実装と日常運用は、開発・インフラなどの担当者と分担を合意して進めます。社内ITの運用は主担当に含めず、コーポレートセキュリティの担当と連携します。

- 業務委託先を含め、本番環境やデータへの人のアクセスを、付与から棚卸しまで管理できる状態にする

- 調査と説明に必要なログが、必要な期間、改ざんされずに残る状態をつくる

- CIS Controls等に沿った内部アセスメントを定期的に回し、結果を計画に戻す

- コーポレートセキュリティの担当と連携し、社内ITとプロダクトの境界で抜けが出ないようにする

### リスクに応じて整備・拡充する領域

初期の重点課題と並行し、リスクと事業上の必要性に応じて、次のテーマにも取り組んでいただきます。既知の課題が減るまで一律に待つのではなく、必要なものは初期から前倒しします。

- **開発の流れへの組み込み**：SAST・SCA・シークレット検出などをCIに組み込み、誤検知を減らし、依存ライブラリやソフトウェアサプライチェーンのリスクも含めて、開発者が自分で対応できる状態にする

- **認証・規格への対応判断**：顧客の業界から求められる規格（金融機関向けのFISC安全対策基準など）に、どこまで、どの順で対応するかを提案する

- **経営判断への意見**：新しい機能や事業の判断に、セキュリティの立場から早い段階で意見を出す

将来的には、Bring Outのセキュリティ全体を統括する役割（CISO）を置くことも考えています。この役割で経験を積んでその立場を担っていただく道も、CISOとともにプロダクトセキュリティを率いる道もあります。

## 大切にしたい指標

プロダクトセキュリティは、見つけた脆弱性の数では測れません。優先度に応じてリスクを低減できていることと、残るリスクの影響・対応計画が明示され、経営が受容可否を判断できることを重視します。

- **優先度に応じた課題対応の進捗**：優先度の高い課題から、計画どおりの対応完了、またはCTOの承認によるリスク受容まで到達しているか

- **新規の脆弱性の期限内対応率**：重大度ごとの対応期限を守れているか

- **残るリスクの見える化**：今はやらないと決めたものが、理由と合意とともに記録されているか

- **外部要求への対応**：顧客審査や監査の指摘に、根拠を持って期限内に応えられているか

- **開発者が自走できる範囲**：設計時のリスク確認から検出・修正まで、Product Security Engineerを経由せずに回る範囲が増えているか

具体的な目標は、入社後に現状を確認したうえで一緒に設定します。

## 向き合う技術

| 領域 | 技術 |

| プロダクト | Webアプリケーション / iOSアプリ / デスクトップアプリ |

| バックエンド | Node.js / TypeScript / Python / GraphQL |

| データストア | PostgreSQL / AWS S3 / DynamoDB |

| インフラ | AWS / Terraform / Docker / GitHub Actions |

| 可観測性 | Datadog等 |

| AI処理 | LLM API、文字起こし用GPU |

| セキュリティツール | SAST・SCA・シークレット検出等（選定・導入はこのポジションの担当領域） |

すべての技術に最初から精通している必要はありません。自分でコードと構成を読み、リスクを根拠とともに説明できることを重視します。

Preferred Experiences

- 事業会社のプロダクトセキュリティ担当として、CTOやVPoEなど、セキュリティ専門ではない上司の下で動いた経験

- 顧客のセキュリティ審査の質問票への回答や、外部診断の報告書を評価して開発チームと対応方針を整理した経験

- SAST・SCA・シークレット検出などのツールをCIに組み込み、誤検知の調整まで含めて運用した経験

- SOC 2の監査、ISMS認証、FISC安全対策基準等への対応経験

- CIS Controls、NIST CSF等のフレームワークを使った内部アセスメントの経験

- AWSのアクセス管理（IAM、権限の一時付与、ログの保全など）の設計・運用経験

- セキュリティインシデントの対応、または対応手順の設計・訓練の経験

- iOSアプリやデスクトップアプリのセキュリティ評価の経験

- LLMを使うアプリケーションの脅威モデリング、プロンプトインジェクション対策、データ保護、外部ツール連携の安全性評価の経験

- OAuth 2.0、OIDC、SAMLなどの認証基盤や、マルチテナントSaaSの権限設計に関わった経験

歓迎要件のすべてを満たす必要はありません。これまでどんなリスクに向き合い、何を決め、何を仕組みに変えてきたかを、ぜひ聞かせてください。

We are looking for

### 仕事の出口は、経営の判断だと考えている方

報告のゴールは「直しました」で終わらず、対応済み・未対応のリスク、その影響と対応計画を示し、経営が受容可否を判断できる状態をつくることです。技術の言葉を、経営が決められる言葉に置き換えることを楽しめる方を歓迎します。

### 「今はやらない」を提案し、合意を得て進められる方

すべてのリスクを同時になくすことはできません。当面受容するリスクと対応しない理由を明示し、CTOの判断・承認を得たうえで、合意した対応と継続的な見直しに責任を持てる方です。

### 指摘で終わらず、完了まで運べる方

開発チームの優先順位や事情を理解したうえで、対応を計画に載せ、最後まで追いかけられる。開発者の味方として、仕組みで解決できる方です。

### 自分の手で確かめられる方

ツールや診断の結果をそのまま受け取らず、自分でコードと構成を読んで確かめたい。AIも積極的に使いながら、判断の根拠と責任は手放さない方です。

**守っているつもりから、守れていると説明できる状態へ。**

Bring OutのProduct Security Engineerとして、顧客と経営が安心して頼れるプロダクトを一緒につくりませんか。

Working Conditions

Salary

応相談

・候補者様の ご経歴 / スキル によって柔軟に条件を検討

・半期ごとにミッションシートを設定し評価を実施

Location

リモートワーク

- 日本国内にお住まいの方に限ります（フルリモート・フレックスですが、国外からの勤務はできません）

Job Type

正社員／契約期間の定めなし

Work hours

・フレックスタイム

- 始業 8:00から10:30まで

- 終業 15:00から20:00まで

- コアタイム. 10:30から15:00まで

- 労働時間 月160h + みなし残業40h以内※実態として、チームMTG等の都合で9:30-17:00位に稼働している従業員が場合が多い、未就学児のお子さんを持つ家庭が多く、夜に稼働している方は少ない

休日

- 週休2日（土日）、祝日

- 有給休暇 年間10日

- 年末年始休暇(12月29日から翌年1月3日まで)

- 慶忌休暇

Probation period

・試用期間は入社年月日より3カ月です。

Benefits

- 社会保険完備

- 健康診断（年1回）

- 育休産休制度

- 交通費支給

- 出先での会議の場合の会議室代全額支給

- リモートワーク手当（ヘッドセットなどの準備として最大2万円補助）

- PC支給（ビズ15万円以内、開発20万円以内）

加入保険

- 社会保険完備