はじめに
こんにちは！創価大学理工学研究科 博士前期課程1年の須藤智也です。
この度は8月から6週間、セキュリティアセスメントチームでインターンをさせて頂きました。
このレポートでは、私がチームの一員として取り組ませていただいた内容を紹介します！
SATについて
セキュリティアセスメントチーム（SAT・旧アプリケーションセキュリティチーム）は、LINEのアプリケーションセキュリティを担うチームです。
業務内容については河岡さんをはじめとする他のインターン生のブログで紹介されているので、私はその中のRA（リスクアセスメント）に絞って紹介したいと思います。
RAとは、主にLINEで提供しているソフトウェアのセキュリティ診断を行い、脆弱性が含まれていないかをチェックする業務です。
あるサービスがリリースされるまでに開発の段階ごとに様々なチェックを受けます。RAはその一つであり、リリース前に実装上の欠陥や脆弱性がないかをチェックします。
主にチェックはソースコードや仕様の静的解析と、実際の開発サービスの動作を検証する動的解析によって行われます。
そして、問題が見つかれば開発者に修正依頼を出し、修正を確認された後にサービスを公開されます。
以上のステップでサービス公開前にチェックを行うことで、潜在するリスクや脆弱性を軽減し、セキュリティ上の品質を向上させています。
RAにおける課題
SATに配属されてからおよそ2週間は、チームに混ざってRAを担当させていただきました。
この経験を踏まえ、インターンシップの残りの期間で自分がプロジェクトで取り組めることを考えました。
特にSATはソフトウェアのセキュリティを担う役割を持っているため、そこに対しての貢献がしたいと考えていました。
私はまず、チームでの恒常的な業務であるRAに注目しました。
RAは通常、個人または少人数の担当者に割り振られます。割り当てられたタスクが複数の領域にまたがる場合や最新のプラットフォームを利用したサービスの診断には、より高度な知識やテクニックが求められます。
チームメンバーが得意な領域も様々で、GraphQLの調査からAndroidの動的解析まで様々あります。個人が勉強会やセミナーに参加し、独自にスキルアップをして技術を磨いています。
そのため、塞ぐことのできるセキュリティホールが担当者によって左右されることが問題となるのではないかと考えました。
加えて、RAはサービスの大部分の開発が終了し、リリース前の最後の段階として実施される場合もあります。
この時にRAにかけられる時間はリリース時間に直結するため、チーム内でのRAの効率性に関わるテクニックの共有も全体として有効な要素だと考えました。
この課題はすでに認識されており（参考）、その解決のための特効薬としてチーム内で準備しているのがSIMS (Security Issue Management System)です。
SIMSは開発現場で用いられていたチケット管理サービスを置き換えるもので、RAに特化したチケット管理プラットフォームです。SIMSではRAに効率的に取り組むための自動スキャナやターゲットのリポジトリ情報を表示する機能があります。
私が最初に考えたプロジェクトは、個々のRA担当者が脆弱性を検出する過程を共有することを目指していました。
RAでは、脆弱性が発見されると新たなチケット（タスクを可視化するもの）を発行し、サービスの開発者に渡します。チケットにはサービスのどの部分に、どんな脆弱性が含まれているか、また推奨される解決策といった情報をつけます。
サービスの開発者にとっては、RAの結果として脆弱性が含まれていたという情報を元に修正することができます。
しかし、他のRA担当者にとっては結果という側面ではなくRAにおいて脆弱性を見つける過程こそがより有益な情報につながるのではないかと考えました。
私はチケットに脆弱性を見つける過程・手法の情報を追加することを提案しました。
例えば、「Burp Suiteというツールの特定のエラーログに注目した」「ソースコードのログイン処理を追った」といった一言のメモをセキュリティチケットに付け加えます。
これにより、有用なツールやテクニックの発掘や明文化が促進され、全体としての知識のベースラインが向上すると考えました。
他のSATメンバーが作成した脆弱性チケットは、似たサービスのRAを担当するときなどにも参照されています。過去に発見された脆弱性の情報を今後に繋げ、よりRAのパフォーマンスを向上させていくことができるのではないかと考えました。
この提案は、既存のチケット管理プラットフォームあるいはSIMSに新たなテキストフィールドを加えることで実装できると考えていました。
しかし、この提案をまとめてチームで意見を募ったところ、私が見落としていた重要な視点を指摘していただきました。
特に核心をついていた意見は、"一言メモ"が個人の裁量に委ねられているという点です。「脆弱性をどのようにして発見したか」という部分は今まで非言語的に蓄えられてきたものであり、その全てを文章にできるわけではありません。革新的な記法が私の提案には必要だということがわかりました。
同時に、過去の知識を共有するという取り組みがあったことも教えていただきました。チーム内で定期的に開かれていた勉強会や外部のイベント、ドキュメント整備の試みも教えていただきました。（実際に社内のBecksというイベントにも参加させていただきました。）
そこで、言語的なコミュニケーションの増加ではなく、ツール主体でのコミュニケーションの促進に焦点を当てることにしました。
SAT-Tools
私はSAT-Toolsを提案しました。SAT-Toolsは、RAをはじめとするセキュリティ診断で用いられるセキュリティ診断ツールやパターン・ルールセットを一元的に管理するリポジトリです。
セキュリティ診断におけるツールは静的解析ではGitleaks・Semgrep、動的解析ではdirsearch・Frida・Burp Suiteなどとても便利なものが開発されています。
こうしたツールを活用することは、大規模なソフトウェアに対しセキュリティ診断を行う上での強力な武器となります。
すでにツールを管理するといった試みはaptやbrewといったパッケージマネージャや、ctf-toolsなどですでに実施されています。この利点をSATチームにもたらすことで、単なるツールを管理すること以上に、チームでの活用知識を育んでいくことができると考えました。
また、SAT-Toolsはパターンやルールセットの管理も目的としています。
脆弱性を発見した際に原因となったソースコードや実装のパターンを収集・管理することで、同様のアンチパターンを他のサービスでも検証することができます。
特定のサービスに対するRAの貢献が他のサービスでも還元されることで、チェックのカバー率を底上げすることを目指しています。
下はSAT-Toolsを実際に使用した際のイメージです。
上では、コマンドとして
「docker run -it -v `pwd`/target:/sat-tools/target --rm sat-tools -c sast <対象のgitリポジトリ>」
を入力し、SAST（静的解析）として登録したgitleaksを診断対象のリポジトリ（https://github.com/...）に対して実行しています。
実行結果として、8つの警告が見つかりました。
内部の動作の手順は以下のとおりです。
1. Dockerでsat-toolsを起動し、target/ディレクトリをマウントする
2. Dockerのentrypointとして指定されている、sat-tools（実行ファイル）がコマンド「sat-tools -c sast <対象のgitリポジトリ>」を受け取る
3. gitで<対象のgitリポジトリ>をクローンする
4. core/inter.pyがsastとして登録されたgitleaksをクローンしたリポジトリに対して実行する
このように、強力なツールをさらに便利に使うことができるようにすることが、SAT-Toolsの目標の一つです。
設計・実装
SAT-Toolsはその目的上、チームの全員が使い勝手の良いツールでなくてはなりません。多種多様なツールを試すという動作上、Dockerイメージとして用意することにしました。
多種多様なセキュリティ診断ツールを一つのプラットフォームで管理するためには、それぞれのツールの使い勝手を統一することが課題です。
特にツールのインストールは様々で、ソースコードからのビルド、pipでのインストールなどツールが推奨するインストールを統合する必要がありました。
SAT-Toolsでは、インストールとアンインストールのコマンドを抽象化し、統一されたコマンド（install (clean) <ツール名>）で扱えるようにしました。
各ツールの管理は、configファイルを設定することで対処しました。具体的な各種ツールの設定はツールごとのフォルダにまとめ、SAT-Toolsからの呼び出し方に対応するスクリプトを用意することで、新たに管理するツールを増やすことができます。例えば、GitLeaksを追加したいときは、以下の情報をconfigファイルに追加します。
config.json
{
"name": "gitleaks",
"fullname": "Gitleaks",
"tags": [
"preinstall",
"sast"
],
"path": "tools/sast/gitleaks",
"bin": "gitleaks",
"install": "bash install",
"run": "bash run",
"clean": "bash clean"
},そして、install, run, cleanに対応したスクリプトを用意します。configファイルにそのコマンドの実行方法を記述できるのですが、ここではシェルスクリプトを使うことにします。
・install: gitleaksをインストールします。zipファイルをダウンロードし、解凍して得た実行ファイルへのリンクをSAT-Tools内のbinフォルダから貼ります。
・run: デフォルトのオプションを指定してgitleaksを実行します。
・clean: install時に作成したリンクとファイルを消去します。
この手順で、新しいツールを追加できます。
最終的に、SAT-Toolsを以下のように設計しました。
Directory tree
sat-tools
├── Dockerfile
├── Makefile
├── README.md
├── core
│ ├── bin
│ ├── config.py
│ ├── entry.py
│ ├── inter.py
│ ├── sast.py
│ └── sat-config-default.json
├── docs
├── results
├── sat-config
├── sat-tools
├── target
└── tools
├── dast
└── sast
└── gitleaks
├── clean
├── install
└── runルールセットの管理
SAT-Toolsはツールの管理に加えて、ルールセットの管理も行います。ここでは、Semgrepを例に取って説明します。
Semgrepはソースコードにおける文法的なパターンとそれが引き起こす脆弱性のルールを登録しておき、セキュリティ診断の対象に一度にフィルタリングをすることができるツールです。
ルールセットはプログラミング言語やプラットフォーム毎の階層構造のディレクトリに格納されており、YAMLファイルと適用例のスクリプトファイルのペアとして保存されています。
このルールセットもSAT-Toolsで管理することで、ルールセットの管理も行うことができます。
└── sast
├── gitleaks
└── semgrep
├── clean
├── install
├── semgrep-rules (submodule)
└── run新たなルールの追加等は管理用リポジトリに対するPull Requestによって実現します。
例えば、KotlinにおけるMD5の使用を検出したい場合、Semgrep Ruleの文法に沿ってuse-of-md5.yamlを記述し、テスト用のKotlinスクリプトとしてuse-of-md5.ktを作成します。
Semgrepのテスト用スクリプトに準拠したファイルを用意することで、Semgrepに用意された機能であるルールの検証を実行できます。
Pull RequestをトリガーとしてGitHub Actionsでチェックを行い、自動的にマージされます。
以上のようにSemgrepのルールの管理をSAT-Toolsの仕組みに組み込むことで、ルールセットの管理が実現されます。
自動スキャンを行う上でのSemgrepのルール（文法上のパターン）は、危険なコードや脆弱性を表します。
False Positiveによって不必要なアラートを減らすために、そのパターンが見つかったら「ほぼ間違いなく脆弱性が存在する」というような信頼度の高いルールが求められます。
一方、セキュリティ診断の際に用いるSemgrepでは人手で脆弱性の診断を行うため、ある程度信頼性に幅を持たせた「セキュリティ診断において注視すべき、脆弱性につながる可能性のある」ルールが求められます。
ある脆弱性が発見されたときに、その発見の手掛かりとなったソースコード上の記述（パターン）は脆弱性診断における脆弱性の検出の過程と対応します。
これらのルールをチーム内で共有することで、各診断者がこれまで持っていた独自のパターン（注視している記述）をチーム内で共有できます。
チームにおけるルールセットの統一によってソースコード中の注視すべき記述・パターンをルールという形で共有でき、チーム内の別の診断者はパターンの詳細を理解せずとも使用することができます。
そのルールによって検出されたパターンがセキュリティ上の問題になるかどうかはそれぞれの診断員が判断するか、そのルールを追加したチームメンバーに問い合わせることができます。
非言語的な知識の共有によって、コミュニケーションコストを抑えつつRAの品質のベースラインを向上させることを目指しています。
まとめ
SAT-Toolsの真価が問われるのは、実際の現場においてどのように活用されるかにあります。
この記事を投稿する時点では、まだインターンの期間が残っているため、実RAに役立てるか・改善点がないかを調査していきたいと考えています。
既知の改善点としては、以下のようなことが考えられます。
・Docker内でプライベートリポジトリをクローンする際のGit認証情報の管理
・社内で管理されているリポジトリは全てプライベートなリポジトリです。そのクローンを内部で行いたい場合は、Docker Secretや設定ファイルをツールから読み込むように設定するなど追加の対応策が必要です。
・診断対象のtarget/ディレクトリはDocker VolumeでホストとマウントしているためSAT-Toolsの管理外でクローンでき、内製のツールをSAT-Toolsで管理する場合はGitのサブモジュールとしてSAT-Toolsと同時にクローンする方法も存在します。
・SAT-Toolsがより多くのツールを管理するようになる場合、さらに柔軟な管理・実行が求められることがありそうです。
・現状、誰でもツールをSAT-Toolsに追加しやすいようにするため、導入方法のドキュメントを整理することにとどめていますが、より大規模になっていった場合にはツールの管理に関して仕組みづくりをする必要がありそうです。
以上、今回のインターンでのプロジェクトとして、SAT-Toolsを提案させて頂きました。
セキュリティ診断に欠かせない"ツール"という武器に対し、よりその力強さを増幅させるツールを目指しました。
本提案やSIMSを含めた様々な取り組みがRAをさらに高度・効率化させ、LINEのサービスがより安心できるものになる助けになればと思っています。
インターン生として感じたこと
私はこのインターンシップ中、実に多くのことを経験させていただきました。
LINEでの働き方や様々な機器を用いてのセキュリティ診断の手法を教えていただき、実際にRAにも参加させていただきました。
RAでは実機・仮想Android端末を用いての動作検証、プロキシツールを活用したセキュリティ診断の他、ソースコードを読んでチェックする静的解析も行うことができました。
ソースコードを読むのが好きな私にとって、セキュリティ担当者がソースコードを見ることができる環境は非常に有益でした。
実際に認証フローを追って行ってアクセス制御やSQLインジェクションといったのセキュリティホールを防ぐことができ、大規模なサービスに対する貢献ができたのはとても良い経験でした！
このインターンシップ全体を通して、様々な人と関わる機会もありました。
メンターの方からはチームへのOnboardingからプロジェクトに対するサポートまでとてもお世話になりました。
インターンを進めるにあたって必要な情報を整理しドキュメント化していただいた他、ミーティングでの進捗確認では適切なコメントを頂いてプロジェクトを進めることができました。
また、SATは様々なバックグラウンドを持つメンバーが集まっているためか、チーム内の雰囲気が開かれており、安心して様々なことに挑戦できました。
インターン期間、1メンバーとして業務に参加する中で、制度・規則を超えた働きやすさを感じていました。
その要素として、インターンの期間中に開かれたSATの交流会（フランクな飲み会です）で、隣の席だったメンバーの方の言葉を思い出します。（その方は日本出身ではないのですが、日本語で流暢に話しかけて頂きました）
「このチームの人は、みんな優しい。それは、みんながお互いを尊敬しているから。（上長さん）も優秀だし、（他のメンバーの方）も優秀。みんながお互いを認めて尊敬しているから、このチームはみんな優しい。」
私がインターンを参加した期間は合併を間近に控えており、両企業が合併後のビジョンについて話し合うミーティングがありました。
そこでLINEのCTO（当時）がLINEのエンジニアカルチャーを共有したのですが、その中の一つに「Trust & Respect」がありました。
インターンを始めるまでは、なぜ企業が企業理念を掲げるのか・それが現場や実製品にどう関わってくるのかについて、私はあまり実感を持てていませんでした。
しかし今回、「Trust & Respect」が浸透するチームでインターン期間を過ごした中で、この考え方によって安心して業務に取り組み、建設的な挑戦をできるということを身をもって体験することができました。
重ねてになりますが、私が今回のインターンに全力で取り組むことができたのは、周囲の方々に本当に恵まれ、支えていただいたためだと実感しています。
過去のインターン生の記事がなかったら、もしかしたらセキュリティを志すきっかけはなかったかも知れません。
インターン期間中もメンターの方々に大変お世話になったことは言うまでもありませんが、他のチームから相談に乗ってくださったエンジニアの方、同期のインターン生にたくさん励まされました。
特に、同じチームでインターンをされていた方は経験が深く、とても心強かったです。（その方の記事はよりセキュリティに対して興味深い内容となっているので、ぜひ見てみてください！）
この記事が将来、LINEやセキュリティを志す未来のエンジニアの成長のきっかけとなることを願って、この記事を結びます。