SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

SpringOne 2021参加レポート~Spring Framework 6.0ロードマップ、クラウドネイティブ対応、DevSecOps

  • X ポスト
  • このエントリーをはてなブックマークに追加

Spring Native

 Sebastien Deleuze氏によるこのセッションでは、Juergen Hoeller氏が初日のMain Stageで「現在取り組んでいる中で最もエキサイティングな仕事の一つ」として言及していた、SpringアプリケーションをNative Imageに事前コンパイル(Ahead-of-time Compilation / AOT Compilation)するためのプロジェクトであるSpring Nativeについて説明がなされました。

 セッション序盤ではSpring Nativeプロジェクトの概要が説明されました。GraalVMを使用してNative Imageを生成する方法と、Buildpacksを使用してNative Imageを含むコンテナー・イメージを生成する方法の両方についてアプリケーションを事前コンパイルするまでの流れが説明された他、現時点で対応しているSpringプロジェクトの一覧の提示もありました。また、最近実装された機能としてJunit 5を使用したテストコードをNative Imageにコンパイルして実行する機能などが紹介されました。

 Deleuze氏がセッション中で最も重要なトピックとして挙げたのは、事前コンパイル時のコード変換です。Spring Bootアプリケーションは必要なBeanの生成等の処理を、通常はリフレクションを利用して実行時に動的に行いますが、Spring AOTプラグインはビルド時にコードを解析し、実行時の動的処理が不要になるようにコード生成やコード変換を行います。これによって、Native Imageとの互換性と実行時のフットプリントの向上の効果が得られるとのことです。プラグインが生成したコードは実行時にオプションを指定することでJVM上での実行の際にも使用可能です。

 現在は実験的なプロジェクトと位置付けられているSpring Nativeですが、セッション終盤に語られたロードマップによればSpring Boot 3に徐々に統合されていくことが計画されているようです。Spring Bootアプリケーションがさらに簡単に、性能の良いNative Imageへとコンパイルできるようになっていくことが期待できそうです。

Spring Boot 3ではSpring Nativeの取り込みが計画されている
Spring Boot 3ではSpring Nativeの取り込みが計画されている

Security as Code: A DevSecOps Approach

 このセッションでは、GitHubのAlvaro Muñoz氏とTony Torralbaが、セキュリティのシフトレフトを実現する方法の一つであるSecurity as Code(SaC)、およびそのツールであるCodeQLについて、デモも交えて解説しました。

 まずMuñoz氏は火星探査機「Curiosity」のバグについて述べました。この探査機の動作プログラムにおいて、CWE-805:"Buffer access with incorrect length value"に分類されるバグが見つかり,同様のバグをプログラム中からCodeQLで探したところ、30件見つかりました。これが見つかったのはライフサイクルの終盤で費用がとても高くついたため、次の探査機「Perseverance」ではCodeQLを用いたセキュリティ活動がライフサイクル序盤に組み込まれました。

 次にMuñoz氏はセキュリティのシフトレフトにおけるよくある間違いとして、「自動化してそれを早期に実行する」だけではなく人とプロセスに着目する必要があり、「コーディングで止まる」ことなく要件定義や設計などの段階まで「go left(er)」するべきであると述べました。

 さらにDaniel H. Pink著『Drive』から、モチベーションを高める3つの要素として、「autonomy(自律性)」「mastery(習熟)」「purpose(目的)」を引用し、これをDevSecOpsに適用することで、開発者がモチベーションを持ってセキュリティに取り組めるようになるという考えを示しました。

 次にTorralba氏が、DevOpsのアプローチを援用して、開発者がDevSecOpsにモチベーションを持って取り組めるようにするアイディアを語りました。即ちDevOpsにおいては、Infrastructure as Code(IaC)を通じて開発者が自律的に運用に関与し、その手法に習熟し目的を理解することで上手くいったのであり、ならばDevSecOpsではSecurity as Code(SaC)を通じてこれを行えば、同様にうまくいくのではないかと考えていると述べました。

 ここで再びMuñoz氏から、「SaCとはセキュリティ・ポリシーに基づく決定をコード化し、他の(セキュリティ・チーム以外の)チームと共有する手法である」と定義した上で、従来のセキュリティ・チームはソフトウェアの配備の可否を決定する門のようなものだったが、SaCは(ソフトウェアが)危険なところに行かないようにするガードレイルのように機能することで、開発者にセキュリティ問題を回避させるという趣旨の考えを示しました。

 さらにここで初めてCodeQLの具体的な説明がなされました。Muñoz氏は「特定の種類のメソッドを検索する」という非常に単純な例を用いて、CodeQLがSQLに似た宣言型の検索言語であると同時に、オブジェクト指向に基づく高い再利用性を持つことを示しました。

 この後Torralba氏がより実際的な例として「SpringアプリケーションにおいてSpring Expression Language(SpEL)による任意コード実行脆弱性を持つメソッドを発見する」CodeQLクエリーの構築をゼロからデモしました。検索対象のコードの中からは最終的に3箇所に問題が見つかったのですが、ここで重要なことは「もともと対象としていた箇所の他に2箇所の問題が見つけられたこと」および「ここで作成されたクエリーは今後も繰り返し利用可能なこと」であるという見解が示されました。

SpELによる任意コード実行脆弱性のデモ
SpELによる任意コード実行脆弱性のデモ

 最後にMuñoz氏から、CodeQLにはSpringに特化したさまざまなサポートがあること、CodeQLクエリーを共有することがオープンソース・ソフトウェア全体のセキュリティの向上につながるのでぜひクエリーを書いて共有してほしいことなどが告げられ、本セッションが締めくくられました。

おわりに

 以上、SpringOne 2021のハイライトでした。各セッションの動画は、Main Stageを含めSpringOne公式サイトおよびYouTubeのVMware Tanzuチャンネルにて公開されていますので、本稿で興味を持ったセッションがあればそちらもチェックしてみてください。

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

SpringOne 2021 参加チーム(SpringOne 2021 サンカチーム)

【NTT ソフトウェアイノベーションセンタ】谷口 展郎、岩塚 卓弥、水野 諭孝 【NTTデータ】田端 一也、高橋 寛恒 【NTTコムウェア】堅田 淳也、杉本 真梨

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15022 2021/10/26 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング