For the complete documentation index, see llms.txt. This page is also available as Markdown.

Scala: build.sbtの依存関係管理とスキャン

課題

Aikido は、Scala の依存関係に含まれる既知の脆弱性(CVE)や、それらの依存関係で使用されているマルウェアや危険なライセンスを検出できます。

Aikido はそれらの依存関係と、その推移的なサブ依存関係をどのように見つけるのでしょうか?

Scala の場合は、 build.sbt ファイルをスキャンして依存関係を確認します。なお、 build.sbt ファイルには、一部の依存関係の正確なバージョンが含まれていない場合があります。そのため、Aikido がアプリケーション内のリスクを完全には検出できないことがあります。

そのため、 build.sbt.lock のような、各依存関係およびサブ依存関係の正確なバージョンを含むロックファイルを使用することを推奨します。

Aikido のセキュリティスキャンを容易にする以外にも、ロックファイルを使う理由があります:

  • ロックファイルを使うと、悪意のあるパッケージを介したサプライチェーン攻撃から保護できます。この種の攻撃はますます一般的になっています

  • ロックファイルを使うと、全員がパッケージのまったく同じマイナーバージョンを使用するため、ビルドの挙動がより予測しやすくなります。「自分の環境では動く」の発生も減ります。

  • ビルド時間の短縮: もはや依存関係の解決は不要です

これらの課題を浮き彫りにする最近の事例を見てみましょう。

// ロックファイルなしの元の build.sbt
libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-http" % "10.2.+",
  "org.apache.spark" %% "spark-core" % "3.+",
  "com.datastax.cassandra" % "cassandra-driver-core" % "latest.release"
)

Aikido が報告した内容:

  • Akka HTTP の重大な CVE が 3 件

  • Spark の高重大度の脆弱性が 2 件

  • Cassandra ドライバの重大な脆弱性が 1 件

調査の結果、すべて誤検知であることが判明しました。スキャナーは、本番環境で実際に使用されていたものとは異なるバージョンを照合していました:

解決策:ロックファイルを追加する

次を使用してください: SBT Dependency Lock プロジェクト用のロックファイルを生成するためのプラグイン。

ステップ1:SBT Dependency Lock プラグインを追加する

ステップ2:ロックファイルを生成する

生成されたロックファイル(build.sbt.lock)は、すべての依存関係を明示的に定義します:

ステップ3:ロックされた依存関係を強制する

代替手段:コンテナスキャン

ロックファイルはソースレベルで優れた依存関係管理を提供しますが、コンテナスキャンはセキュリティ検証のもう一つの強力なアプローチです。コンテナにはコンパイル済みの成果物が含まれているため、本番環境の実際の状態を表します。

コンテナスキャンの利点

コンテナスキャンを使うべき場面

コンテナスキャンが特に有用なのは、次のような場合です:

  • 本番対応の成果物を検証する必要がある

  • ビルドプロセスが複数段階に分かれている

  • 本番で動作している正確なバージョンを確認したい

  • アプリケーションと実行環境の両方をスキャンする必要がある

コンテナスキャン vs. ロックファイル

項目

コンテナスキャン

ロックファイル

検証のタイミング

ビルド後

ビルド前

確認対象

コンパイル済み成果物

ソースの依存関係

正確性

本番と同一

開発環境と同一

統合

CI/CD パイプライン

開発ワークフロー

ベストプラクティス:両方のアプローチを使いましょう。コンテナスキャンは有用ですが、ロックファイルと併用したときに最も効果的です。

最終更新

役に立ちましたか?