Security as Code

Security as Codeは、DevSecOpsをテーマにした入門書です。DevSecOpsは、DevOps + Securityと説明されますが、2023年末時点では、クラウドベンダおよびCI/CDパイプライン提供事業者主導で、その必要性が喧伝されているような状況に思えます¹。
他のDevSecOps文献をあたっても理念はしっかり書かれているものの、実装例テストのシフトレフトのコンセプトに基づいて、CI/CDパイプラインに、セキュリティテスト、かつほとんどコンテナスキャンやインフラのコンフィグスキャンばかりで、「えっ、それだけ？」感が拭えません。

開発者は、セキュアコーディングの原則を理解し、セキュリティエンジニアリングを日常業務の一部とするように方向転換しなければならない

と、そもそも普通の開発現場では普通にやっていることへ「方向転換」と言ってる前提も違いそうです。

ということで、取り立ててDevSecOpsには新しい話題はなさそうなのですが、自動化を軸にプロセスとツールが整理されるのは良いことかもしれません。

図は、各フェーズで、どういう観点でセキュリティチェックおよびテストを行い、その分野でどういうツールがあるかを示したものです。各用語の定義は以下のとおり。

• ソースコンポジション分析(SCA): 依存関係やライブラリに脆弱性がないかをチェックする。
• 静的アプリケーションセキュリティテスト(SAST): 静的コード解析し、XSSやSQLインジェクション、バッファオーバーフローなどのセキュリティ上の弱点があるかを判定する
• 静的アプリケーションセキュリティテスト(DAST): 外部からアプリケーションやサービスに侵入しようとする方法と同様の方法で攻撃をシミュレートする
• インタラクティブアプリケーションセキュリティテスト(IAST)： 実行中のアプリケーションにエージェントとセンサーを配備することで、アプリケーションを計測し、テストによってシミュレートされる実行時間中のアプリケーションの動作を分析する
• IaC Scanning: インフラに関するSAST
• ランタイムアプリケーション自己保護(RASP): RASPツールが潜在的な脅威を検出したら、脅威に対処するためのアクションを自動的に実行する

このうちSCAでやっている依存ライブラリの脆弱性検出は、近年急成長している分野ですが、この予防策にはトレードオフがあるので、少し掘り下げてみたいと思います。

依存ライブラリのバージョンアップ戦略

依存ライブラリが古いままだと、それだけ脆弱性の影響を受ける可能性も高まり、また検出時の対応が大幅なコード修正を伴うようになることがあります。一方で、こまめにバージョンアップしていくのも、明確なベネフィットがなくそのコストを支払うことになります。

ということで戦略を分類すると上図のようになります。現実的には、以下のどれか基本戦略とし、場合によってはライブラリ個別に別の戦略も取り入れるになるかと思います。

プロアクティブ

常に最新バージョンを取り込んでいく。

• メリット
  • 1回の作業量は少なくなり、脆弱性発生時の対応も速くなる。
  • バグレポートなどでOSSへの貢献ができる。
• デメリット
  • 他の依存ライブラリとの関係で、単にバージョンアップできない場合がある。
  • メジャーバージョンアップ直後など、バグを踏む確率が高い。

LTSドリブン

プロアクティブの一部だが最も消極的。フレームワークや主要なライブラリはLTS(Long-Time Support)バージョンが存在する。

• メリット
  • バージョンアップのタイミングを計画しやすい
  • 比較的問題が起きにくい
• デメリット
  • 次のLTSにバージョンアップするときに、変更箇所が多くなる。

脆弱性ドリブン(リアクティブ)

脆弱性発生検知のタイミングで、バージョンアップする

• メリット
  • (平時の)バージョンアップにかかる工数を最小化できる
• デメリット
  • 古いバージョンのセキュリティパッチバージョンが出なくて、大幅なバージョンアップを余儀なくされることがある。

1. 本書もGoogleとAWSの中の人の共著のようです。 ↩