こんにちは！SmartHR 品質保証部所属の ark265 、gonkm です。 SmartHR全体のプロダクトを横断的に品質保証業務を行なうチームに所属してます。
今回はQAエンジニアが知識0から始めたセキュリティ分野に挑戦した2年間の取り組みを振り返りつつ記事にしました。 QAエンジニアがセキュリティ分野へチャレンジする時の参考になれば嬉しいです。
なぜQAエンジニアがセキュリティ分野に挑戦しようと思ったのか
QAエンジニアが脆弱性診断を実施した理由と訪れた変化にも書いている内容に補足してお話します。 元々(今も)、脆弱性の発見は年に数回行なう外部のセキュリティベンダーによる脆弱性診断で行なっていました。 しかし、機能テストのようにセキュリティもより早いサイクルでプロダクトチームへ脆弱性などをフィードバックする仕組みを作り上げることができれば、より堅牢性の高いプロダクト開発ひいてはプロダクト開発にセキュリティを意識してもらうことに貢献できると考えたためです。 その思いの下、セキュリティチームとQAチームのサブチームが誕生しました。
知識0からどうやって脆弱性診断ができるようになっていったか
脆弱性診断を始めるメンバーが決まったもののQAエンジニア側には脆弱性診断に関する専門的な知識が0に近かったのでまずはインプットを始めました。 インプットの目標は1年後に手動診断とツールを使用した自動的な診断が一人で行なえる(手動診断の項目洗い出しは必要に応じてセキュリティエンジニアのサポートあり)としました。 インプットと同時にセキュリティエンジニアとペア/モブで脆弱性診断をして業務を通じて理解度を上げていきました。 具体的にやってきたことを以下に記載します。
脆弱性診断に関するインプット
まず、基礎を体系的に学ぶために、「体系的に学ぶ安全なWebアプリケーションの作り方」と「安全なウェブサイトの作り方」を読んで、理解を深めました。その後、OWASP（Open Web Application Security Project）が発行しているOWASP TOP 10やASVSを通じて、最新のトレンドを補いました。実際の診断方法については、OWASP Web Security Testing Guideや、Burp Suiteを提供しているPortSwigger社のWeb Security Academyを利用して学習しました。脆弱性のスコアリングを行なうために共通脆弱性評価システムCVSSの学習も行ないました。
SmartHRの技術スタックに基づいて、Railsセキュリティガイドも参照しました。さらに最近では、「セキュア・バイ・デザイン 安全なソフトウェア設計」や、「ハッキングAPI ―Web APIを攻撃から守るためのテスト技法」の輪読会も定期的に行なっており、技術力の向上を図っています。
定期的な脆弱性診断実施の取り組みのその後
QAエンジニアが脆弱性診断を実施した理由と訪れた変化 の執筆時に引き続き、社内のプロダクトに対して継続的に脆弱性診断を実施しています。新規に開発されたプロダクトは、こちらから声を掛けるよりも開発チームから脆弱性診断の実施依頼をもらうことも多くなり、活動が社内に認知されてきたことを実感しています。中には開発チームと一緒に脆弱性診断のハンズオンを行なうこともありました。
脆弱性診断に利用していたツールも見直しを行なっています。当初はZAPを利用していましたが、現在はBurp Suiteも併用し、各ツールの持つ特色を活かして、より効率的に診断を行なえるようになりました。
また、診断結果の報告書の作成についても、よりわかりやすく、技術スタックによった具体的な改善案を提示することができるようになってきています。
SAST(Static Application Security Testing)導入
脆弱性診断の実施が安定してきたころ、より早くセキュリティに関するフィードバックできる方法を検討して、ソースコードを解析して脆弱性を発見するツールであるSASTを導入することにしました。 弊社ではRuby on Railsを使っているのでBrakemanを導入しました。
導入まで
Brakemanの基本情報と導入するために必要な手順をまとめたドキュメントを作成して、各プロダクトチームへ個別に説明へ行きました。
全てのエンジニアが集まる定例に参加して、Brakemanの導入支援を全体周知して、導入してくれるプロダクトチームを募集しました。
導入してくれるプロダクトチームが決まったら、作成したドキュメントをもとに各プロダクトチームへの説明会を開催して導入に関する懸念事項やすり合わせを行ないました。
導入後にどういった運用をしているかをざっくり説明するとこんな感じです。
BrakemanをCIに組み込んでPull Request毎に静的解析する
検知した問題は原則プロダクトチーム内で解決する
導入後にやっていること
脆弱性診断を担うサブチームでもBrakemanの検知内容や運用状況を把握するために、Brakemanで検知された内容を確認するためのSlackチャンネルを作成しています。 検知内容を確認して必要に応じて開発チームとコミュニケーションを取り、解決に向かうためのサポートを行ないます。
これから挑戦してようとしていること
脆弱性診断の自動化
これから挑戦していきたいことの一つが、脆弱性診断の自動化です。現在は脆弱性診断のプロセスの多くを人手で行なっていますが、自動化することによって定期的に診断を行えるようになれば、今以上にセキュリティリスクの早期発見とプロダクトセキュリティの継続的な向上に寄与できると期待しています。もちろんこの取り組みには、診断ツールの選定や環境構築、診断項目抽出や結果の蓄積と分析など、様々な課題がありますが、これらをクリアしていくことで、より安定した脆弱性診断を行なえるようになると考えています。取り組みの経過や成果については、今後のブログで報告していけたらと思います。
Brakemanの効果測定・検出内容の可視化
Brakemanを導入して検出した脆弱性の修正が行なえるようになりました。 次のステップとしてチャレンジとして検出された内容をデータとして貯めていき可視化することで、作り込んでしまう脆弱性の傾向を可視化したり、Brakemanが実際にどれだけ効果が出ているかを測定することに挑戦していこうと思います。
We are Hiring !
最後まで記事を読んでいただき、ありがとうございました。 SmartHRのQAエンジニア、セキュリティエンジニアに興味を持っていただけましたら、下記の採用サイトからエントリーいただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気軽に聞きにきていただけたら嬉しいです。 みなさまとお話できることを楽しみにしております。
hello-world.smarthr.co.jp
QAエンジニア（リーダー候補） / 株式会社SmartHR
QAエンジニア / 株式会社SmartHR
セキュリティエンジニア / 株式会社SmartHR
