はじめに
この記事は「セッションを聞いたけども、よくわからなかった」や「ちょっと考えを整理していきたい」などGoogle Cloud Next Tokyo 2023 Day1で見聞きしたことをまとめていく記事です。
今回はDevSecOpsにまつわるセキュリティの話をCI/CDと絡めてまとめることができたらと思います。
どんな用語が出てきたかをまずは整理
まずは下記の用語が何回か登場しました。
- CI/CD
- ソフトウェアサプライチェーン
- DevOps
- シフトレフト
- DevSecOps
- SAST
- SCA
- DAST
順番に見ていきます。
重要なこと
用語を確認する前に結論言います。
DevSecOpsに必要なことは何かといえば、開発サイドがセキュリティの重要性を知ることであり、セキュリティを適用するタイミングをより早くすることです。
今回は用語をおさらいしていきますが、この記事ではDevSecOpsに必要なことを知ることが目的です。
DevSecOpsとは何かという以前にDevOpsが何かを知る必要があり、DevOpsを知るためにはCI/CDを知る必要があります。CI/CDを知るためにはソフトウェアサプライチェーンを知る必要があります。
まずは「CI/CDとは」について見ていきましょう。
CI/CDとは
CI/CDはContinuous Integration/Continuous Delivery or Continuous Deploymentの略称です。 一連の開発プロセスを自動化して継続的にデプロイを繰り返すという技術/概念とも言えます。
CI/CDを導入することで開発してから実際にユーザに届くまでの時間を短縮することにつながりました。
そして、ソフトウェアを開発してユーザに届けるまでのこのプロセスをソフトウェアサプライチェーンと呼びます。
ソフトウェアサプライチェーンの適用範囲
このOSS時代においてソフトウェアサプライチェーンの適用範囲はとても広いものとなっています。
以下のような要素がソフトウェアの構成要素となっていることがソフトウェアサプライチェーンの適用範囲を広げている要因となっています。
- 自分のプロジェクトのコード
- OSSのコード
- 購入したコード
- 退職者が書いたコード
- ネットやAIが書いたコード
OSS時代においては不特定多数の人間もしくは機械がコードを記述し、それらがソフトウェアに組み込まれます。
DevOpsとは
CI/CDによるリリース速度の高速化と円滑なソフトウェアサプライチェーンによりスピーディなシステム開発が運用と両立してできるようになりました。これがDevOpsです。
しかし、DevOpsにはセキュリティという重要な観点が抜けており
たとえば、リリース後に重大な脆弱性が発覚してサイバー攻撃の足掛かりとなってしまうことがあります。
なお、昨今においてはサイバー攻撃の8割はソフトウェアの脆弱性が原因とされていますが
セキュリティ対策を施す製品はネットワークやエンドポイントのセキュリティが多いです。
DevOpsの考えにセキュリティの概念を取り入れるため、開発の各工程にセキュリティ対策を施すようになりました。これをシフトレフトと言います。
補足：なぜ、DevOpsにはセキュリティが欠けているのか
前述の通り、DevOpsにはセキュリティという概念が欠けています。
それはなぜでしょうか。DevOpsそのもののコンセプトの問題？考案した人の思慮の浅さが原因？
諸説ありますが、一つ言えることとしてはセキュリティの重要性が認識されていないことにあると考えられます。または開発者がセキュリティに詳しくないのでどうしようもないということもあるとも考えられます。
DevOpsの場合においてはリリースした後にスモークテストなりを実施する方式をとっています。
つまりはリリースした後に発覚することが前提、当たり前になっています。
DevSecOpsの誕生
ここまで来るとDevSecOpsがどういうものかわかってきたと思いますが
ここで一つちょっとした例えを出してみましょう。
もし、あなたが何かしらの成果物を完成度の高い状態で出した時に「そもそも〜はだめなんだよ」みたいな聞いてもいない前提をもとにダメ出しをされたらどうでしょうか。
そして、それを作り直すとなったらどうでしょうか。
容易に想像がつくと思いますが、手戻りの工数は測りしれません。作り直すとなった場合はかかった工数と同じくらいかもしくはそれ以上の工数がかかるかもしれません。
運が良ければ、作ったものを少し直すだけで済むかもしれませんが、多くの場合は最初から作るか大幅な修正を余儀なくされるでしょう。
ではここで成果物を作る工程毎に指摘を入れてみたらどうでしょうか。
おそらく、最終成果物における手戻りはかなり減ると考えられます。
そう！DevSecOpsというのはつまり、開発から運用までの各工程でスキャンを挟むことで頻繁にダメ出しを行い、セキュリティ的に良くないことを修正していくことになります。
DevSecOpsを実現するには
具体的には以下の項目を満たしておく必要があると考えられます。
- SAST
- SCA
- DAST
- 他
- secretのハードコートを防ぐ
- インフラを正しく設定する
SAST（静的アプリケーション解析）
まずはSAST、ソースコードだけを見て脆弱性がないかを見つける解析手法、もしくはツールのことです。ソフトウェアを動かすことなく実行する解析であることが最大の特徴です。
SCA（ソフトウェアコンポジション解析）
ソフトウェアを構成するコンポーネント（OSS、ライブラリ、パッケージ）などから脆弱性を見つける解析手法、もしくはツールのことです。SCAを実施した後は代替のライブラリに対してタイムリーに切り替える必要があります。
DAST（動的にアプリケーション解析）
静的解析ではわからなかったランタイムの脆弱性を見つける解析手法、ツールのことです。
実際に動かしてみて解析するところが特徴となります。
ソフトウェアのテストをしたことがある人はわかると思いますが、実際に実行してカバレッジ（網羅率）を出すのと似ています。
他
他は当たり前のことだと考えられますが、もしかしたらよくやってしまう？ことでもあるので紹介します。
secretのハードコートを防ぐ
たとえば、ちょっとした実行でシークレットアクセスキーのようなものをハードコーディングしてしまう経験がある人は少なからずいると思います。
そういったコードが誤ってプロダクションにデプロイされてしまうなんてことは誰しもが避けたいことです。
DevSecOpsでは各工程でセキュリティスキャンを実行するため、その過程で気づくことができます。
インフラを正しく設定する
これは昨今、クラウドが登場してからよく発生している事件ですが
ちょっとした設定ミスで多くの損害を出してしまうケースがあります。たとえば、外部に公開してはいけないストレージサービスをパブリックにしていたことや暗号化しなければいけない通信が暗号化できてない、通信がインターネットを抜けていたなど設定をしっかりしていれば、防げたことは多いです。
最近ではインフラをコードで管理するということになってきており、いわゆるIaCが登場してから
インフラの設定項目をソースコードで管理できるようになりました。
DevSecOpsではそれらIaCをスキャンして問題のあるコードは修正するようにする仕組みを取り入れています。
まとめ
今回はGoogle Cloud Next Tokyo 2023 Day1で聞いた内容、「DevSecOps」にフォーカスして関連用語をまとめました。
おそらくDay2も似たようなことを聞くと思うので今日聞いたことを忘れずに行きたいと思います。