アドウェイズもDevSecOpsを導入してシフトレフトしていきます

こんにちは。技術本部の非機能領域を担当するチームでユニットマネージャーをしています、奥村(@arumuko)です。
現在はセキュリティ関連の業務を中心に取り組んでいます。過去にはセキュリティ施策の価値の定量化の記事を執筆しました。

チームとしてはパブリッククラウドのセキュリティ向上の取り組みなどを行っていました。

今回は最近メインで取り組んでいるDevSecOpsの導入・文化醸成について執筆します。
まだ、道半ばなので「こうすればうまくいったよ！」は書けないですが、ひとつの事例として参考になる部分はあると思いますので是非ご一読ください。

DevSecOpsとは
背景
推進の全体像
これまでやってきたこと
今やっていること
- セキュアコーディングツール検証
- パッケージ脆弱性の可視化
課題
- フェーズ×チームの組み合わせが多いので時間が掛かる
- 説明が難しい
展望
まとめ

DevSecOpsとは

DevSecOpsは要件定義・設計〜保守・運用までのシステム開発のライフサイクル全体にセキュリティを適用するアプローチです。
システム開発のライフサイクルの各フェーズにおいて、適切なセキュリティを適用することにより、システム全体のセキュリティを向上させることを目指します。
DevSecOpsは、セキュリティチェックをCIに統合するなど自動化し、継続的な監視と対応を実装することで、安全なソフトウェアをより速く、より効率的に提供します。

フェーズは下記があります。

プラン
開発(code)
ビルド
テスト
リリース
デプロイ
運用
監視

手段をベースにしたパイプラインは OWASP DevSecOps Guidelineが参考になると思います。

導入のメリットは以下が挙げられます。

自動化されたセキュリティが導入されていることにより、セキュリティトラブルに対処するプロセスを短縮し、時間とコストを節約できる
DevSecOps環境を整備しておくことは、結果的に生産性の向上に繋がる
セキュリティ対応を開発の初期段階から前倒しで行うこと（シフトレフト）により、セキュリティ対策のコスト削減に繋がる

背景

世間的にシステムの脆弱性を悪用した攻撃が増加してきている状況の中で、セキュリティガードレールを中心としたセキュリティ対策(過去記事)を行ってきました。セキュリティ対策を行っている中で、DevSecOpsというアプローチを知りました。

セキュリティガードレールのような運用フェーズでのセキュリティ対策だけでなく、開発フェーズでのセキュリティ対策も行う事を目指したいと考え導入を推進する事を決めました。
システム開発のライフサイクル初期段階からセキュリティ対策を実施し、脆弱性が入り込まないようにする手法にシフトすることでセキュリティリスクの低減ができると考えました。

他にも以下の様な考えがありました。

開発チームが開発も運用も行っており、DevOpsができているので、DevSecOpsもフィットするだろうと考えた
IaC化、CI/CDがほとんどのサービスで実施できているので導入しやすい
DevSecOpsを導入することで開発者のセキュリティに対する感度を上げていきたい

推進の全体像

私のチームは技術本部という部署の中で「革新的な開発者体験で、エンジニアの仕事価値を飛躍させる」というミッションを持って活動をしています。
基本的に、全体最適や全体に関わる環境の改善などを行っております。
DevSecOps導入推進も同じく、開発組織に存在する各チームでDevSecOpsが取り入れられる事を目指します。

なので基本的な流れは、全体に適用するという前提で、計画 -> 手段の検証 -> 選定 -> スモール展開 -> 全体展開になります。

これまでやってきたこと

今まで行った事を紹介します。

DevSecOpsについてのチーム内勉強会

まずは、導入を推進する私のチーム内のDevSecOpsに対する理解度を向上させるために、チーム内勉強会を開催しました。
資料を各自で確認し感想や意見交換を行いました。資料は以下を参考にさせて頂きました。

DevSecOps説明資料作成

勉強会で得た知見を元に、開発チームにDevSecOpsとは何かを説明するための資料を作成しました。
インターネットで都度検索したりすると解釈がぶれたりするので、大きめの改善や新しい手法を取り入れる時は最初に説明資料を作るようにしています。

資料には以下が記載されています。

DevSecOpsとは何か
DevSecOpsを導入するメリット
各フェーズでのセキュリティ施策について
既存セキュリティ施策との関連性について
導入方針

Pre-commitフェーズで用いるツールの選定とサンプルの準備

具体的な施策の1弾として、Pre-commitフェーズで用いるツールの選定とチームで利用するためのツールとサンプルを準備しました。

awslabs/git-secretsの通常のスキャンに加えて、独自に作成した、禁止及び、許可のパターンファイルをプロダイバーとして追加するというのを行っています。
Macを前提として git-secrets をセットアップするシェルスクリプトを作成しました。
また、パターンファイルを暗号化してチームで共有できるような仕組みにしています。

この取り組みについては別の記事で紹介できればと思います。

IaC解析、コンテナ解析の部分導入

フェーズとしては飛びますが、DevSecOps導入推進以前からチーム内で導入実績のあった、IaC解析の tfsec や、コンテナ解析のtrivyを開発チームが管理しているリポジトリに導入しました。

導入できる開発チームと調整し、CI/CDに組み込む形での導入を行っています。

今やっていること

今取り組んでいる事を紹介します。

セキュアコーディングツール検証

開発(code)フェーズでの取り組みとして、セキュアコーディングを行うためのツールの選定と導入推進に取り組んでいます。

現在はSnykのIDEプラグイン版の検証利用展開を行っております。

パッケージ脆弱性の可視化

こちらもフェーズとしては飛びますが、デプロイフェーズのセキュリティスキャンとして、Amazon Inspectorを用いた、EC2のパッケージ脆弱性の可視化を行っております。

全AWSアカウントの情報を集約したデータを用いて、Looker Studioで脆弱性状況の可視化を行っており、EC2に内在するパッケージの脆弱性が一覧で把握できるようになっています。
また、SSMインベントリの情報とEC2の情報を取得、加工し、スキャン可能状態かどうかの可視化も行っており、何割のインスタンスでInspectorによるスキャンが行えているのかも可視化しています。
その情報を元に、各開発チームでSSM Agentの導入やIAMロール付与の対応を行っており、スキャン率向上にも取り組んでおります。

課題

私が感じているDevSecOps導入推進における課題を2点紹介します。

フェーズ×チームの組み合わせが多いので時間が掛かる

前述した通り、DevSecOpsは8つのフェーズが存在します。また、それぞれのフェーズでも複数の対象領域や手段があります。
フェーズ、対象領域、手段の多さに加えて、複数のチームでの導入を目指しているので、どうしても時間が掛かります。

また、チームの状況やサービスの性質も様々なので、それぞれの環境に合わせた考慮も必要になります。
かと言って、抽象的な指示を出して、後は開発チーム任せにするのも、全体最適の観点や知見醸成の観点からすると良くないと考えています。

チームの状況などを考慮すると、取り組んだ事の紹介にあったように、IaC解析やコンテナ解析やパッケージ脆弱性可視化など、ビルドフェーズ、デプロイフェーズでの施策が先行する事があります。
フェーズ毎に進めずに、DevSecOpsの全フェーズで特に価値のありそうなフェーズから取り組んでいるような状況です。

説明が難しい

DevSecOpsだけでなく、セキュリティ全般に言えることかもしれませんが、何故そのツールや施策なのかの説明が難しい場合があります。
セキュリティ対策が必要な事も理解しているし、導入することにも前向きではあるが、「何故その手段なのか」は説明が必要です。
セキュリティの領域を任されているチームが説明するのは当然ですが、説明される側はそれがいかに価値のあるものなのかを判断するのが難しいのだと思います。
セキュリティや信頼性などの非機能領域はコストと品質のトレードオフが発生するのでさらに難しいです。

なのでスモールスタートや一時利用などを行い、その手段がどれほどに価値があるのかを早く、明確にするのが必要だと考えています。
私のチームでもスモールスタートを前提として施策の推進をすることがよくあります。