はじめに

この記事はGoogle Cloud Next Tokyo ’23で出てきたワードについて見ていく記事です。
Google Cloud Next Tokyo ’23ではDevSecOpsに関するセッションがありました。
そもそもDevSecOpsとは何だったかを振り返ります。

DevSecOpsの前に。。。

まずはDevSecOpsと併せてセッションで登場した下記の用語について見ていきましょう。

  • CI/CD
  • ソフトウェアサプライチェーン
  • DevOps
  • シフトレフト
  • 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の場合においてはリリースした後にスモークテストなどを実施する方式、つまりはリリースした後に発覚することが前提になっています。
もしくはデプロイ後に検査して発覚することがあるということです。

DevSecOpsの誕生

ここまで来るとDevSecOpsがどういうものかわかってきたと思いますが
ここで一つちょっとした例えを出してみましょう。

もし、あなたが何かしらの成果物を完成度の高い状態で出した時に「そもそも〜はだめなんだよ」みたいな聞いてもいない前提をもとにダメ出しをされたらどうでしょうか。そして、それを作り直すとなったらどうでしょうか。
容易に想像がつくと思いますが、手戻りの工数は測りしれません。作り直すとなった場合はかかった工数と同じくらいかもしくはそれ以上の工数がかかるかもしれません。

運が良ければ、作ったものを少し直すだけで済むかもしれませんが、多くの場合は最初から作るか大幅な修正を余儀なくされるでしょう。
ではここで成果物を作る工程毎に指摘を入れてみたらどうでしょうか。おそらく、最終成果物における手戻りはかなり減ると考えられます。

そう！DevSecOpsというのはつまり、開発から運用までの各工程でスキャン（指摘）を挟むことで頻繁にダメ出しを行い、セキュリティ的に良くないことを修正していくことです。

DevSecOpsを実現するには

具体的には以下の項目を満たしておく必要があると考えられます。

  • SAST
  • SCA
  • DAST
  • 他
  • secretのハードコートを防ぐ
  • インフラを正しく設定する

SAST（静的アプリケーション解析）

まずはSAST、ソースコードだけを見て脆弱性がないかを見つける解析手法、もしくはツールのことです。ソフトウェアを動かすことなく実行する解析であることが最大の特徴です。

SCA（ソフトウェアコンポジション解析）

ソフトウェアを構成するコンポーネント（OSS、ライブラリ、パッケージ）などから脆弱性を見つける解析手法、もしくはツールのことです。SCAを実施した後は代替のライブラリに対してタイムリーに切り替える必要があります。

DAST（動的にアプリケーション解析）

静的解析ではわからなかったランタイムの脆弱性を見つける解析手法、ツールのことです。
実際に動かしてみて解析するところが特徴となります。
ソフトウェアのテストをしたことがある人はわかると思いますが、実際に実行してカバレッジ（網羅率）を出すのと似ています。

他

他は当たり前のことだと考えられますが、もしかしたらよくやってしまう？ことでもあるので紹介します。

secretのハードコートを防ぐ

たとえば、ちょっとした実行でシークレットアクセスキーのようなものをハードコーディングしてしまう経験がある人は少なからずいると思います。
そういったコードが誤ってプロダクションにデプロイされてしまうなんてことは誰しもが避けたいことです。

DevSecOpsでは各工程でセキュリティスキャンを実行するため、その過程で気づくことができます。

インフラを正しく設定する

これは昨今、クラウドが登場してからよく発生している事件ですが
ちょっとした設定ミスで多くの損害を出してしまうケースがあります。たとえば、外部に公開してはいけないストレージサービスをパブリックにしていたことや暗号化しなければいけない通信が暗号化できてない、通信がインターネットを抜けていたなど設定をしっかりしていれば、防げたことは多いです。

最近ではインフラをコードで管理するということになってきており、いわゆるIaCが登場してから
インフラの設定項目をソースコードで管理できるようになりました。
DevSecOpsではそれらIaCをスキャンして問題のあるコードは修正するようにする仕組みを取り入れています。

まとめ

今回はGoogle Cloud Next Tokyo ’23 Day1で聞いた内容、「DevSecOps」にフォーカスして関連用語をまとめました。
別の記事で紹介予定ですが、Google Cloudのサービスを用いることでSLSAの基準を満たしたCI/CDパイプラインを構築できます。

感想

現場では開発技術を扱うことがあり、構築済みのCI/CDパイプラインを扱うことが主ですが、これを機に見直していきたいと思いました。
なお、恥ずかしながら筆者である私はまだGoogle CloudのプロダクトでCI/CDのパイプラインを構築した経験がないため、実際にやってみようと思いました。

参考にしたセッション

おわり