Flatt Security に入社しました

2020 年より約 4 年間長期インターンとして携わってきた Flatt Security に、2024 年 4 月 1 日付で正社員として入社しました。この記事では、Flatt Security への入社を決意した理由を振り返り、これから取り組みたいことを表明します。

セキュリティとの邂逅からこれまでを振り返る

私がセキュリティという分野に出会ってからこうして入社するまでにはさまざまな出来事があり、それらの経験によって私のセキュリティに対する関心や情熱が形成されてきました。ここではセキュリティに出会ってからそれに本気で向き合いたいと思うようになった経緯や、セキュリティエンジニアから開発エンジニアへ転向した理由などを振り返ります。

セキュリティへの技術的興味から開発者としての当事者意識へ

私がプログラミングを始めたのは中学2年の頃ですが、当時はゲームや bot の開発、自然言語処理などを主にやっていて、セキュリティの勉強を始めるのはその6年ほど後でした。セキュリティに出会ったきっかけは、私が所属していた大学サークル TSG が SECCON で優勝したことです。それまでセキュリティについてあまり触れてこなかった私は、「CTF で世界一を取ったチームがこんなにすぐそばにいるなら、この機会に CTF を始めてみよう」と思い、優勝メンバーが開催してくれた CTF 入門勉強会に参加し始めました。最初の勉強会は pwn の入門で、「C 言語をコンパイルしてできたバイナリって、人間に読めるの!?」という衝撃から始まったことを記憶しています1。その後 web や crypto の勉強会に参加したり、常設 CTF を少しずつ解き進めたりしました。現在 Flatt Security の CTO である米内さんは TSG のメンバーでもあり、米内さんが開催した CSS Injection の勉強会に参加したこともありました。

こうして初めは単なる技術的興味から CTF を勉強していましたが、大学 2 年の夏に起きた 7pay 事件を機に、開発者としてセキュリティへの当事者意識を持つようになりました。サービス開始からわずか数日で不正利用が明らかになり、そのままサービス終了へ至ったことに、プログラミングを趣味としていた私は強烈な衝撃を受けました。もし私が開発したものに似たようなことが起きたら、つまり私が丹精を込めてコツコツ開発してようやくリリースに漕ぎ着けたプロダクトが、リリース直後にセキュリティ上の問題が発覚してそのままお蔵入りにせざるを得なくなったら、あまりにも悔しいだろうと思いました。せっかく磨き上げたプロダクトが、ニーズではなくセキュリティ上の問題によって再起不能になるのは、あまりにももったいないと思うのです。

その年の冬、Flatt Security の創業者であり TSG のメンバーでもある井手さんに、セキュリティエンジニアとしての長期インターンのお誘いをいただきました。「開発者としてセキュリティをしっかり勉強しなければ」と思っていた私にとって、Web サービスのセキュリティ診断をするという経験はとても魅力的でした。また会社の当時のミッション2である「セキュリティの力で信頼をつなげ、クリエイティブな社会を実現する」というフレーズは、「手塩にかけて作ったプロダクトがセキュリティ上の問題でコケないようにしたい」という私の考えに共鳴するものでした。このような理由から、私は Flatt Security でのインターンを決断しました。

インターンで芽生えた課題意識

「セキュリティの知識を身に付けたい」という理由で始めたインターンでしたが、実際にセキュリティ診断に携わると、世の中のプロダクト開発におけるセキュリティにおける理想と現実のギャップを感じるようになりました。そして現実を理想に近づけていくためには従来のワンショットのセキュリティ診断では限界があり、もっと開発組織と近い距離感で、開発サイクルに伴走してプロダクトのセキュリティに携わる必要があると考えるようになりました。

診断で深刻な脆弱性を発見したことは何度もありましたが、私が脆弱性を発見したということは、その脆弱性が生まれてから診断時点までにずっと見過ごされてきたことを意味します。開発者がコードを書いた時点やプルリクエストをレビューした時点で、どうしてそれらの脆弱性は気づかれなかったのでしょうか。脆弱性が見過ごされたままプルリクエストがマージされるという構造を根本的に解決したいと思うものの、診断エンジニアに見えるのは出来上がったプロダクトだけで、その背後にある開発組織にアプローチできないことに歯痒さを感じていました。

開発組織が自力で多くの脆弱性を見つけられるようにしたいと考えている理由はもう一つあります。それは、プロダクトを作った人たちだからこそ効率的に脆弱性を見つけられるはずだということです。セキュリティ診断ではもちろんセキュリティの知識が求められますが、診断対象のプロダクト特有の知識と合わせてこそ効率的な検査や精緻なリスク評価が可能になります。例えば診断対象のシステムの挙動に合わせてうまく自動診断ツールを繋ぎ込む実装は、診断における重要な仕事の一つです。さらに、ビジネスロジック脆弱性と呼ばれるものについては、そもそも「問題視される挙動とは何か」を診断対象サービスごとに考える必要があります。例えば「ユーザーの実名が閲覧可能」という事象は、実名制の Web サービスでは正常な挙動ですが、ハンドルネーム制の Web サービスであれば個人情報の漏洩となります。このようにプロダクトの仕様や特性を把握することは高品質なセキュリティ診断に不可欠であり、Flatt Security における診断工程でも、脆弱性を探す前にシステムの正常系を理解するところから始まります。一方で開発組織のメンバーであれば、プロダクトを既に熟知しているのでオーバーヘッドなく効果的に脆弱性を調査できるのではないかと思うのです。外部の視点だからこそ先入観を排除して脆弱性を見つけられるという意見もあり、私はそれを否定することはしませんが、ベンダーの立場で診断に携わってきた経験から感じるのは、プロダクトを熟知していれば見つけやすい脆弱性も少なくないということです。

コードが書かれてから診断で脆弱性が見つかるまでのタイムラグにも課題を感じていました。特に機能の仕様そのものや根本的な設計の問題に起因する脆弱性が見つかった場合、診断報告書で提案する修正方法は仕様や設計の根本的な変更を求めるものとなりがちですが、一度作ったものを設計段階から作り直すのは手戻りコストがかかります。その度に、「仕様策定や設計の段階でセキュリティエンジニアが携わっていれば、手戻りはもっと小さかったのに」と悔しく思っていました。

近年の開発スタイルの進化と旧来のセキュリティ診断との間のミスマッチを感じることもありました。例えばイテレーティブな開発スタイルが普及してきたのにもかかわらず、セキュリティ診断の実施頻度がそれより遥かに低いという点です。診断の過程で脆弱性を発見して再現手順と合わせて報告したものの、報告書がお客様に読まれるまでの間にプロダクトのリリースがあって、その変更によって再現手順が動かなくなってしまうこともありました。つまり、プロダクトは刻々と変化していくのにもかかわらず、従来のセキュリティ診断がそのスピードについていけていないのです。また、一度セキュリティ診断をして脆弱性を一通り洗い出したとしても、その後すぐにプロダクトは変化していき、その変化の過程で新しい脆弱性が埋め込まれてしまうかもしれません。このように日々生まれるかもしれない脆弱性に対応するには、低頻度のセキュリティ診断ではタイムラグが大きすぎると感じていました。

以上の課題意識を裏返すと、私が考えるプロダクトセキュリティの理想状態は次のようなものです。コードを書いた時点やプルリクエストをレビューする時点などで、開発組織が自力でほとんどの脆弱性を見つけている。プロダクトは日々変化するものの、継続してセキュアな状態が保たれている。ベンダーによるセキュリティ診断で報告される脆弱性は、専門的なスキルや外部視点がなければ検出できないようなものだけである。これをベンダー側の立場から見ると、セキュリティエンジニアは難度の高い脆弱性の調査により多くの時間を割くことができ、時間あたりの提供価値を高めることができるはずです。プロダクトを熟知している開発組織とセキュリティの専門性が高いベンダーがそれぞれの強みを活かしてプロダクトのセキュリティを保っている状態を私は目指しています。

プロダクトセキュリティの理想を追求したいからこそ、開発エンジニアを志す

インターンでセキュリティ診断に携わったことで、プロダクトセキュリティに関する以上のような課題意識を、推測ではなく実感として持つようになりました。Flatt Security ももちろんこういった課題を乗り越えるため、開発組織に寄り添ったサービスを提供できるよう探求し続けています。私も開発組織におけるプロダクトセキュリティのあり方を抜本的に革新したいと思っていたものの、それを考えるには開発組織に関する知識が自分に不足していると感じていました。開発サイクルに伴走するサービスを考えたくても、そもそも開発サイクルというものへの解像度が足りていないのです。

就職について考え始めた修士 1 年の春、私は開発エンジニアとしてプロダクト開発に携わりたいと考えていました。自ら開発を手がけることでプロダクトが作られる現場を知り尽くし、そのセキュリティを理想状態へ持っていくために開発サイクルのあらゆるプロセスを改革したいと考えていました。

ちなみに開発エンジニアを志望したもう一つの背景として、そもそもソフトウェア作りが好きであることがあります。Flatt Security でインターンを始めた動機も「自分が開発したソフトウェアをセキュアにするための知識が欲しい」であり、最終目的はソフトウェアを作ることでした。したがって私のキャリアの中心はソフトウェア開発であるはずで、そうしたキャリアのためには開発者としての実務経験が有利に働きます。当時の私はセキュリティエンジニアとしての経験や、内製のセキュリティ診断プラットフォームの開発経験はあったものの、開発者としてのキャリアを築くにはもう少し本格的な開発経験が欲しいと感じていました。

こうして開発エンジニアへの転向を決意したわけですが、就職先として当初考えていたのはいわゆるメガベンチャーと呼ばれるような企業でした3。様々なプロダクトを抱える企業であれば、多様な開発組織のあり方に触れることができるというのが一つの理由です。また開発者として成長する上でも、様々な領域のスペシャリストが集うメガベンチャーは魅力的な環境です。Flatt Security ではメガベンチャーを経て中途入社した社員もおり、そういった社員がそれまでのキャリアで培ったスキルや人脈などを Flatt Security で役立てている姿も、私がファーストキャリアにメガベンチャーを選ぶ後押しとなりました。

Flatt Security への入社を決意した 2 つの転機

就職を考え始めた頃はメガベンチャーで開発エンジニアとして働くことを考えていましたが、その年の夏に 2 つの転機が訪れます。

1 つ目の転機は、「未来会議」という社内イベントです。これは 0→1 から 1→100 のフェーズに移りつつある Flatt Security において、事業をどのように進化させれば非連続的な成長を達成できるかを事業部全体で考える社内ビジネスコンテストのようなものです。診断サービスに直接関わるセキュリティエンジニアや営業・PM のみならず、人事や総務などのメンバーも参加し、いくつかのチームに分かれて事業のアイデアを 2 日間じっくり議論しました。そこで私は先述したプロダクトセキュリティへの課題意識をぶつけ、Flatt Security として何ができるかをチームメンバーと議論しました。

この社内イベント「未来会議」を通じて、私は「Flatt Security のが面白い」と感じました。Flatt Security の非連続的な成長に携われるのは今であって、5〜10年後では同じ経験はできないでしょう。つまり、メガベンチャーでしばらく働いた後に Flatt Security に戻ってきたとしても、「未来会議で感じた今の Flatt Security の面白さ」「事業を 1→100 に成長させる経験」は体験できないのかもしれないのです。

このイベントを通じて強く印象に残ったもう一つのことは、プロダクトセキュリティのあり方に変革を起こす上での Flatt Security の強さです。私はそれ以前にも大学の授業などでビジネスコンテストに参加したことがありましたが、「これならうまくいくはずだ」「これを積極的に推し進めたい」と思える事業アイデアはなかなか作れませんでした。一方で、この社内ビジネスコンテストで各チームが考えたアイデアはどれも魅力的で、説得力のあるものでした。全てのチームが強いアイデアを出せた背景としては、次のような事柄があると私は考えています。

  • プロダクトセキュリティにおける課題意識が想像に基づいたものではなく、診断サービスなどの提供を通じてお客様の現実のセキュリティ課題に向き合って培われたものであること
  • 他社がこれまでやってこなかったチャレンジングな事業アイデアでも、それを可能とする優秀で熱意のあるメンバーが揃っていること
  • 新しいサービスが受容されるために必要な信頼・ブランド力・顧客基盤が、これまでの診断サービスの提供によって蓄積されていること

私の以前の考えは、「Flatt Security を出てプロダクト開発組織に入り、自分でセキュリティを推し進めていく」というものでした。一方でこの未来会議で見せつけられたのは、Flatt Security というチームは、プロダクトセキュリティのあり方を革新する上で個人より遥かに強い武器を持っているということでした。

私が Flatt Security への入社を決意した 2 つ目の転機は、Flatt Security が開発しているセキュリティプロダクト「Shisho Cloud」のチームに参加したことです。つまり、Flatt Security の内部でセキュリティ診断からプロダクト開発へジョブチェンジしたことになります。私が開発エンジニアとしての就職を考えていた理由の一つは開発者としての実務経験を積むことでしたが、Shisho Cloud の開発に携わるうちに、ここで活躍できれば自信を持って実務経験のある開発者を名乗れると感じるようになりました。

そして私が Shisho Cloud のチームに参加したのは、Shisho Cloud が正式リリースされる直前でした。つまり Shisho Cloud というプロダクトのコア機能に携われる機会が、今ならたくさんあるのです。実際これまでに、GitHub Actions から Shisho Cloud にログインするための OIDC ベースの認証機構や、セキュリティポリシーを記述した TypeScript コードを Shisho Cloud 上で実行する基盤づくりなど、技術的に奥深い領域に携わることができましたし、これからも面白いチャレンジが待っています。

Flatt Security の今

私が Flatt Security への入社を決意したのは 1 年ほど前です。前節で述べた「Flatt Security の今の面白さ」は 2023 年春時点のものであり、執筆時点の Flatt Security には新たなチャレンジが待っています。

2023 年 7 月よりセキュリティ診断に対するソースコード診断の無償付帯という施策を打ち出し、セキュリティエンジニアがソースコード情報を活用することで、診断の効率や診断報告書の品質を高めてきました。ソースコード情報を効果的に診断に用いる工夫には、まだまだ探求の余地があると私は思っています。

blog.flatt.tech

また、ChatGPT を始めとする生成 AI 技術は、近年急速に普及してきたものの、セキュリティ診断を始めとするプロダクトセキュリティ領域でその活用はまだ発展途上にあると考えています。セキュリティサービスではお客様の環境の脆弱性情報など様々な秘密情報を取り扱うため、生成 AI やそれを提供するプラットフォームに由来するリスクを把握して適切な利用方法を編み出さなければなりません。このような制約下で生成 AI を用いてセキュリティサービスの進化を探求する試みは、今まさにアツいチャレンジです。

そして先日 Flatt Security は 10 億円の資金調達を行い、合わせて GMO インターネットグループに参画しました。

flatt.tech

私がグループ参画を知ったのは入社を決めた後でしたが、Flatt Security でプロダクトセキュリティの理想を追求していきたいという考えに変わりはありません。そう言い切れるのは、Flatt Security がこれまで大事にしてきた価値観がこれからも保たれていくからです。高度な専門性とエンジニアリングを武器にすること。これまで提供してきたサービスの現状維持に甘んじず、本質的に価値のあるセキュリティサービスを追求し続けること。そして倫理観——自らの専門性を悪用しないだけでなく、専門性を正しく活かして世の中のために役立てること。Flatt Security をここまで成長させてきたこれらのコアは、これからも我々を駆動し続けます。

blog.flatt.tech

Flatt Security に限らず、会社というものは時間と共に変化していきます。時代が急速に変化していることを考えれば、変化は生存戦略として当然のことです。他社でも企業が合併したり、経営陣が交代したり、志望していた部署がなくなったり、憧れの先輩社員が転職したり、こういったことが就職活動を始めてから入社するまでに起き得ます。そういった不確実性を踏まえてファーストキャリアを選ぶには、会社の背骨をなす軸というものが一つの観点となるでしょう。これほどのビッグイベントを経ても Flatt Security が Flatt Security であり続けたからこそ、これからも長いスパンで私と Flatt Security は同じ志を持って前進していけると思っています。

グループ参画で得られたものは、10 億円の資金だけではありません。特に私が期待しているのは、グループ内のエンジニアとの横の繋がりです。グループが抱える様々なサービスの開発に携わるエンジニアとの交流を深め、それぞれが抱えるセキュリティ上の課題により解像度高く向き合うことができればと考えています。またソフトウェア開発において私より高い専門性を持つ方もグループ内にたくさんいらっしゃるでしょうから、そういった方から刺激を受けることができれば幸いです。

Flatt Security で取り組みたいこと

先述したように、私が開発エンジニアへの転向を決めた理由は、「開発組織の内側からプロダクトセキュリティを理想に近づけていきたい」「開発者としてキャリアを築くために実務経験が欲しい」というものでした。後者については、1 年半以上 Shisho Cloud の開発に携わったことにより達成されつつあると感じています。これからは前者、つまり Shisho Cloud そのものをセキュアに開発するための施策にも取り組み、プロダクトセキュリティの理想を追求していきます。これまでにも新機能の設計時にセキュリティ上の懸念事項を議論したり、プルリクエストに対してセキュリティ観点を含めたレビューをしたりしてきましたが、これからも開発サイクルの様々な工程に対して有効なアプローチを探求し続けます。もちろん、セキュリティプロダクト Shisho Cloud の提供を通じて世の中の開発組織のセキュリティにも貢献していきます。

プロダクトセキュリティの文脈では「開発スピードとセキュリティの両立」がしばしば語られますが、スピードを重要視しているのは Shisho Cloud の開発も同じです。競合製品がメキメキと成長しているこのレッドオーシャンで我々は生き抜かねばなりませんが、一方でそのためにセキュリティを犠牲にするという選択肢は毛頭ありません。このような厳しい環境であっても開発サイクルに伴走してセキュリティを担保し続けることができれば、そのプラクティスは世の中の多くの開発組織でも通用するはずです。

Flatt Security の Shisho Cloud とプロフェッショナルサービスはともに、今大きな転換期にあります。これまではセキュリティの課題を解決する手段の提供に注力してきましたが、これからは個々の手段にとどまらず、そもそも何を守るべきか・なぜ守るべきか・どれほど守れているかなどを、直感ではなく検証可能な事実に基づいて説明できるためのプラットフォームと専門集団へと進化していきます。

blog.flatt.tech

Shisho Cloud はお客様のプロダクトを構成する様々なコンポーネントの情報を集約し、これらの疑問に論理立てて答えるためのプラットフォームへと再設計されます。プロフェッショナルサービスはこの集約された情報をもとに、重点的に守るべきものを合理的に判断し、守るための効果的な手段を提案することができます。その手段はこれまで提供してきたセキュリティ診断に限らず、例えば Shisho Cloud 上の自動検査として実現できるものもあるでしょう。そしてセキュリティ診断で報告したリスクは PDF の報告書に綴じるのみならず、「何がどれほど守られていたか」というデータとしてまた Shisho Cloud に集約される姿を目指します。

Shisho Cloud を活用してプロフェッショナルサービスを進化させ、プロフェッショナルサービスの提供価値を最大化するために Shisho Cloud を進化させようとしているこのフェーズにおいて、セキュリティ診断と Shisho Cloud 開発の両方を経験してきた者として、この共進化に心血を注いでいきたいと考えています。

おわりに

私の技術力やセキュリティへの情熱を養ってくれた TSG および Flatt Security のみなさまに深く感謝を申し上げます。就職活動を通じて技術やキャリアについて様々なことを学ばせてくださった、他企業のエンジニアや人事のみなさまにも厚く御礼申し上げます。時には切磋琢磨し時には励まし合った友人たち、そして生まれてこのかた私を支え続けてくれた家族にも心から感謝しています。

Flatt Security では調達した資金をもとにプロフェッショナルサービスや Shisho Cloud に投資していくべく、セキュリティエンジニア・ソフトウェアエンジニアなど様々な職種に対し積極的に採用活動をしております。この記事を読んで弊社に興味を持った方や一緒に働きたいと感じた方がいらしたら、ぜひ採用情報ページをご覧ください。中途採用・新卒採用・長期インターンなど様々なステージの方を歓迎しております。特に学生の方は、「就活の時期になったら Flatt Security を検討してみよう」ではなく、今インターンとして Flatt Security の一員となることを私は強く勧めます。それは私がここまで述べてきたように、「Flatt Security のが面白い」からです。私や頼もしいメンバーたちと共に、ワクワクする Flatt Security の今を形づくり、プロダクトセキュリティの理想へ前進していきましょう。応募するか迷っている段階でも、カジュアル面談でお気軽にご相談ください。

またこの記事を読んでセキュリティに関心を持った東大生の方がいらしたら、ぜひコンピューター系サークル TSG への入部をご検討ください。初心者向けの勉強会が予定されていますし、技術的に困ったことを相談できる優秀な部員たちとの接点にもなります。近い興味を持った仲間との交流をぜひ深めてください。

ここまでお読みくださりありがとうございました。


  1. ちなみに TSG には難解プログラミング言語でコードゴルフをする文化があり、そのおかげでアセンブリを読むハードルが下がったと思っています。難解プログラミング言語の読み書きを経験していると、アセンブリは読みやすいとすら感じてしまいます。そう、難解プログラミング言語は役に立つのです。
  2. 現在のミッションは「エンジニアの背中を預かる」というフレーズですが、これも開発エンジニアがプロダクト作りそのものに注力できるように Flatt Security がセキュリティ面を支えるというもので、やはり私の考えとの共鳴を感じています。
  3. 振り返ってみると、結局メガベンチャーではなく Flatt Security への入社を決めた後、入社直前に GMO インターネットグループへの参画が決まったので、人生って面白いですね。