Mavenのセキュリティに関する10のベストプラクティス

今月も、セキュリティに特化したチートシートをお届けします。今回は、Mavenをさらに使いこなすためのベストプラクティスを10個ご紹介します。JavaおよびJVMエコシステムのビルドツールでは、Mavenが明らかにトップです。※ネタバレ注意！10月に公開予定のJVMエコシステムに関する調査結果でも、Mavenの優位性は2018年も続いており、今後も変わる気配はありません。以下に示すとおり、開発者の10人中6人がメインプロジェクトでこのビルドツールを使用しています。

今年に入って5つ目となるSnykのチートシートです（時間が経つのは本当に早いですね）。これまでに、Javaの型推論、GitHubセキュリティのベストプラクティス、Zip Slip、Spring Bootセキュリティに関する10のベストプラクティスを取り上げてきました。今回の記事のアイデアは、Apache Mavenプロジェクトの代表者、Robert Scholteとクレタ島のビーチで過ごしていたときに生まれました。美しい黄金色の砂浜に座り、温かなクレタ島の海で泳ぎながら、次の10個のセキュリティのヒントを考えました。たまには皆さんのために、こんなこともしています。

1. シークレットを暗号化する

Maven 2.1.0以降、共有ビルドマシン上のパスワードを暗号化できるようになりました。複数のユーザーが共有マシンにアクセスできる場合や、settings.xmlファイルに多くのユーザーがアクセスできる場合は、保存されているシークレットを暗号化しましょう。settings.xmlファイルをほかの開発者と共有する場合は、チーム全体ではなく、権限を持つユーザーだけがMavenアーティファクトをリポジトリにデプロイできるように、シークレットをファイルから削除することを検討してください。権限を持つユーザーは、Mavenの設定フォルダ内、またはそのユーザーだけがアクセスできる場所にsettings-security.xmlファイルを保存します。チーム全体が使用する共有場所でビルドを実行する場合は、settings.xmlファイル内のシークレットを暗号化してください。そのためには、適切に保管・共有できるマスターパスワードを作成する必要があります。

Maven CLIで次のコマンドを実行すると、マスターパスワードとサーバーパスワードを作成できます。

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password
Master password:
{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}

作成したら、次のように~/.m2/settings-security.xmlファイルに保存します。

<settingsSecurity> <master>{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}</master> </settingsSecurity>

次のコマンドを実行すると、サーバーパスワードを作成できます。

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-password
Password:
{155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}

次のようにsettings.xmlファイルに保存します。

<server> <id>my.server</id> <username>smaple</username> <password>Simon reset this password on 2019-03-11, expires on 2019-04-11 {155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}</password> </server>

詳しくは、settings.xmlファイルへのシークレットの保存方法に関するMavenのドキュメントをご覧ください。

2. CLIでパスワードを使用しない

前の例では、設定ファイルにシークレットを追加する正しい方法を紹介しました。一方で、間違った方法もあります。誤って使わないよう、こちらも知っておきましょう。上記の暗号化コマンドには、コマンドラインでパスワードを指定する古いオプションがあります。たとえば、次のように実行します。

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password P@ssw0rd

「10 この方法でも暗号化されたシークレットを作成できますが、シークレットを平文でコマンドラインに入力してはいけません。シークレットはコンソールの履歴に保存され、簡単に取得できてしまいます。

3. 常にHTTPSを使用する

Mavenリポジトリには、ローカルとリモートがあります。通常、マシンの~/.m2/repository/ディレクトリにあるローカルリポジトリには、以前ダウンロードしたプロジェクトがキャッシュされています。リモートリポジトリには、Maven Centralや、Artifactoryなどを使って組織が構築したリポジトリがあります。pom.xmlの要素を確認すれば、ビルドで使用しているリポジトリがわかります。今やほとんどの通信において、サードパーティサービスへの接続にHTTPSを使うことが非常に重要です。Mavenリポジトリも例外ではありません。接続先のサーバーが意図したものであることを検証すれば、中間者攻撃や、より具体的には「安全でないプロトコルによるリソースのダウンロード」の脆弱性のリスクを低減できます。

これを避けるため、組織がホストするリポジトリも含め、常にHTTPSで通信してください。pom.xmlの要素で指定するURLにhttpsを使用していることを確認してください。

4. 依存関係の健全性を確認する

アプリケーションにサードパーティ製の依存関係を取り込むことは非常によく行われていますが、多くの場合、開発者は「機能要件を満たすか」だけを見て判断しています。依存関係をアプリケーションに取り込むにあたっては、その健全性も同じくらい重要です。依存を検討しているプロジェクトの健全性を判断する際は、次の点を確認しましょう。

アクティブなコミッターの数 - 1、2人だけで保守されているオープンソースプロジェクトは、更新やリリースを特定の個人に頼りがちなため、リスクが高くなる可能性があります。貢献者のチームがいれば、このリスクを大幅に軽減できます。

セキュリティポリシーの明記 - セキュリティ上の問題を報告する手順をユーザーに示すことで、問題の報告を受けられる可能性が高まります。また、セキュリティ上の問題や修正が発生した際にユーザーへ通知する仕組みがあれば、依存関係をより安全に利用できます。

定期的な更新とリリース - 依存するプロジェクトが積極的に開発されていることを確認しましょう。依存関係が言語機能などに対応して最新の状態に保たれるため、自分のプロジェクトの今後の開発にも役立ちます。さらにセキュリティの観点では、報告された問題が速やかに対処されることが重要です。

5. 既知の脆弱性をテストする

ライブラリの再利用により、既知の脆弱性を悪用しようとする攻撃者にとって被害対象が多くなるため、オープンソースの依存関係が狙われるケースは増えています。アプリケーションの依存関係ツリー全体に既知の脆弱性がないことを確認することが重要です。

SnykなどのツールでMavenのビルドアーティファクトをテストすると、既知の脆弱性がある依存関係を検出できます。ダッシュボードでは、pom.xmlファイルを通じて取り込んでいるパッケージに含まれる脆弱性の一覧を確認できます。

さらに、バージョンアップやSnykのセキュリティチームが作成したパッチなど、修正方法も提案します。たとえばGitHub、Bitbucket、GitLabなどのソースコード管理ツールを接続すれば、プルリクエストやマージリクエストを通じてセキュリティの問題を自動的に修正できます。SnykはWebhookを使って、今後作成されるプルリクエストやマージリクエストも自動でテストし、ほかの開発者が新たな脆弱性をプロジェクトに持ち込まないよう、環境を継続的に保護します。

SnykはWeb UIとCLIの両方から利用できるため、CI環境に簡単に統合できます。また、脆弱性の深刻度が設定したしきい値を超えた場合に、Mavenビルドを失敗させるよう設定できます。

オープンソースプロジェクト、または月間テスト数に上限のあるプライベートプロジェクトでは、Snykを無料で利用できます。

6. チェックサムをテストする

チェックサムは、データの転送中や保存中に発生したエラーを検出するためのものです。プロジェクトの各依存関係について、チェックサムを確認することが重要です。チェックサムはデータの完全性の検証によく使われます。依存関係の真正性を確認するためのものではありませんが、追加の確認手段として役立ちます。Maven 4では、すべての依存関係のチェックサムがデフォルトで検証されます。それまでは、Mavenコマンドに-Cフラグを付けてチェックサム検証を有効にしてください。チェックサムが一致しない場合、ビルドは失敗します。

$ mvn -C install // fail if checksums don’t match

$ mvn -c install // warn if checksums don’t match

7. パスワードにプロパティを使わない

Mavenでは、pom.xmlファイル内のプレースホルダーとしてプロパティがよく使われます。以下のpom.xmlの例のように、my.propertyというプロパティを設定できます。

<properties>
  <my.property>value</my.property>
</properties>

pom.xmlファイル内のどこでも、${my.property}という表記を使ってmy.propertyプロパティを参照できます。これはとても便利な機能ですが、別の場所で使うパスワードを簡単に保存できてしまいます。しかし、その場合はパスワードを平文で保存し、チーム内で共有してしまう可能性があります。プラグインでは、settings.xmlのサーバーエントリを使うようにしましょう。

8. Mavenの開発者情報・役割を活用する

「オープンソースセキュリティの現状」レポートが示すとおり、報告が必要なセキュリティ上の問題を見つけた人が、必要な情報を得られるようにすることが重要です。セキュリティ報告プロセスを定めているGitHubリポジトリは、報告プロセスを明記していないリポジトリと比べ、セキュリティバグの報告を受ける可能性が3倍以上高くなります。

Mavenのpom.xmlファイルにdevelopersタグを追加すると、セキュリティ上の問題についてチームに連絡する必要がある場合に備え、セキュリティ担当者の情報を記載できます。以下は、社内のセキュリティ担当者であるDannyを追加した例です。

<developers>
    <developer>
      <id>grander</id>
      <name>Danny Grander</name>
      <email>danny@snyk.io</email>
      <organization>Snyk</organization>
      <organizationUrl>https://snyk.io</organizationUrl>
      <roles>
        <role>security</role>
      </roles>
    </developer>
  </developers>
  ...
</project>

できれば、メールアドレスにはsecurity@yourdomain.comのような汎用アドレスを指定しましょう。セキュリティ担当者に何かあっても、メールが監視されている受信トレイに届くようになります。

9. 常に最新の状態に保つ

セキュリティアップデートは通常、新しいバージョンで提供されます。セキュリティ上の欠陥を含むバージョンを使うリスクを減らすため、Mavenのリリースを常に確認して最新の状態を保ちましょう。特にMaven 3.0.4は、HTTPS接続の証明書を無視する重大なセキュリティ問題があるため、使用を避けてください。最新のMavenバージョンは、Mavenのダウンロードページで確認できます。

10. セキュリティ情報を確認する

Mavenチームは、Apache Mavenのサイトに掲載するセキュリティ情報を通じて、セキュリティ上の問題を知らせています。Snykのセキュリティチームが多数のZip Slip脆弱性を発見した際、Apacheチームは（Apacheプロジェクト内のZip Slipを排除するため、私たちと懸命に取り組みました）、以下のようにApache Mavenのサイトでセキュリティ情報を公開しました。

Apache Mavenプロジェクトの最新情報を受け取るには、announce@maven.apache.orgのメーリングリストに登録するか、Twitterで@ASFMavenProjectをフォローしてください。

Apache Mavenのセキュリティに関する10のベストプラクティスは以上です。このチートシートをダウンロードして、手近な場所に貼っておきましょう。ビルドのセキュリティを常に意識できます。

チートシートをダウンロード

チートシートを印刷して目につく場所に貼っておけば、Mavenを使う開発者が実践すべきベストプラクティスをいつでも確認できます。