見出し画像

「『自己流』コードリーディング勉強会」を開いた話

GMO Flatt Security株式会社

こんにちは、GMO Flatt Securityの松井(@ryotaromosao)です。昨年9月に内定者インターンとしてジョインし、4月から新卒正社員となる予定です。普段はセキュリティエンジニアとして、Webアプリケーションの脆弱性診断をしています。

今回の記事では、先日社内で「コードリーディング勉強会」を開いた話をしたいと思います。


GMO Flatt Securityの脆弱性診断の特徴

弊社の脆弱性診断の一番の特徴は、何といっても「ソースコード診断無料付帯」だと私は考えています。一般的に、ソースコードを参照するホワイトボックス診断は、ブラックボックス診断に対して高価なオプションであることが多いのですが、弊社では、通常のWebアプリケーション診断（ブラックボックス）と同じ料金で、ホワイトボックス診断の要素も組み合わせながら診断を行います。

これにより、診断スピードや正確性、報告書の品質向上といったメリットがあり、一方で診断するエンジニアは技術力を高めやすくなります。お客様と弊社双方にとってWin-Winというわけです。

この方針を実施するために、ソースコードのリーディング力が弊社の診断員にとってとても重要になってきます。
以下のページにより詳細な説明がされていますので、ご興味のある方は是非ご覧ください。

ソースコードの読み方は人それぞれ

弊社に入社すれば、何か統一された革新的なコードリーディング方法に沿って全員診断を実施していくのか、というとそうではありません。

routeから読んでいくのか、controllerを探すのか、もしくは実際にアプリケーションを触ってみてそのリクエストから追っていくか、読み方は人それぞれです。

インターンとして入社したこともあり、いきなり実案件に責任を持つことはなくまずは先輩と一緒に診断プロジェクトに参加します。その中で、最初は他人が書いたソースコードの読み方なんて分からずに我流で試行錯誤していて、「コードの読み方」について自分の中で答えを見つけられずにいました。

「『自己流』コードリーディング勉強会」の開催

そこで、まずは色々な人にコードリーディングの方法を聞いてみて、自分に一番合った方法を見つけようと思い、勉強会を開くことにしました。

勉強会を開くことは初めてだったのですが、プロダクト企業のセキュリティ出身、セキュリティベンダー出身、開発出身とそれぞれ異なったバックグラウンドを持つGa_ryo_さん（@Ga_ryo_）、fujirさん、lambdasawaさん（@lambdasawa）にお願いしました。これにより多様なメンバーの「自己流」を学ぶことが可能です。

勉強会の様子

実際にGitHub上のOSSのソースコードを参照しながら、ペアコーディングならぬペアリーディング的にソースコードの読み方を教えてもらいました。　　　　　　　　　　　　　　　　　　　　　　　　　　

簡易議事録

以下では勉強会で特に盛り上がったトピックについて議事録形式で紹介します。あくまでも簡易的なログなので、より詳細なコンテンツは追ってイベントや技術ブログで解説できればと思います。

また、あくまで「自己流」の紹介であるため以下に書いてあることが常に正解とは限りません。自分に合ったスタイルが重要です。

飛ばしながら読むのが正義か

一般的なコードリーディングは飛ばしながら読むといいと言われることが多いが、診断目的の場合は基本的には全部読んだ方が良い。もちろんUI部分は読まなくていい場合が多いが、そうでない場合は飛ばせば飛ばすほど何も分からなくなる上、以下のデメリットがある。

  • 思い込み（飛ばした部分の脳内補完）のせいで脆弱性が見つからない

  • いざ重い処理が出てきた時に読み切る筋肉が一生付かない

また、そもそもソースコードを読み慣れていない人が、どこを飛ばしていいのか判断することは難しく、読み飛ばした部分に脆弱性があった時にはお客様からの信頼を失ってしまうことになる。

環境整備の話

コードリーディングは未知の情報を無限にインプットする行為であるため、脳内キャッシュが生きているうちに次のコードを読むことが重要。そのために重要なのがコードリーディングのための環境整備。

  • 弊社ではIDEツールとしてIntelliJを推奨

    • VS Codeでもタグジャンプは可能だが、そのための設定が必要であることが多い。IntelliJではデフォルトの設定でタグジャンプができるため、非常に便利

  • タグジャンプでの行き来を素早くするために、トラックボールや自作キーボードを使ってる社員も多い

コードリーディング

以下が、Ga_ryo_さんが行っているコードリーディングのフロー。まず、目grepで全てのファイルを参照し、脆弱性がありそうな箇所に当たりをつける。その後、ソースコードを見に行き、実際にアプリケーションを触っていく。

  1. 目grep
    まずはすべてのファイルを開いて目を通す。正規表現や、異常な文字列など脆弱性のありそうな箇所にブックマークをつけ、脳内indexを貼る。これもスピード感が重要で、環境整備が必須。

  2. routeを読む
    routeを探して読んでいく。読んだ箇所にはBreakPointを貼り、チェックをつける。そうすることで共通の処理は再度読まなくて済む。（ここら辺からアプリを触っても良いが、まだ触らない）

  3. 怪しそうな機能や、認証・認可のコードを読む
    特にユーザー入力のある箇所やAPI、認証・認可のコードをまず読む。

  4. 実際にアプリケーションを触る

コード読みの気持ち

ソースコードを速く正確に読むために、以下の二つを意識できるととても良い。

  • アプリケーションの全体像を掴む
    （脆弱性を探すことが目標ではあるが）脆弱性を探すことだけを目的にして読んでいくと、アプリケーションの全体像やロジックが掴めないことが多い。なので上記のように、一旦目grepで全体像を掴むようなステップがあると良い。

  • 常に全力で読まない
    重い実装も軽い実装も常に全力で読んでいると、どうしても疲れてしまう。なので、常に100%で読むのではなく、例えば簡単そうな実装から読んでいって、重そうな実装は本気で読む！といったメリハリが重要。

おわりに

本ブログでは、「『自己流』コードリーディング勉強会」を開いたお話をしました。今回、勉強会を開いたことで新しいノウハウを多く得ることができました。この勉強会はセキュリティエンジニアからとても好評であり、第2回の開催も予定しています。

弊社には技術力の高いエンジニアが多く在籍しており、多くのことを吸収できる環境が整っています。内定者インターン生である自分ができたように、誰でも勉強会を開くこともできます。今回のように自分が教えてもらうための勉強会を開くことも可能です。

そんな弊社では積極的に採用を募集しています。技術力を高められる環境に身を置いてみませんか？

弊社では26卒セキュリティエンジニアを積極募集中です。業務内容や求める人物像などご説明できますので、気になる方はぜひ新卒採用情報ページをご覧ください！

また、記事を読んで弊社に興味を持ってくださった中途の方は採用情報ページをぜひご覧ください。カジュアル面談も大歓迎です！まずは説明を聞いてみたい、というだけでもお気軽にお申し込みください。

ここまでお読みいただきありがとうございました！

いいなと思ったら応援しよう！