はじめに

本ブログでは、これまでも度々触れてきた、Zephyr® について、今回は、AMD™ 社製 KV260 で動作させる手順の概要について紹介します。

KV260 は、Vision AI Starter Kit として位置付けのリファレンスで、ARM Cortex a53、ARM Cortex r5、FPGA を搭載しています。

下記サイトの内容に従い、KV260 ボードで Zephyr® のコードを実際に動作させました。

① Zephyr® 生成環境の構築、および生成手順

参照サイト：https://docs.zephyrproject.org/latest/develop/getting_started/index.html

② KV260 Development Board RPU Cortex-R5 で Zephyr Hello_world デモコードを動作させる手順

参照サイト：https://docs.zephyrproject.org/latest/boards/amd/kv260_r5/doc/index.html
上記 1) で生成した、Zephyr® コードを KV260 ボードで動作させます。
より詳細には、r5 で動作する Zephyr® コードを、a53 で動作している Linux 経由で実行しています。

③ KV260 にて、Linux を経由せず Zephyr® コードを r5 で動作させる手順

作業環境として、Ubuntu 22.04 LTS を使用しました。
それでは、手順詳細を順に紹介していきます。

①Zephyr® 生成環境の構築、および生成手順

手順の詳細は以下のサイトを参照しました。
参照サイト：https://docs.zephyrproject.org/latest/develop/getting_started/index.html

作業手順(参照したサイトの内容から抜粋しています)

Install dependencies(依存パッケージのインストール)

Ubuntu 22.04 LTS で必要となるパッケージをインストールします。

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install --no-install-recommends git cmake ninja-build gperf \
ccache dfu-util device-tree-compiler wget python3-dev python3-venv python3-tk \
xz-utils file make gcc gcc-multilib g++-multilib libsdl2-dev libmagic1

Get Zephyr and install Python dependencies(Zephyr® の取得および Python® 依存関係のインストール)

Create a new virtual environment(新しい仮想環境の作成)

新しい仮想環境を作成します。

$ mkdir zephyrproject
$ cd zephyrproject
$ python3 -m venv ./zephyrproject/.venv
* python3 等がインストールされていなければ、以下を実行します。
$ sudo apt install python3-venv

Activate the virtual environment(仮想環境の有効化)

仮想環境を有効化します。

$ source ./zephyrproject/.venv/bin/activate

Install west(west のインストール)

west をインストールします。

$ pip install west

Get the Zephyr source code(Zephyr® ソースコードの取得)

Zephyr® ソースコードを取得します。

$ west init ./zephyrproject
$ cd ./zephyrproject
$ west update

Export a Zephyr CMake package(Zephyr® CMake パッケージのエクスポート)

Zephyr® CMake パッケージをエクスポートします。これにより、CMake は Zephyr® アプリケーションの生成に必要な定型コードを自動的に読み込むことができるようになります。

$ west zephyr-export

Install Python dependencies using west packages(west packages を使用して Python® 依存関係をインストール)

Zephyr® の west 拡張コマンドを用いて、Python® 依存関係をインストールします。

$ west packages pip --install

Install the Zephyr SDK(Zephyr® SDK をインストールする)

Install the Zephyr SDK using the west sdk install(west sdk install を使用し、Zephyr® SDK をインストールします)

$ cd ./zephyr
$ west sdk install

サンプルコードの生成

$ west build -p always -b <your-board-name> samples/basic/blinky
^^^^^^^^         ^^^^^^^^^^
kv260_r5         samples/hello_world

今回は、hello_world を Build するので、

$ west build -p always -b kv260_r5 samples/hello_world

hello_world は、~/zephyrproject/zephyr/samples/hello_world/ 以下にあります。

生成の結果、以下に、zephyr.elf が生成されます。

~/zephyrproject/zephyr/build/zephyr/zephyr.elf

②KV260 Development Board RPU Cortex-R5 で Zephyr Hello_world デモコードを動作させる手順

手順の詳細は以下を参照しました。
参照サイト：https://docs.zephyrproject.org/latest/boards/amd/kv260_r5/doc/index.html

実際の手順は以下の通りでした。

起動用 SD Card image のダウンロード

以下のサイトより、OpenAMP を含んだイメージをダウンロードします。
参照サイト：https://www.xilinx.com/member/forms/download/xef.html?filename=petalinux-sdimage_xilinx-k26-starterkit.wic.xz

以下のコマンドで、SD Card 書き込みます。

$ sudo dd of=/dev/sdb if=Downloads/amd/petalinux-sdimage_xilinx-k26-starterkit.wic

デモコードを 対象機にコピー

前の手順で生成した zephyr.elf を使います。
開発環境側(Ubuntu 22.04 LTS)から以下のコマンドで対象機に zephyr.elf をコピーします。

$ scp <path_to>/zephyr.elf petalinux@<board-ip-address>:/home/petalinux

実行例は以下の通りです。

$ scp workspace/zephyrproject/zephyr/build/zephyr/zephyr.elf petalinux@192.168.13.205:/home/petalinux
petalinux@192.168.13.205's password:
zephyr.elf 100% 375KB 4.0MB/s 00:00

下記メッセージが表示されてエラーが出る場合は、-O オプションを使用します。

<エラーメッセージ>
sh: line 1: /usr/libexec/sftp-server: No such file or directory
scp: Connection closed

$ scp -O workspace/zephyrproject/zephyr/build/zephyr/zephyr.elf petalinux@192.168.13.205:/home/petalinux
petalinux@192.168.13.205's password:
zephyr.elf 100% 375KB 4.0MB/s 00:00

対象ボード側で zephyr.elf がコピーされていることを確認します。

xilinx-k26-starterkit-20221:~$ pwd
/home/petalinux
xilinx-k26-starterkit-20221:~$ ls
zephyr.elf <<< zephyr.elf がコピーされた
xilinx-k26-starterkit-20221:~$

重要

公式手順に記載されている以下の内容に従い、
対象ボード側の /lib/firmware 以下にも zephyr.elf をコピーします。

After that move the file to /lib/firmware directory, then you be able to start the firmware on the desired RPU via remoteproc with:

デモコードの実行に従い、対象ボード側のコンソールは、r5 の出力用に使用するため ssh 接続で操作します。

$ ssh petalinux@192.168.13.249
petalinux@192.168.13.249's password:
xilinx-k26-starterkit-20221:~$ sudo -i
Password:
root@xilinx-k26-starterkit-20221:~# pwd <<< target 側の shell
/home/root
root@xilinx-k26-starterkit-20221:~# cd ../petalinux
root@xilinx-k26-starterkit-20221:/home/petalinux# ls
xilinx-kv260.tar.gz zephyr.elf
root@xilinx-k26-starterkit-20221:/home/petalinux# ls -l
total 177512
-rwxr-xr-x 1 petalinux petalinux 449772 Aug 27 21:49 zephyr.elf
root@xilinx-k26-starterkit-20221:/home/petalinux#
root@xilinx-k26-starterkit-20221:/home/petalinux# echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware
root@xilinx-k26-starterkit-20221:/home/petalinux# echo start > /sys/class/remoteproc/remoteproc0/state

コンソール側の結果

*** Booting Zephyr OS build v4.3.0-1097-g5220936bbc02 ***
Hello World! kv260_r5/zynqmp_rpu

上記出力が対象ボード側のコンソールに表示されました。

なお、本作業は、2025年12月9日に実施したものです。

③KV260 にて、Linux を経由せずに Zephyr® コードを r5 で動作させる手順

本手順では、KV260 の基本構成に基づく Vivado™ XSA ファイルを使用します。

(注) XSA ファイルについて
XSA(eXtensible System Archive)ファイルとは、FPGA/SoC 設計のハードウェア情報(IP、ピン配置、クロック、メモリ設定など)と作成時の Vivado™/Vitis™ バージョンなどのメタデータをまとめたアーカイブファイルです。本手順では .xsa ファイルが必要で、生成には、Vivado™ を使用します。

Vitis™ の起動 (Vitis™ Embedded を使用)

Vitis™ は、AMD™ FPGA processors のためのアプリケーションソフトウェア開発環境です。
以下のサイトより、Vitis™ Embedded をダウンロードします。(本記事では、2025.1 を使用)

参照サイト：https://japan.xilinx.com/support/download/index.html/content/xilinx/ja/downloadNav/vitis.html

Worksapce の作成

作業用フォルダの作成と初期化を行います。
あらかじめ、作業用フォルダを作成します(例：$ mkdir -p workspace/kv260_zephyr)。

次に、Vitis™ メニューにて、
[File] [Set Workspace …] を選択し、kv260_zephyr を指定します。

Platform Component の作成

Vivado™ で設計した XSA ファイルに基づき、BSP、FSBL を生成するための Platform Component を作成します。Platform Component は、Vivado™ で設計したハードウェア情報(XSA ファイル)に基づき、BSP(Board Support Package)、FSBL(First Stage BootLoader)を生成するためのプロジェクトです。これを作成します。

VITIS EXPLORER にて、[Create Platform Component] を選択します。
Component name に任意の名称を入力します(本例では、kv260_zephyr)(図1)。入力後、[Next]ボタンを押下します。

図1

[Hardware Designe(XSA) For Implementation] の [Browse]ボタンを選択し、あらかじめ作成しておいた .xsa ファイルを指定します(図2)。指定後、[Next]ボタンを押下します。

図2

[Generate Boot artifacts] がチェックされていること、および[target processor to create FSBL:] が、cortexa53 になっていることを確認します(図3)。確認後、[Next]ボタンを押下します。

図3

Summary の画面にて、[Finish]ボタンを押下します。
これで、Platform Component の作成が完了します。

Platform Component の生成

FSBL(fsbl.elf)を生成します。
[Build]ボタンが追加されているので(図4)、選択して、生成を実施します。

図4

fsbl.elf が生成されます(図5)。

図5

Boot Image の作成

生成した fsbl.elf と 動作させたいアプリケーションを結合し、起動可能なイメージである、BOOT.bin を生成します。

上記動作させたいアプリケーションを生成した zephyr.elf とします。

Vitis メニューにて、
[Vitis] [Create Boot Image] [Zynq Ultrascale+] を選択します。
図6 の [+]ボタンを押下し、fsbl.elf を登録します。
[File Path] に fsbl.elf への path を指定します。
[Type] は自動的に “bootloader” が選択されます。
[Destination CPU] は a53-0 を選択し、[OK]ボタンを押下します。

図6

続けて、再度[+]ボタンを押下し、zephyr.elf を登録します。
[Type] は、datafile、[Destination CPU] は r5-0 を選択します(図7)。
[OK]ボタンを押下します。

図7

[Output BIF File Path] に任意のファイル名をパスと併せて入力します。
[Output Image] のファイル名が BOOT.bin になっていることを確認します(図8)。
赤枠のファイル名の順序が異なる場合は、[+] 右側にある矢印で変更できます。
確認後、[Create Image] ボタンを押下します。
BOOT.bin、および bootImage.bif が生成されます。
Vitis での操作はこれで終了です。

図8

KV260 Flash Memory への BOOT.bin のコピー

KV260 の web サーバーによる BOOT.bin イメージのコピー

KV260 ボードの FWUEN(Firmware Update) Button を押したまま、RESET Button を押すと、web サーバーが使用可能になります。
ブラウザから http://192.168.0.111 に接続します。
KV260 の Flash Memory は、Image A、Image B の 2 領域があり、いずれか一方を選択して使用します。

BOOT.bin イメージのコピー手順は以下の通りです(図9)。

• 1) Recover Image 下の [Browse] ボタンで、<path to>/BOOT.bin を選択
• 2) [Select Image to bo recovered] で、Image A または Image B を選択
• 3) [Upload] ボタンを押下してコピーを実施

次に、(図9) の Boot Image Status 下にて、

• 4) [Requested Boot Image] で、コピーした Image A または Image B を選択
• 5) コピーした側の Image の Bootable ボタンを有効化
• 6) [Configure] ボタンを押下

これで、コピー処理および BOOT.bin を動作させる準備が完了します。

図9

 

BOOT.bin の起動

電源 OFF —> ON、または RESET ボタンで BOOT.bin を動作させます。
コンソールに、以下の出力が表示されました。

Hello World! kv260_r5/zynqmp_rpu

最後に

以上になります。
このコラムが、皆様がAMDボードやZephyrに興味を抱くきっかけになりましたら幸いです。

ウインドリバーのZephyr RTOS 開発・運用支援サービス

詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

---

• AMD™、Vivado™、Vitis™ は、Advanced Micro Devices, Inc. の商標または登録商標です。
• Zephyr® は The Linux Foundation の商標です。
• Python® は Python Software Foundation の登録商標です。

---

[2026年01月20日 時点]

IoTデバイスや組込みシステムの開発でRTOSを検討している方の中には、「Zephyr OS」が気になっている方も多いのではないでしょうか。Zephyr OSは、リアルタイム性能や限られたリソースでも動作する軽量さなどが特徴です。RTOSの選定は、開発後の保守性や移植性、製品寿命に直結するため重要事項となります。

この記事では、Zephyr OSの基本概要から特徴、利点、活用分野を整理し、他のRTOSやLinuxとの比較を通じて、選定の判断材料を解説します。

 

Zephyr OSの基本概要

Zephyr OSは、組み込み機器やIoT向けに設計された軽量RTOSです。小規模リソースしかなくても、必要機能を限定することでZephyr OSを組み込むことができます。ここでは、Zephyr OSの成り立ちと特徴、適用範囲などを解説します。

 

組込みシステム向けに設計されたオープンソースRTOS

Zephyr OSは、リソースが限られる機器で使うことを前提に設計されたオープンソースのRTOSです。（※）

小さなカーネル（OSの中核部分）を中心に、ドライバやネットワークなどを必要な分だけ選定して、構成できます。ライセンスはApache 2.0で、商用利用や改造がしやすい点が特徴です。（※）

Zephyr OSは、環境センサーやウェアラブル、組み込みコントローラなどで動作し、リアルタイム性と省リソース性を両立します。最小限から始めても、その後、要求に応じて機能を追加できるため、試作から量産まで一貫した開発がしやすいRTOSです。

※出典：

Wind River「Zephyrとは？」

Zephyr Project「Zephyrプロジェクトコンポーネントのライセンス」

 

The Linux Foundationによるプロジェクトの位置づけ

Zephyrプロジェクトは、世界的な非営利団体であるThe Linux Foundationが中立的に運営しており、Zephyr OSの開発や普及を担っているプロジェクトです。（※）

運営には多くの企業や技術者コミュニティが参加し、長期的に使い続けられるようにロードマップ（将来計画）が作られています。参加企業には「プラチナメンバー」や「シルバーメンバー」といった区分が設けられています。企業からの資金や技術の支援によって、製品やサービスが共存できるエコシステムが広がっている状況です。

こうした企業支援と、コミュニティの協力が両立していることで、Zephyr OSの導入企業は長期的に安定したサポートや情報を得やすくなります。結果として、製品の長期利用に必要な継続性と透明性を確保できる体制が整っています。

※出典：Zephyr Project「Zephyrプロジェクトについて」

 

IoT・エッジデバイスにおける適用範囲

Zephyr OSは、小型のセンサーやビーコンのような超小型機器から、スマートウォッチや産業用コントローラまで、幅広い分野で利用されています。OSの中核部分であるカーネルが非常に軽量であるため、CPUやメモリの少ないマイコン（小型の制御用プロセッサ）でも、効率よく動作が可能です。

使いたい機能だけを選んで組み込めるため、電力やメモリに制約が厳しい機器でも扱いやすいのが特徴となります。また公式のサンプルコードやサポートが整備されているため、開発者は試作から量産までスムーズに進めることが可能です。

IoTやエッジ分野と呼ばれるネットワーク末端部分でのリアルタイム性、長期保守のしやすさが求められる場合などに、Zephyr OSは有効な選択肢となります。

 

Zephyr OSの主要な特徴

Zephyr OSは、軽量で柔軟に構成できるRTOSです。小型マイコンでも安定して動作し、複数CPUに対応する移植性も備えています。ここでは、3つの主要な特徴を解説します。

 

必要な機能を選択可能なモジュール構造

Zephyr OSは、機能を必要に応じて追加・削除できるモジュール方式を採用しています。開発者はKconfig（機能設定ツール）とDevicetree（ハード構成記述ファイル）を使って、最終的なプログラムに含める要素を取捨選択することが可能です。（※）

例えば、Bluetooth通信や特定のドライバを有効にする一方で、不要なファイルシステムは外すといった柔軟な構成ができます。その結果、コードのサイズや依存関係を抑えられ、メモリや電力に厳しいデバイスでも扱いやすくなります。試作から量産まで同じ開発基盤を活用でき、効率と保守性を両立できる点も魅力です。

※出典：Zephyr Project「Devicetree と Kconfig」

 

小規模デバイスに適した軽量アーキテクチャ

Zephyr OSは、限られたリソースで効率的に動作するように設計されています。アプリケーションとカーネルを同じメモリ空間で動かせる構造を持ち、資源の割り当てをコンパイル時に固定することで処理の無駄を減らす方法です。この機能により、低消費電力のマイコンでもセンサー計測や無線通信などを安定して行えます。

また必要な機能だけを取り込む仕組みのため、更新時に影響が及ぶ範囲を限定しやすいのも特徴です。プロトタイプでは、最小限の構成にとどめ、量産時に必要な機能を段階的に追加するなど、開発プロセスに合わせて柔軟に拡張できます。

 

複数アーキテクチャをサポートする移植性

Zephyr OSは、ARM Cortex-M/A/R、Intel x86、RISC-V、ARC、Xtensaなど、幅広いCPUアーキテクチャを公式にサポートしています。（※）

共通のビルドシステムと抽象化されたドライバモデルを備えているため、異なるハードウェア間での移植作業にかかる工数を抑えることが可能です。例えば、評価ボードで開発したソフトウェアを将来別のSoC（システム・オン・チップ）へ移行する場合でも、基本構造を大きく変えずに対応できます。

この柔軟性により、製品ライフサイクルの長期運用に耐えられるだけでなく、新しいハードを積極的に採用する戦略にも適しているでしょう。

※出典：Nordic Semiconductor「Zephyrのご紹介」

 

Zephyr OSの利点

Zephyr OSの利点は、製品導入を想定したセキュリティの強化、長期運用を可能にする体制、開発を効率化するツール群です。ここでは、それぞれの具体的な内容について解説します。

 

商用利用に対応したセキュリティ強化機能

Zephyr OSは、製品開発で必要となるセキュリティ基盤を備えています。脆弱性が見つかった際の報告方法や対応ルールを公開しており、透明性の高い運用が可能です。また開発者向けにセキュアコーディングの指針や、ソフトウェア強化の手法も提供しています。カーネルはMPU（メモリ保護機能）による安全対策が施され、スタック保護や制御フロー保護も選択可能です。

またZephyr OSは、高いセキュリティやメモリ保護機能を持つCPUアーキテクチャの「Armv8-M」と連携できます。その場合は、Armが提供するセキュリティ基盤ソフトウェアの「Trusted Firmware-M（TF-M）」と組み合わせる形です。（※）

TF-Mは、起動時の正当性確認、暗号処理、データ保護などを担っています。Zephyr OSと連携することで、機密情報を扱う処理を、安全に実行できる環境を構築可能です。この仕組みは第三者による監査やセキュリティ認証にもつなげやすいため、商用製品として長期運用するシステムに向いています。

※出典：Zephyr Project「Trusted Firmware-Mの概要」

 

長期運用を支えるLTSとコミュニティサポート

Zephyr OSは、定期的なアップデートと長期サポート（LTS）で製品の長期運用を支えます。通常のリリースは「およそ4カ月ごと」に実施され、新機能や改善が継続的に追加される形です。（※）

LTSでは「2年以上」の修正提供が保証されており、安定した基盤を維持できます。（※）

LTSの更新状況は、GitHubで確認できるため、導入企業は安心して運用方針を立てることが可能です。またThe Linux Foundationには多くの企業が参加しており、近年はルネサスやWind Riverがプラチナメンバーに加わるなど、支援体制が強化されています。（※）

そのため、透明性と継続性を重視する長期製品にも対応しやすい環境が整っていると言えるでしょう。

※出典：

Zephyr Project「リリースプロセス」

Zephyr Project「Zephyr Project Overview」（Page 40）

Zephyr Project「プラチナ Zephyr Project」

 

開発効率を向上させるビルドシステムとツールチェーン

Zephyr OSには、開発を効率化する専用ツール群がそろっています。ソース取得、ビルド、書き込み、デバッグを一元管理する「west」や、設定を自動化する「Kconfig」などです。主なツールや仕組みを以下にまとめています。

これらのツールや仕組みを活用することで、試作から量産まで一貫したフローを維持することができ、開発効率と品質を両立することが可能となります。

※出典：

Nordic Semiconductor「ビルド、フラッシュ、デバッグ」

Zephyr Project「Zephyr SDK」

Zephyr Project「入門ガイド」

 

Zephyr OSの利用分野

Zephyr OSは、小型センサーからウェアラブル機器、産業機器まで幅広く対応します。ここでは、主に利用されている分野を紹介します。

 

IoTデバイスやセンサー制御への活用

Zephyr OSは、センサー制御を統一的に扱える仕組みを備えています。センサーAPIとサブシステムを利用すると、温湿度や照度などのデータを安全に取得可能です。設定はDevicetreeで記述でき、不要な機能を外すことでリソースを節約できます。Devicetreeとは、制御基板のハードウェア構成を記述するためのテキストファイルです。（※）

多数のサンプルコードが提供されているため、評価ボードを使った検証を始めやすい点も特徴となります。クラウドと連携する際にはLwM2Mクライアントを使用することで、一元管理や遠隔制御が可能です。

またZephyr OSは、省電力マイコンでも安定稼働できるため、環境モニタリングや状態監視システムの基盤としても適しています。

※出典：Qiita「Zephyr RTOS 〜 Devicetree 序章 〜」

 

ウェアラブル端末やヘルスケア機器への応用

Zephyr OSは、Bluetooth Low Energy（BLE）の通信スタックを標準で備えています。BLEとは、省電力・低消費電力を重視した短距離無線通信技術のことです。（※）

BLEを利用することで、心拍や歩数などを継続的に計測し、スマートフォンへ効率的に送信できます。またGATTを利用した通信機能により、アプリケーションへのデータ反映もスムーズとなります。GATTとは「Generic Attribute Profile」の略で、BLE機器が持っているデータ構造と操作方法を定義したものです。（※）

また、Zephyr OSでは、BLEのアーキテクチャやAPIが整備されているため、開発者は容易に実装を進めることができます。実際に血圧計や活動量計などのヘルスケア機器での採用例も報告されています。（※）

低消費電力と安定した接続性を両立できるため、ウェアラブル端末や医療機器のように長時間使用する装置に適していると言えるでしょう。

※出典：

Google for Developers「Bluetooth Low Energy」

TechWeb「GATTとは」

Zephyr Project「心拍モニター（周辺機器）」

 

産業機器やスマートホーム製品への導入

Zephyr OSは、工場やビルの管理システム、家庭用家電などの制御基盤としても活用されています。例えば、ビル内の防災、セキュリティ、照明、空調などのさまざまな設備機器の一元管理や、軽量な通信プロトコルであるLwM2Mを用いてクラウドと連携し、複数機器の状態監視、設定値の一括変更などの制御です。

また産業機器としては、評価ボードを使って早期検証を行い、製品用SoCへスムーズに移行する流れが取りやすいのも利点と言えるでしょう。SoCは「System on a Chip」の略で、CPUやグラフィック、無線通信、メモリなど、多数の機能を1枚の半導体に集積した回路です。

スマートホーム分野では、低消費電力と無線通信を組み合わせることで、利便性を高められます。公式の事例や技術資料が公開されているため、導入検討や設計の参考にしやすい環境が整っている状況です。

 

Zephyr OSと他のRTOSの比較

Zephyr OSは、ライセンス形態や開発体制、利用環境が他のRTOSとは異なります。ここでは、代表的なRTOSである「FreeRTOS」「Mbed OS」「ThreadX」との違いを解説します。

 

FreeRTOSとの相違点

RTOSは、用途や開発体制によって選択基準が変わります。特にZephyr OSとFreeRTOSは、多くの組み込み機器で検討対象となる代表的な存在です。両社はライセンスの仕組みやエコシステムの広がり、機能の構成方法に違いがあります。それぞれの特徴を下表にまとめました。

Mbed OSとの相違点

Zephyr OSとMbed OSは、開発体制と将来の運用面で大きな違いがあります。Zephyr OSはThe Linux Foundationのもとで継続的に更新され、ボードやドキュメントも整備され続けている状況です。一方、Mbed OSはArmが推進していましたが、2026年7月にEOL（サポート終了）が発表され、今後の積極的な保守は期待できません。（※）

導入検討時には、標準化された管理方法を持つZephyr OSと、保守方針が変わるMbed OSの違いを理解しておくことが重要です。

※出典：ARM「Mbed OS EOL 発表」

ThreadXなど商用RTOSとの相違点

Zephyr OSとThreadX（Azure RTOS）は、ライセンス条件と自由度の点で対照的です。Zephyr OSは、Apache 2.0ライセンスで提供され、自由に改編や再配布が可能となっています。（※）

一方、ThreadXは、ソースは公開されていますが、商用利用には制約がある状況です。

プレライセンス対象MCUであれば利用可能ですが、その他では別途契約が必要となります。導入時には、自社製品に使うMCUが対象かどうかを確認し、自由度を優先するかコストや契約条件の明確さを優先するかで判断が必要です。

※出典：Zephyr Project「Zephyrプロジェクトコンポーネントのライセンス」

Zephyr OSとLinuxの比較

Zephyr OSとLinuxは設計思想が異なり、使われる場面にも違いがあります。ここでは、リアルタイム性、多機能性、要件定義を基準にした選定方法を解説します。

 

リアルタイム性能におけるZephyrの優位性

Zephyr OSは遅延を最小限に抑えるリアルタイム性能が強みで、制御装置や計測機器に適したRTOSです。主な特徴としては、次の内容になります。

• 優先度ベースのスケジューラで安定したタスク制御
• 軽量カーネルにより処理のばらつきを軽減
• タイマーとクロックを統合し期限管理を容易化
• KconfigやDevicetreeで静的に構成を定義
• リアルタイム性が必須な分野で有効に機能

リアルタイム性が求められる現場では、処理の遅れが致命的な結果を招く場合があります。Zephyr OSは軽量カーネルとシンプルな設計により、応答の確実性を高める仕組みが特徴です。

また構成を静的に定義できるため、実行時の不安定要素を減らせる点も安心材料と言えるでしょう。こうした特徴から、Zephyr OSは産業用制御や医療機器など、安定したリアルタイム動作が必要な製品に適しています。

 

拡張性と多機能性におけるLinuxの強み

Linuxは多機能かつ拡張性に優れ、将来の機能追加や大規模システム開発に適したOSです。主な特徴は次の通りです。

• 豊富なドライバとユーザー空間の資産を活用可能
• ネットワークやセキュリティ機能を容易に統合
• Yocto Projectで再現性の高いイメージを生成（※）
• CI（継続的インテグレーション）との連携で開発から検証まで効率化（※）
• PREEMPT_RTでリアルタイム性能を補強可能（※）

Linuxは多彩なドライバやライブラリを活用でき、ネットワークやセキュリティ機能を一体的に構築できます。またYocto Projectを利用すれば、再現性の高いOSイメージを生成でき、開発から量産までの効率化が可能です。

リアルタイム性が必要な場合は、PREEMPT_RTを導入して強化する選択肢もあります。多機能性や将来的な拡張を重視するプロジェクトでは、Linuxは強力な基盤として選ばれやすいOSです。

※出典：

Wind River「Yocto Projectについて理解しよう」

Atlassian「継続的インテグレーションとは何ですか?」

The Linux Foundation「リアルタイムプリエンプションの技術的詳細」

 

要件定義に基づく適用範囲の判断基準

Zephyr OSとLinuxの選定では、性能やリソース制約を数値で明確化し、要件に基づいて適切なOSを判断することが重要です。それぞれのOSに適したケースを、下表にまとめています。

RTOSであるZephyr OSは、遅延を最小限に抑えつつ軽量な構成ができるため、小規模デバイスや厳格なリアルタイム応答が求められる環境に向いています。

一方Linuxは、豊富な機能と拡張性を備え、大規模システムや多様なアプリケーションの統合に強みのある点が特徴です。導入前には同一条件で両者を比較し、サポート体制や外部リソースの入手性も含めて検討することで、長期運用に耐えられる最適な選択が可能となります。

 

Zephyr OSの将来性とエコシステム

Zephyr OSの将来性は、国際規格への対応、商用サポートの拡大、オープンソースコミュニティの活動によって支えられています。ここでは、それらの特徴について解説します。

 

国際規格およびセキュリティ認証への対応状況

Zephyr OSは、IoT向けのセキュリティ基準「PSA Certified Level 1」を取得し、PSA Functional API認証にも合格しています。（※）

またCVE（脆弱性識別番号）の公式機関として、脆弱性の受付を行い、透明性の高い手続きを実施している状況です。（※）

ArmのTrusted Firmware-M（TF-M）と連携することで、安全な暗号処理や実行環境を提供できるのも特徴の一つです。将来の安全認証取得に備えて、監査に対応可能な長期サポート版（LTS）の整備も進められており、製品開発に必要な環境を充実させています。（※）

※出典：

GlobalPlatform「PSA認定 Zephyrプロジェクト証明書」

Zephyr Project「セキュリティとZephyr Project」

Zephyr Project「リリースプロセス」（長期サポート（LTS））

 

企業による商用サポートの拡大

Zephyr OSの支援体制は、年々強化されています。2025年にはルネサスとWind RiverがZephyrプロジェクトのプラチナメンバーに加わり、エコシステム全体への投資が拡大傾向です。（※）

Wind Riverは日本語による開発・運用サポートを提供しており、要件定義から保守までを一貫して支援できます。またZephyrプロジェクトに参加している企業は、トレーニングやプロフェッショナルサービスを通じて、技術者の育成を後押ししている状況です。

そのため、Zephyr OS導入企業は、製品開発に必要なサポートを受けやすくなり、長期的な運用に向けた体制を築きやすいと言えるでしょう。

※出典：

Zephyr Project「プラチナ Zephyr Project」

 

オープンソースコミュニティによる継続的な改善

Zephyr OSの開発は、活発なコミュニティによって継続的に進められています。リリースは約4カ月ごとに行われ、機能追加や改善が定期的に提供される状況です。（※）

また約2年ごとに長期サポート版（LTS）が公開され、製品用途に求められる安定性とセキュリティ更新が保証されています。（※）

リリースプロセスは文書化され、安定化の手順や公開履歴が誰でも確認可能です。このような透明性の高い開発体制により、企業は安心してZephyr OSを採用でき、長期製品にも適した選択肢となっています。

※出典：

Zephyr Project「リリースプロセス」

Zephyr Project「Zephyr Project Overview」（Page 40）

 

まとめ

Zephyr OSを選ぶ際は、軽量性やセキュリティ機能、サポート体制などを整理し、Linuxなどの他の選択肢との違いを理解して検討することが重要です。

Zephyr OSは、小規模デバイスでも効率的に動作する軽量カーネルと、柔軟なモジュール構造を備えています。必要な機能だけを組み込み、消費電力やメモリ容量を抑えられるのが特徴です。そのため、IoT機器やセンサー制御のような、省リソース環境に適していると言えるでしょう。

またセキュリティ機能の充実や長期サポート（LTS）、企業コミュニティによる活発な開発活動が、長期利用における安定性を支えています。自社の製品要件や運用方針に沿った形で、OSを選ぶことが重要となります。

最後に

ウインドリバーのZephyr RTOS 開発・運用支援サービス

詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

---

[2025年10月16日 時点]

組込みやIoT開発で主に使用されているOSは「RTOS」と「Linux」です。RTOSは応答の確実性が求められる制御系に強みがあり、Linuxは豊富なライブラリや保守性に強みがあります。そのため「RTOS」か「Linux」か、どちらを選択すれば良いのか迷うことも多いでしょう。

この記事では、RTOSとLinuxの違いや特徴を整理し、開発目的や要件に応じて適切に選定するための基準について解説します。

 

RTOSとLinuxの基本

RTOSとLinuxは、組込みシステム開発でよく比較されるOSです。ここでは、それぞれの特徴を整理し、なぜ多くの分野で注目されているのかを解説します。

 

RTOSの定義と特徴を整理

RTOS（リアルタイムOS）とは、処理の遅れが許されないタスクを確実に実行するために設計されたOSです。多くのベンダーから製品が出ており、μITRONやT-Kernel、VxWorksなどがあります。（※）

RTOSは、例えば自動車のブレーキ制御や医療機器のセンサー処理など、瞬時の反応が必要なシーンで利用されます。特徴としては以下のような点が挙げられるでしょう。

• タスクの優先度を基準に処理を切り替える仕組み
• 割り込み処理にすばやく応答できる性能
• 最悪応答時間を見積もりやすい設計

最悪応答時間（WCET: Worst Case Execution Time）とは、タスクが実行可能状態になってから、処理が完了するまでの最も遅い時間です。RTOSでは、この時間が保証されています。（※）

これらの特徴により、RTOSは「常に決められたタイミングで動くこと」が求められる場面で、強みを発揮します。

※出典：

IT用語辞典 e-Word「リアルタイムOS 【real-time operating system】 RTOS」

 

Linuxの定義と特徴を整理

Linuxはオープンソースで開発されている汎用OSで、もともとはPC向けに作られました。しかし現在では、組込み分野でも広く使われている状況です。主な特徴は以下の通りです。

• 豊富な機能やドライバがすでに揃っている
• ネットワーク通信やファイルシステムなどが標準で利用可能
• ソースコードを自由に変更できるためカスタマイズ性が高い

これらの特徴により、機能の多い製品や複数の外部機器と接続するIoT機器、スマート家電などに適しています。またLinuxは、開発者やコミュニティによる継続的な改良が行われている点も、長期運用や将来の拡張を見据えるうえで大きな強みです。

 

組込みOSとして両者が注目される理由

RTOSとLinuxは、どちらも注目されています。これは用途によって、それぞれの強みが異なるためです。

また、両方を組み合わせて、制御はRTOS、画面や通信はLinuxというように分担する「ハイブリッド構成」のシステムも存在しています。（※）

※出典：openEuler「Embedded SIG | Multi-OS Hybrid Deployment | Linux Server OS」（図1の下の説明部分）

 

RTOSとLinuxの違いを整理

RTOSとLinuxは、同じOSでも役割や得意分野が異なります。RTOSは「時間通りに処理する確実さ」を重視し、Linuxは「多機能性や拡張性」を重視している点です。ここでは、リアルタイム性、ハードウェア要件、開発環境という観点から、両者の違いを解説します。

遅延が致命的になる場面ではRTOSが適し、多少の遅れを許容できる場面ではLinuxが効果的です。目的に応じた選定が必要となります。

リソース制御とハードウェア要件の違い

RTOSは、軽量で数KBのメモリしかない小型マイコンでも動作可能です。Linuxは、多くのメモリや高性能なCPUを必要とし、豊富な機能が装備されているのが強みとなります。

実際の開発現場では、センサー制御やモーター駆動などのリアルタイム処理はRTOSに任せ、画面表示やネットワーク通信はLinuxに任せる「ハイブリッド構成」も一般的となっています。

 

開発環境とサポート体制の違い

RTOSは、ベンダーが提供する開発環境を利用します。Linuxは、「Yocto Project」などの環境を活用することで容易に開発が可能となります。

RTOSの具体的な環境としては、Arm Cortex-M向けの開発環境であるNXPの「MCUXpresso」、STM32マイクロコントローラ向けの開発環境であるSTMicroelectronicsの「STM32CubeIDE」などがあります。（※）

また、オープンソースのZephyr RTOSのように無料で導入できる選択も可能です。どのOSを選ぶかは、開発チームのスキルや製品の寿命、保守方針に応じて決めることが大切となります。

※出典：

Wind River「Yocto Projectについて理解しよう」

NXP「MCUXpresso統合開発環境 (IDE)」

STMicroelectronics「STM32CubeIDE」

 

RTOSを選ぶべき場面

RTOSは導入する場面を見極めることで、大きな力を発揮します。リアルタイム性、省リソース、省電力、安全規格対応といった観点から、その特徴を整理します。

 

高いリアルタイム性が求められる

RTOSは、処理の遅れが許されない用途に適しています。例えば、自動車のエアバッグ制御では、衝突から数ミリ秒以内に膨らませることが必要です。また心拍監視や産業ロボットの制御も、わずかな遅延が大きな事故につながるでしょう。RTOSは優先度制御や割り込み処理に強く、応答を一定に保ちやすい設計です。

一方、Linuxは多機能ですが、処理が集中すると遅延が生じる可能性があるため、こうした分野ではRTOSが選ばれています。

 

小規模メモリや低消費電力が重視される

RTOSは必要な機能だけを搭載できるため、数十KBのメモリでも動作可能です。この特性は、IoTセンサーやウェアラブル機器のように、省電力設計が必須の機器に適しています。多くのRTOSはCPUをアイドル時にスリープさせる仕組みを持ち、消費電力を抑えてバッテリー駆動時間を大幅に伸ばすことが可能です。

一方Linuxは多機能である反面、比較的メモリや電力を必要とするため、軽量デバイスには向きません。小型で長寿命が求められる機器では、RTOSが有利です。

 

安全規格に準拠したシステムが必要な場合

車載や医療分野では、「ISO 26262（自動車機能安全規格）」や「IEC 62304（医療機器ソフトウェア規格）」の準拠が必須です。（※）

RTOSにはこれらの規格に対応した製品が多く、ASIL-Dといった自動車分野の安全規格である「ISO 26262」の最高レベルに対応可能な製品もあります。またRTOS製品であるQNXは、豊富な認証実績を持ち、ドキュメントやツールも充実している状況です。

一方、Linuxでも安全対応の組み込みは進んでいますが、RTOSの方が長年の実績と専用サポート体制で一歩抜き出ています。

※出典：

日本自動車研究所「機能安全（ISO26262）」

 

Linuxを選ぶべき場面

Linuxは高機能なOSで、組み込み用途でも多く利用されています。ここでは、複雑な機能、豊富な資産、長期運用の観点からLinuxが適する場面を解説します。

 

複雑な機能やマルチタスクが必要

Linuxは同時に複数のアプリケーションを動かす「マルチタスク処理」に強みがあります。例えば、IoTゲートウェイや産業用制御装置では、ネットワーク通信、画像処理、音声認識といった異なる処理を一つのシステムに集約する必要があります。その場合、Linuxの「完全なマルチタスク」機能で、効率的にタスク配分が可能です。

またユーザー空間とカーネル空間を分けて動作させる仕組みにより、システムが安定しながらも柔軟な拡張が可能となります。この特性により、機能が多岐にわたる複雑な製品でLinuxは大きな効果を発揮します。

 

豊富なドライバやライブラリの活用

Linuxは膨大なデバイスドライバを標準で備えているため、USBカメラや無線LANモジュール、各種ストレージなどを追加開発なしで利用できます。ネットワーク関連機器についても、幅広くドライバが公開されており、開発期間を短縮することが可能です。

またThe Linux Foundationが提供する「The Linux Foundationのプロジェクト群」を利用すれば、機械学習や暗号化といった高度な分野でもオープンソースのライブラリを簡単に組み込めます。Linux Fundationのプロジェクト群とは、オープンソースや標準の発展を促進するために支援するプロジェクトです。（※）

新しいハードウェアやサービスをすばやく製品に組み込みたい場合、Linuxの既存資産を活用することは大きなメリットとなります。結果として、開発効率の向上と市場投入までのスピードアップが期待できるでしょう。

※出典：The Linux Foundation「The Linux Foundationについて」

 

将来的な拡張性や保守性を優先

Linuxはオープンソースであるため、世界中の開発者コミュニティによって継続的に改良や更新が行われています。製品を長期運用する際には、セキュリティ更新やバグ修正を受けられる点が大きな安心材料です。

長期サポート版カーネル「LTS」や業界団体が提供する「LTSI」、CIPによる超長期サポート「SLTS」などの仕組みを活用すれば、数年以上にわたる安定運用が可能です。（※）

また、Yocto Projectを利用すると、製品のライフサイクルに合わせたカスタマイズや再現性のある更新が実現できます。（※）

これらによって、Linuxは拡張性と保守性の両面で信頼性の高い選択肢となるでしょう。

※出典：

ThinkIT「Linuxカーネル「Linux 6.12」が長期サポート版に」

The Linux Foundation「LTSI 長期支援イニシアチブ」

Civil Infrastructure Platform「Linuxカーネルとコアパッケージ」（SLTS）

Wind River「Yocto Projectについて理解しよう」

 

RTOSとLinuxのトレードオフを整理

RTOSとLinuxは、どちらが優れているかではなく、用途に合うかどうかが重要です。ここでは、開発コストや性能、自由度、セキュリティなどの観点でそれぞれを解説します。

 

開発コストと開発スピードのバランス

開発にかかる時間や費用は、採用するOSによって大きく変わります。RTOSは短期間で開発を進めやすく、Linuxは工数や人件費がかさみやすい傾向です。

短期間での試作品や限定機能の製品なら、RTOSが有利ですが、多機能かつ長期的に改良を重ねる製品ならLinuxの方が結果的に効率的です。開発スピードとコストのバランスは、チームの規模や製品の将来像を踏まえて判断することが重要となります。

※出典：Wind River「Yocto Projectについて理解しよう」

 

性能・信頼性と自由度のバランス

システムを長期間安定して動かすか、柔軟な拡張を優先するかによって、選ぶOSが変わります。RTOSは安定した動作が特徴で、Linuxは複雑な機能に適しています。

安定した処理時間や長期稼働が必要ならRTOS、拡張性と多機能化を重視するならLinuxが適していると言えます。

 

長期運用とセキュリティアップデートのバランス

組み込み機器は10年以上使われることも珍しくなく、途中での更新や保守が重要なポイントとなります。RTOSはベンダーごとに異なり、Linuxは長期サポート体制が提供されています。

※出典：

ThinkIT「Linuxカーネル「Linux 6.12」が長期サポート版に」

Civil Infrastructure Platform「Linuxカーネルとコアパッケージ」（SLTS）

Yocto Project「4つのYoctoプロジェクトのコンセプト」（4.1 Yoctoプロジェクトのコンポーネント）

 

RTOSとLinuxの選定時に考慮すべきリスクと対策

RTOSやLinuxを選ぶ際は、性能やコストだけでなく運用で直面するリスクにも目を向ける必要があります。ここでは、障害対応、規格準拠、ツール活用の観点から対策を解説します。

 

トラブル発生時のデバッグや障害対応の難易度

組込みシステムでは、障害が発生すると原因の特定に時間がかかることが多く、OSごとに有効な対策が異なります。

RTOSは、構造がシンプルなため挙動を追いやすい反面、ログ取得や解析機能が限られていることもある状況です。その場合に有効なのが「JTAGデバッガ」です。JTAGデバッガは、メモリやレジスタの動きを直接観察できるため、詳細な障害解析が可能となります。（※）

一方、Linuxは多彩なログ機能やデバッグツールを備えており、障害発生時に詳細な情報を得られる強みがあります。ただし、ソースコードが膨大で依存関係も複雑なため、原因の切り分けに時間を要することも考えられるでしょう。

そのため、開発段階から運用を見据えて、どのツールを使い、どのようにログを管理するかを明確に設計しておくことが重要です。障害対応の仕組みを前もって整えておけば、復旧を早められるだけでなく、システム停止による業務への影響も最小限に抑えることができます。

※出典：CQ出版「基板用 JTAGデバッガ」

 

規格準拠や認証取得にかかる負担

自動車や医療機器、産業機械といった分野では、製品が必ず安全規格や法規制に適合している必要があります。

RTOSは、システムが軽量で機能範囲が限定されるため、認証の対象範囲が絞られ、比較的スムーズに審査が進むことが多い状況です。

一方、Linuxは機能が豊富で複雑なため、検証すべき範囲が広くなります。例えば、IEC61508（産業機械向け機能安全規格）やISO26262（自動車向け機能安全規格）といった国際規格への適合です。（※）

規格に適合させるため、多くの工数と時間が必要になる可能性があります。

また考えられるリスクとしては、開発の終盤になってから規格適合の不備が判明し、追加の修正や再検証でスケジュールが大きく遅れることです。そのようなことがないように、初期段階で規格要求を明確に洗い出し、OSの選定と同時に認証取得計画を立てることが必要となります。

※出典：

日本自動車研究所「機能安全（ISO26262）」

 

ツールの活用でリスクを減らす方法

OSの選択に関わらず、適切な開発ツールや共通システムであるエコシステムの考え方を取り入れることで、運用上のリスクを抑えられます。

RTOSの場合、ベンダーが提供する統合開発環境（IDE）や自動コード生成ツールを利用すれば、初期設定やドライバ実装のミスを防ぐことが可能です。例えば、NXPの「MCUXpresso」やSTMicroelectronicsの「STM32CubeIDE」などの開発環境となります。（※）

一方、LinuxではYocto Projectのようなビルドシステムを利用することで、複雑な構成管理やセキュリティ更新を効率的に実施することが可能です。ツールの選定を誤ると、障害対応やアップデートのたびに余計な工数が発生してしまう可能性があります。そのため、開発初期から利用可能なツールやサポートを調査し、運用を前提にした仕組みを整えておくことが、長期的なリスク低減につなげられます。

※出典：

NXP「MCUXpresso統合開発環境 (IDE)」

STMicroelectronics「STM32CubeIDE」

 

よくあるRTOSとLinuxの選定失敗ケース

RTOSとLinuxはどちらも強みがありますが、誤った選定をすると大きな手戻りやコスト増につながります。ここでは、起こりやすい失敗パターンを紹介し、判断時の注意点を解説します。

 

RTOS選定で失敗するケース

RTOSは軽量でリアルタイム性に優れているため、制御処理に適していますが、複雑な機能を統合する場面では限界があります。例えば、通信機能やクラウド連携、GUI表示、セキュリティ対策を追加する段階で、必要なドライバやライブラリが不足しやすく、結果として独自実装が増えることになるでしょう。このような状況では、開発コストや期間が大幅に膨らみ、想定以上の負担となることが少なくありません。

Linuxに標準搭載されているネットワークスタックや豊富なライブラリを活用していれば、効率的に開発を進められる可能性が高いでしょう。多機能を前提とした製品や長期的に運用するシステムでは、RTOS単独ではなくLinuxを採用する判断が適切です。

 

Linux選定で失敗するケース

Linuxは多機能で拡張性に優れていますが、厳密なリアルタイム性が求められる場面では不向きです。負荷が集中した時に処理応答にばらつきが出やすく、最悪応答時間（処理が最も遅れる時間）を守ることは難しいでしょう。特にモーター制御や医療機器のように、わずかな遅れが事故や不具合につながる分野では、リスクが高いと言えます。

本来であれば要件を数値化し、ツールで遅延の分布を評価するテストが必要です。リアルタイム性を軽視してLinuxを採用すると、設計の大きな見直しを迫られる典型的な失敗につながります。

 

まとめ

今回は、RTOSとLinuxの基本的な特徴や違い、活用しやすい場面、選定時に想定されるリスクと対策などを解説しました。RTOSはリアルタイム性や省リソース環境に適しており、Linuxは多機能性や拡張性、長期運用のしやすさに適しています。

重要なのは、自分たちのプロジェクトに必要な要件を明確に定義し、それに最も適したOSを選ぶことです。特徴を理解したうえで判断すれば、開発の効率性と信頼性を高めることが可能となるでしょう。

最後に

ウインドリバーのZephyr RTOS 開発・運用支援サービス

詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

---

[2025年10月16日 時点]

NXP® MIMXRT1060-EVKCで始めるZephyr®とMCUbootによるセキュアブート

セキュアブートとは

セキュアブートは、機器の起動時に読み込むソフトウェアの 署名やハッシュを検証して正規のコードだけを実行する仕組み です。
不正な改ざんやマルウェアの混入を防ぎ、システムを安全に立ち上げるための重要なセキュリティ機能です。

Zephyrとは

Zephyrは、Linux Foundationが主導する オープンソースのリアルタイムOS（RTOS） です。
軽量で省リソースながら、Bluetooth®やWi-Fi®などの通信機能、セキュリティ機能、デバイスドライバを幅広くサポートしており、マイクロコントローラからIoT機器まで幅広い組込み開発に利用できます。

MCUbootとは

MCUbootは、マイクロコントローラ向けに開発された オープンソースのセキュアブートローダ です。
アプリケーションの署名検証や暗号化をサポートし、ファームウェアの安全な更新やロールバック機能を提供することで、IoT機器や組込みシステムの信頼性とセキュリティを高めます。

開発環境

ボード外観と接続

画像上部のUSBケーブル : DEBUG ポートとPCを接続
画像下部のUSBケーブル : USB OTG ポートとPCを接続

環境構築

パッケージマネージャを使ってホスト環境にいくつかの依存関係をインストール

winget install Kitware.CMake Ninja-build.Ninja oss-winget.gperf python Git.Git oss-winget.dtc wget 7zip.7zip

7zip.exeのパスを環境変数に設定してください。

その他ツールをインストール

1. TeraTerm のターミナルプログラムをインストール
2. MCUXpresso IDE をインストール
3. MCUXpresso Secure Provisioning Tool (以後、SECと記載)をインストール
   • NXP® のウェブサイト にアクセスし、Windows 用の SEC インストーラをダウンロードします。
   • MCUXpresso_Secure_Provisioning_<version>.exe インストーラをダブルクリックしてインストールを開始します。

Zephyr MCUBoot デモを構築

0) 事前準備

コマンドプロンプトを起動して以下を実行してください。

# 新しい仮想環境を作成する
cd %HOMEPATH%
python -m venv zephyrproject\.venv

# 仮想環境を有効化する
zephyrproject\.venv\Scripts\activate.bat

# west をインストールする
pip install west

# Zephyr のソースコードを取得する
west init zephyrproject
cd zephyrproject
west update

# Zephyr CMake パッケージをエクスポートする
west zephyr-export

# west パッケージを使って Python® の依存関係をインストールする
west packages pip --install

# Zephyr SDK をインストールする
west sdk install

# mcumgr が未導入なら（Python venv でも可）
pip install mcumgr

# 署名鍵（ここでは RSA-2048）
imgtool keygen -k bootloader\mcuboot\root-rsa-2048.pem -t rsa-2048


1) MCUboot（ブートローダ）単体をビルド＆書き込み

MCUbootをビルド

west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-mcuboot bootloader\mcuboot\boot\zephyr

MCUbootのセキュアブート書き込み手順（SEC 使用）

1. ターゲットをSerial Downloaderモードに切り替え
   • MIMXRT1060-EVK の ブートスイッチ を Serial Downloader (USB) に設定
   • USB (DEBUG USB) を PC に接続
   • デバイスマネージャで HID デバイス / COM ポートが認識されていることを確認
2. SEC プロジェクトを作成
   • SEC を起動 → New Workspace を作成
   • 「Processor」は「MIMXRT1060」を選択
   • 「Boot」は「Authenticated(HAB)」を選択
3. 鍵作成
   • 「PKI management」タブで「Generate Kyes」ボタンを押下して「Authentication keys」を作成
   
4. ビルドイメージ作成
   • 「Source executable image」は、MCUbootのビルド結果が格納されているフォルダパスを設定
     • 例：「..\zephyrproject\build-mcuboot\zephyr\zephyr.elf」）
   • 「Authnetication key」は、「PKI management」タブで作成した鍵を任意で選択（例：SRK1:IMG1_1 + CSF1_1）
   • 「Build image」ボタンを押下してビルド実行
   
5. イメージ書き込み
   • 「Write image」タブで「Write image」ボタンを押下して書き込みを実行
   
6. ターゲットを通常ブートモードに切り替え
   • EVK のブートスイッチを FlexSPI NOR Boot に戻す
   • 再起動すると、MCUboot が起動し署名検証を実行 → 有効なアプリのみ起動
7. 動作確認

• シリアルターミナル（115200bps）で EVK をモニタ（以下のようなログが出ていれば動作しています）

2) 警告（USB重複）を消す：オーバレイでどちらか無効化

usbd@402e0000 と usbh@402e0000 が同アドレスで同時 enable だと DTS 警告が出ます。使わない方を無効化 してください。

• 以下の場所に overlay ファイルを作成してください。
  • zephyrproject\bootloader\mcuboot\boot\zephyr\boards\mimxrt1060_evk.overlay
• overlayに以下を書き込んでください。USBホスト を無効化しています。

&usbh { status = "disabled"; };

（Host優先なら &usbd { status = "disabled"; };）

3) パーティションを確実に：pm_static.yml（推奨）

Slot1 へアップロードできるように、QSPI(8MB想定)に mcuboot/slot0/slot1 を明示します。

• プロジェクト直下に pm_static.yml ファイルを作成してください。

例：zephyrproject\bootloader\mcuboot\boot\zephyr\pm_static.yml

• pm_static.ymlに以下の内容を書き込んでください。
  

  # 例: MIMXRT1060-EVK の QSPI 8MB を想定
mcuboot:
address: 0x60000000
size: 0x00080000 # 512KB

  slot0_partition:
  address: 0x60080000
  size: 0x00380000 # 3.5MB

  slot1_partition:
address: 0x60400000
size: 0x00380000 # 3.5MB


4) v0.0.0 の SMP サンプル（mcumgrサーバ）をビルド＆書き込み

バージョンを付与して署名バイナリを生成します。

west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-smp-svr-v0 zephyr\samples\subsys\mgmt\mcumgr\smp_svr -- ^
-DOVERLAY_CONFIG=overlay-serial.conf ^
-DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\" ^
-DCONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS=\"--version=0.0.0\"


build-smp-svr-v0を実機に書き込みます。

west flash -d build-smp-svr-v0

5) mcumgr の接続を作成（UART）

mcumgr-cliのインストール

1. Go をインストール（未導入なら）

以下のURLからWindows 用 MSIをダウンロードして実行してください。

https://go.dev/dl/

1. mcumgr-cli をインストール（公式の Go CLI）

go install github.com/apache/mynewt-mcumgr-cli/mcumgr@latest

mcumgr 接続

mcumgr conn add COMPORT type="serial" connstring="dev=COM3,baud=115200,mtu=512"

• “dev=COM3”はデバイスマネージャーで「MCU-Link VCom Port」を確認することでポート番号がわかります。
  • 例：「MCU-Link VCom Port(COM3)」

mcumgr 操作 (イメージリスト表示)

mcumgr -c COMPORT image list

結果

Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
Split status: N/A (0)

6) v1.0.0 をビルドして Slot1 にアップロード

west build -p always -b mimxrt1060_evk/mimxrt1062/qspi -d build-smp-svr-v1 zephyr\samples\subsys\mgmt\mcumgr\smp_svr -- ^
-DOVERLAY_CONFIG=overlay-serial.conf ^
-DCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"bootloader/mcuboot/root-rsa-2048.pem\" ^
-DCONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS=\"--version=1.0.0\"


アップロード＆イメージリスト表示

mcumgr -c COMPORT image upload -e build-smp-svr-v1\zephyr\zephyr.signed.bin
mcumgr -c COMPORT image list


結果

Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
image=0 slot=1
version: 1.0.0
bootable: true
flags:
hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
Split status: N/A (0)


7) 新イメージを試す → 確定する

初期状態は以下を想定しています。

Images:
image=0 slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
image=0 slot=1
version: 1.0.0
bootable: true
flags:
hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
Split status: N/A (0)


• HASH0 = d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
• HASH1 = 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e

次回リセットで v1.0.0 を試す

mcumgr -c COMPORT image test <HASH1>

コマンド実行後にリセットします。

結果

slot0とslot1が入れ替わっていることを確認します。

Images:
image=0 slot=0
version: 1.0.0
bootable: true
flags: active
hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
image=0 slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: d62f08cd883eb7d31508bfe32be94df20a773a1cd27ed79cfc51254d333c43d7
Split status: N/A (0)


端末が v1.0.0 で起動したら、永続化（ロールバック防止）

mcumgr -c COMPORT image confirm <HASH1>

• confirm しないで再起動すると、MCUboot は 0.0（slot0）へロールバックします。

コマンド実行後にリセットします。

結果

Images:
image=0 slot=0
version: 1.0.0
bootable: true
flags: active confirmed
hash: 1193fbc56fd090c787a33b98de6ca3a72b9a36ff7f41048bad463c384ea2e10e
Split status: N/A (0)


最後に

ウインドリバーのZephyr RTOS 開発・運用支援サービス

詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

---

NXP® は NXP Semiconductors N.V. の登録商標です。
Zephyr® は The Linux Foundation の商標です。
Windows® は米国およびその他の国における Microsoft Corporation の登録商標です。
Python® は Python Software Foundation の登録商標です。
Bluetooth® は Bluetooth SIG, Inc. の登録商標です。
Wi-Fi® は Wi-Fi Alliance の登録商標です。

---

[2025年10月07日 時点]

Zephyrとは

Zephyrは、Linux Foundationによってオープンソースで開発が進めらているIoT向けのRTOS(リアルタイムオペレーティングシステム)です。
軽量で、x86、arm、RISC-Vなどのさまざまなアーキテクチャに対応し、リアルタイム機能を持ち、さまざまなプロトコルスタックを実装し、セキュリティを重視していることなどを特長とします。

STM32N6570-DKとは

STM32N6570-DKは、2024年にSTMが販売を開始した評価用ボードです。
Arm® Cortex®-M55コアベースのマイクロコントローラ(STM32N657X0H3Q)が搭載されています。

本コラムでは、STM32N6570-DK上でZephyrを動かして、シリアルとLEDとデバッガーを動作させる手順を説明します。
Windows環境ではGUIによるデバッグは未サポートのようなので、コマンドラインでデバッグを行う方法も簡単に説明します。

開発環境

ホストマシンはUSB-Cポートがあるとよいです。
Type-Aだと供給電力の問題で、カメラやディスプレイを動かすときに特に動作が不安定になることがあります。

関連ソフトウェア

Windowsには以下のソフトウェアをインストールしておく必要があります。

開発環境の構築

開発環境の構築はコマンドラインからできます。
Windows PowerShellを開いて、以下のコマンドを実行すれば開発環境を構築できます。

> mkdir zephyr
> cd zephyr
> python -m venv zephyrproject\.venv
> Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
> zephyrproject\.venv\Scripts\Activate.ps1
> pip install west
> west init zephyrproject
> cd zephyrproject
> west update
> west zephyr-export
> west packages pip --install
> $env:PATH = "C:\zephyr;" + $env:PATH
> $env:PATH = "C:\Program Files\7-Zip;" + $env:PATH
> cd zephyr
> west sdk install


二回目以降

いちど「west sdk install」まで実行したらこれ以降は、
PowerShellを開くたびに以下のコマンドを実行してPythonの仮想環境を有効化することでZephyrのビルドができるようになります。

> cd C:\zephyr
> Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
> zephyrproject\.venv\Scripts\Activate.ps1
> cd zephyrproject\zephyr


samples/basic/blinkyアプリケーションのビルド

開発環境の構築とシェルの設定ができたら、以下のコマンドでsamples/basic/blinkyアプリケーションをビルドできます。
samples/basic/blinkyは、LEDをチカチカ点灯させる、いわゆるエルチカです。

> west build -b stm32n6570_dk//fsbl samples/basic/blinky


(–sysbuildオプションつきのMCUBootベースのアプリケーションだと、セキュアブートとなってしまい、デバッガーが接続できなくなってしまうようです。)

アプリケーションの書き込み

アプリケーションの書き込みを書き込むには、STM32N6570-DKのブートスイッチ「Development boot」にする必要があります。
以下が「Development boot」の設定です。

BOOT0: 0 (左)
BOOT1: 1 (右)


「STLINK V3EC」ポートをUSBケーブルでPCとつないだ状態で、以下のコマンドを実行すれば、ボードのフラッシュメモリにプログラムを書き込めます。

> west flash


シリアルとLED

プログラムを実行する前にTeraTermを起動して「STMicroelectronics STLink Virtual COM Port」を開いておきます。
また、シリアルポートの設定をしておきます。

ボードのブートスイッチを「Flash boot」にし、ボードのリセットスイッチを押すと、プログラムを実行できます。
以下が「Flash boot」の設定です。

BOOT0: 0 (左)
BOOT1: 0 (左)


シリアルの動作が確認できました。

LEDの動作も確認できました。

デバッグ設定

アプリケーションのデバッグのためには、コンパイル最適化を抑制する必要があります。
C:\zephyr\zephyrproject\zephyr\samples\basic\blinky の prj.conf で、デバッグ用のオプションの設定(CONFIG_DEBUG)を記述することで、コンパイル最適化を抑制できます。
prj.confの内容は、以下のようにすればよいです。

CONFIG_GPIO=y
CONFIG_DEBUG=y


「west build ～」で再ビルドして、「west flash」でアプリ再書き込みを行えば、デバッグができるようになります。

デバッガー

以下のコマンドでデバッガーを起動できます。

> west debug


デバッガーの動作が確認できました。 

コマンドラインからのデバッグは、デバッガーへの命令をすべてコマンドで送る必要があります。

ブレークポイント

ブレークポイント(一時停止する箇所)の設定は「b 関数名」でできます。
その後、「c」でプログラムを実行できます。
ブレークポイントに到達すると、プログラムはブレーク(一時停止)します。
「l」で周辺のソースコードを表示できます。

z_cstart()はZephyrで最初の方に呼ばれる初期化の関数です。

ステップ実行

プログラムを一行ずつ実行するのは「s」でできます。
「s」は「ステップ・イン」で、関数があると関数の中に入ります。

 「スペース」を押すと直前のコマンドを繰り返せます。

「ステップ・オーバー」は「n」で、関数があると関数の中に入らずに次の行に進みます。

バックトレース

「bt」はバックトレースを表示します。
これで関数の呼び出し関係がわかります。

変数の値の表示

ローカル変数の値の表示は「i lo」でできます。

main()関数の44行目まで飛んで、ローカル変数の値を見てみます。

変数の値の変更

変数の値の変更は「p 変数名=値」でできます。

ローカル変数led_stateの値を変更してみます。

その後コンソールでprintf()の表示をみると、値が変更されて結果も変わったたことがわかりました。

最後に

以上になります。
このコラムが、皆様がSTMボードやZephyrに興味を抱くきっかけになりましたら幸いです。

ウインドリバーのZephyr RTOS 開発・運用支援サービス

詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。

---

• STM32® は STMicroelectronics International N.V. またはその関連会社の登録商標です。
• Arm および Cortex は、米国およびその他の国における Arm Limited（またはその子会社）の登録商標です。

---

[2025年08月22日 時点]

多くの企業で利用されているLinuxは、一般的に安全といわれています。しかし、システムの設計ミスや運用の不備によって脆弱性が生まれ、情報漏洩やサービス停止と言った被害を引き起こす可能性も少なくありません。

脆弱性とは、システムやソフトウェアに存在しているセキュリティ上の欠陥を指します。（※）

そのため、脆弱性は早期発見と早期対策が重要といえるでしょう。

この記事では、Linuxの脆弱性についての基本から、実際の被害事例、今すぐ実践できる対策などを分かりやすく解説します。

※出典：総務省「脆弱性とは？」

 

Linuxの脆弱性とは何か

Linuxは高い安定性と信頼性があり広く利用されていますが、脆弱性が存在しているのも事実です。ここでは、Linuxに潜む脆弱性について、その定義や種類、原因を分かりやすく解説します。

 

脆弱性の定義とセキュリティ上のリスク

脆弱性とは、ソフトウェアやシステムに存在するセキュリティ上の欠陥です。この欠陥が悪用されると、第三者による不正アクセスや情報漏洩の原因になります。

例えば、認証をすり抜けるコードの記述ミスや、古いライブラリを使用している場合などです。脆弱性を放置すると、攻撃者に侵入のきっかけを与えてしまうため、脆弱性の早期発見と適切な対策がシステムの安全を守る鍵となります。

 

Linuxにおける主な脆弱性の種類

Linuxで多く見られる主な脆弱性は、権限昇格、バッファオーバーフロー、サービス妨害です。下表に主な脆弱性の種類をまとめました。

これらは古いカーネルやソフトウェアを利用している場合、簡単に成功してしまいます。脆弱性の種類を理解し、事前の対策が重要といえるでしょう。

 

脆弱性が生まれる原因とは

Linuxの脆弱性が生まれる主な原因には、次のものがあります。

• ソフトウェアの設計ミスや実装ミス
• 開発時に十分なテストが行われていない
• オープンソースのためコードの公開範囲が広く、攻撃者が問題点を見つけやすい
• 長期間アップデートされていない
• 古いパッケージを使用している
• 管理者側の設定ミスや脆弱性情報を把握していない

このように技術的な問題だけでなく、運用面の甘さも脆弱性を生む原因となります。これらの原因を理解することで、予防の精度を高めることが可能となるでしょう。

 

Linux脆弱性による被害事例

Linuxシステムに脆弱性がある場合、情報漏洩やサービス停止、企業の信頼失墜といった重大な被害を招く可能性があります。ここでは、代表的な事例を紹介します。

 

システム侵害による情報漏洩

Linuxサーバーの脆弱性を突かれ、顧客情報や社内資料が不正に取得されることがあります。2024年に報告された「CVE-2024-6387」は、OpenSSHに関する脆弱性で、リモートからroot権限を奪取されるリスクです。（※）

この問題により外部からの第三者の侵入を許してしまうため、企業内の機密情報や個人情報が流出してしまう可能性があります。

※出典：MITRE社「CVE-2024-6387」

 

サービス停止・業務への影響

「CVE-2021-3156（sudoのヒープバグ）」は、特権昇格に悪用される脆弱性として知られています。（※）

この脆弱性によってローカルユーザーがrootに権限昇格してしまう可能性があるため、悪用されるとシステムに重大な影響を及ぼします。その結果、企業のサービス停止や物流・販売システムの停止など、業務に大きな損害が出てしまう要因となるでしょう。

※出典：MITRE社「CVE-2021-3156」

 

企業ブランドの信頼失墜

Linuxで利用されているファイル圧縮ツールの「XZ Utils」に悪意のあるコードが挿入されていました。2024年に「CVE-2024-3094」として報告されています。（※）

特定の条件が整うと、外部から攻撃者がSSHポート経由で接続できるようになる問題です。Linuxパッケージに「XZ Utils」を含めている場合、配布元の企業が攻撃経路を組み込んでいることになるため、企業の信頼を失墜させる要因となります。

※出典：MITRE社「CVE-2024-3094」

 

Linux脆弱性をチェックし対策する方法

脆弱性は早期発見と迅速な対処が重要です。ここでは、脆弱性を調べる方法と、チェック後の基本的な対策方法を解説します。

 

脆弱性情報の確認手段

Linux脆弱性を調べる際は、信頼性の高い情報源から最新の情報を得ることが重要です。国内ではIPAとJPCERTが運営するJVN（Japan Vulnerability Notes）があり、企業向けに脆弱性情報を提供しています。（※）

海外サイトでは、米国NISTのNVD（National Vulnerability Database）です。（※）

NVDでは、世界中の脆弱性情報をCVE番号（共通脆弱性識別子）付きで掲載しています。自社で使用しているソフトウェアやカーネルのCVE番号を検索し、影響範囲や深刻度を確認することで、優先的に対応すべき脆弱性が明確になります。

 

※出典：JVN（Japan Vulnerability Notes）「脆弱性関連情報と対策情報」

NIST「国家脆弱性データベース」

 

自動スキャンツールの活用

自社のLinuxサーバーに脆弱性がないかどうかを自動的にチェックする方法として、スキャンツールの活用が有効です。代表的なものに「OpenVAS」や「Lynis」があり、いずれもオープンソースで利用できます。（※）

OpenVASは、ネットワーク経由で多様な脆弱性を検出し、レポートを生成します。Lynisは、コマンドラインで実行し、システム構成やパーミッション、パッケージの状態を総合的に診断可能です。いずれも継続的な運用を前提とし、定期的にレポートを確認することで脆弱性の見落としを防げます。

※出典：Greenbone Networks GmbH「OpenVAS」

CISOFY「Lynis」

 

定期的なパッチ適用・アップデートの徹底

脆弱性対策でもっとも基本的で確実なのが、セキュリティパッチの適用です。Linuxを使用するための環境を一つにパッケージングしたものを「Linuxディストリビューション」と呼びます。

「Red Hat」「Ubuntu」などのLinuxディストリビューションでは、脆弱性が発見されると対応パッチが随時提供される形です。特に深刻な脆弱性に関しては、緊急アップデートとして配信されることもあるため、随時適用することが重要となります。運用中のサーバーなど、すぐに適用が難しい場合は、適切なスケジュールと手順のもとで継続的にアップデートを行える体制づくりが大切です。

 

Linux脆弱性対策の強化

組み込みLinuxの脆弱性対策を包括的に実施するには、Wind River Linux Servicesがおすすめです。脆弱性を検出するCVEスキャンから長期保守まで、企業が直面する不安に応える施策が可能となっています。

 

CVE対応と長期サポートで脆弱性リスクを低減する

Wind Riverは、SBOM（Software Bill of Materials）やプラットフォームマニフェストを分析し、組み込みLinux環境に存在するCVEを自動検出します。またシステムの影響度の判定も可能です。これにより技術的な欠陥が解消され、リスクを抑えつつ長期にわたるサポートが可能となります。継続的な対応体制を整えることで、製品ライフサイクル全体の安全性を確保できます。

 

セキュアブートと署名済みパッケージで信頼性を確保する

Wind River Linux Servicesは、セキュアブートとデジタル署名によって、ブート時の改ざん防止を実現します。これにより、マルウェアなどの不正なプログラムの起動を事前に防ぐ仕組みです。デジタル署名にはキー管理体制が不可欠となっており、Wind Riverでは設計や運用を支援します。組み込みLinux製品では、信頼できる起動の構築が製品信頼性の基盤となります。

 

Yocto Projectベースの管理性と更新性を生かす

Wind River Linux Servicesは、Yocto Projectベースのディストリビューションを使用し、高度なカスタマイズ性と安定した更新機能を両立しています。開発後の更新機能や継続的な脆弱性対策、コンプライアンス文書、高品質なボードサポートパッケージなどです。

 

まとめ

Linuxは高い信頼性がある一方で、設計や運用の不備により脆弱性が発生するリスクもあります。実際に情報漏洩やサービス停止などの被害事例も報告されており、定期的な脆弱性チェックとパッチ適用が不可欠です。

JVNやNVDによる脆弱性の情報収集、自動スキャンツールの活用に加え、Wind River Linux Servicesを活用したCVE対応や長期サポートの導入も有効です。Linux脆弱性対策は、技術面と運用面の両面から取り組む必要があります。

弊社のWind River Linux Servicesを利用することで、システム全体のセキュリティを継続的に維持することが可能です。

Wind River Linux Services

詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。

---

[2025年08月06日 時点]

DevSecOps（デブセックオプス）とは、 ソフトウェア開発の「開発（Development）」「セキュリティ（Security）」
「運用（Operations）」を統合する考え方です。 DevOps（デブオプス）から派生した概念であり、セキュリティを融合させ、
迅速かつ安全性の高い開発を目指すことが目的です。

DevOpsとは

DevSecOpsを説明する上で、まずはDevOpsから理解をする必要があります。
DevOpsとは、Development（開発）とOperation（運用）を組み合わせてできた言葉です。
文字の通り、開発担当者と運用担当者が協力をして、システムの価値を継続的に向上させるための概念です。

DevSecOpsができた背景

近年、DevOpsやアジャイルといった開発手法が広まりを見せています。
アジャイル開発は、要件や仕様の優先順位に基づき作業を細かく分割し、それらを短期間で繰り返し進める方法です。
これらの手法を組み合わせることで、開発期間の短縮と品質の向上が期待できます。
しかし、頻繁なリリースに伴い脆弱性テストを実施すると、工数増加により開発スピードが低下してしまうという問題もあります。
この問題に対応するために、セキュリティ対策を開発プロセス全体に組み込む「DevSecOps」という考え方が生まれました。

DevSecOpsのメリット

DevSecOpsでは、セキュリティ対策が開発サイクルの中に組み込まれており、問題が発覚した際に早期に対応することができます。
もし製品のリリース直前に脆弱性が見つかった場合、対応できる時間が限られているため、対処が困難になることが多いです。
この手法を採用することで、開発プロセスにおける安心感が高まり、製品の品質向上やリリースの迅速化にもつながります。

DevSecOps実現の為に必要な要素

DevSecOps実現に必要な要素は下記４項目となります。

１、セキュリティ対応を自動化するツールの導入・運用

具体的にツールを４つまとめました。

SAST（Static Application Security Testing）

ソースコードやバイナリを静的に解析することで脆弱性を早期に発見する手法です。
開発初期やコード記述の段階で実行することで、後工程での修正コストを抑える効果があります。
またCI/CDパイプラインへの組み込みにも適しています。

SCA（Software Composition Analysis）

オープンソースソフトウェア（OSS）や外部ライブラリに含まれる既知の脆弱性や
ライセンスリスクを検出するための分析手法です。
ビルド時やデプロイ前に実施することで、外部コンポーネント由来のリスクを事前に把握し、対処することができます。

DAST（Dynamic Application Security Testing）

実行中のアプリケーションに対して外部から攻撃をシミュレートすることで、ランタイム上の脆弱性を検出する手法です。
テスト環境やステージング環境で動作中のアプリケーションに対して行われ、
実際の挙動をもとにしたセキュリティ評価が可能です。

IAST（Interactive Application Security Testing）

アプリケーションにセンサーを組み込んで実行中の挙動を監視しながら脆弱性を検出するアプローチです。
SASTとDASTの特長を併せ持ち、実行環境に即した高精度な診断が可能となるため、
テスト中や実行中のフェーズでのセキュリティ対策として有効です。

これらのツールを組み込むことで、DevSecOpsの運用を支援することができます。

２、開発フローの見直しと最適化

CI/CDパイプライン(ソフトウェア開発からリリースまでの一連の工程を自動化し、効率化する仕組み)を導入することで、
プログラムのビルド・テスト・デプロイが自動化され、開発からリリースまでのプロセスが短縮されます。
これにより、変更や改善への迅速な対応が可能になります。

３、組織体制と文化の形成

失敗を前向きに捉え、継続的な改善につなげる柔軟な組織文化が求められます。
各部門の密な連携と、円滑な情報共有を行うことも重要です。

４、全社的なセキュリティ意識の共有と定着

セキュリティを全員の共通の責任として意識することが求められます。

弊社関連製品のご紹介

DevSecOpsを取り入れる上で有効な弊社製品をご紹介いたします。

Wind River Linux Services  ＜製品ページ＞

組込みLinuxプラットフォームの設計、実装、セキュリティ対策、ライフサイクルの管理を提供する サービス
ニーズに応じた５つのサービスで、Linux開発・運用で直面する課題を解決

SecDevice  ＜製品ページ＞

IoT製品/IIoTデバイス製品全般が対象
自動化検査及びテスト記録レポートを生成
ファジングテストで未知の脆弱性を確認
特許取得のスマート検証手法による高精度・時間短縮

SecSAM  ＜製品ページ＞

ソースコード不要でOSSモジュール分析が可能
SBOMを採用、管理と同時にリスクの追跡にも対応
コンポーネントのライセンスチェック機能

wolfSSL製品 ＜製品ページ＞

セキュリティ専門ベンダーの製品として最新プロトコル標準に対応し、世界中の組み込み製品で利用
組み込み機器やリソース制約のある環境向けに最適化されたSSL/TLSライブラリ
物理層、暗号アルゴリズム層、トランスポート層、アプリケーション層の各層で製品を展開

まとめ

DevSecOpsは、DevOpsの考え方を発展させたもので、
セキュリティを重視しながら開発プロセスの効率化と品質向上を図るアプローチです。
組織全体の文化を変化させていく必要があり、課題も多いですが、
迅速かつ安全なソフトウェア開発を実現することができます。
その結果、継続的な改善と自動化を通じて、高品質かつ信頼性の高い製品のリリースが可能になります。

本文中に記載されている会社名、製品名等は、各社の登録商標または商標です。

Wind River Linux Services

CentOSのEOL

CentOSは、長年にわたりサーバー環境や開発環境において最も利用されてきたLinuxディストリビューションの一つです。特に、その安定性とRed Hat Enterprise Linux（RHEL）とのバイナリ互換性により、無償で利用できる企業向けの選択肢として広く親しまれてきました。しかし、CentOSのEnd of Life（EOL）を迎えることは、ユーザーにとって大きな影響をもたらします。このEOLは、特にCentOS 7を使用している企業にとって、計画的な対応が求められます。

CentOS EOLの主な影響

1. セキュリティリスクの増加

   最も深刻な影響は、セキュリティのリスクです。CentOSがEOLを迎えると、セキュリティパッチやバグ修正が提供されなくなります。これにより、CentOSを使用しているシステムは新たに発見された脆弱性に対して無防備になり、攻撃者に悪用されるリスクが高まります。特に、企業や重要な業務システムでCentOSを使用している場合、このセキュリティリスクは業務の継続性に大きな影響を与える可能性があります。

2. 運用の混乱

   CentOSのEOL後、システムの更新やサポートを受けるために、他のディストリビューションへの移行を余儀なくされます。この移行プロセスは簡単ではなく、既存のシステムやアプリケーションとの互換性の問題、ダウンタイム、運用負荷の増加が懸念されます。特に、システムの規模が大きい企業にとって、これらの問題はリソースを大きく消費し、移行期間中の業務に支障をきたすことになります。

3. 代替ディストリビューションへの移行

   多くの組織が、CentOS Streamのようなオプションを検討しています。CentOS Streamはローリングリリースモデルを採用しており、より新しい機能が提供されますが、頻繁な更新が必要になるかもしれません。また、CentOSとバイナリ互換性がある他の代替ディストリビューションも直接的な代替として考えられます。

4. 延長サポートオプション

    一部の企業は、CentOS 7の延長サポートを提供しているため、移行を延期することができます。これにより、移行計画を立てる時間を確保できる一方で、セキュリティのリスクを引き起こす可能性があります。

5. コストとライセンス

   代替ディストリビューションへの移行は、追加のライセンス費用がかかる可能性があり、CentOSをコスト効果の高い解決策として使用してきた組織にとって、予算に影響を与えるかもしれません。

   

CentOSのEOLは、単なるディストリビューションのサポート終了以上の影響を及ぼします。

企業や開発者は、セキュリティリスクや運用の混乱を避ける為に、早急に代替ディストリビューションへの移行を検討する必要があります。

移行を急ぐ必要がある一方で、コストや運用負担を考慮した戦略的な移行計画を立てることが重要です。また、延長サポートを利用するなど、段階的な移行を選択する企業も増えると予想されます。

Wind River Linux Servicesは、組込みLinuxプラットフォームの設計、実装、セキュリティ対策、ライフサイクルの管理を提供する サービスです。ニーズに応じた５つのサービスで、Linux開発・運用で直面する 課題を解決します。

主なサービス内容

1.セキュリティスキャン※無償CVEスキャンサービス実施中

組込みLinux開発特有のニーズに合わせたプロフェッショナルグレードのセキュリティ脆弱性（CVE）スキャンを提供しより高品質なソフトウェアの構築と導入時間の短縮を支援します。

2.セキュリティの解析とレメディエーション

開発コードの品質向上をはじめ、アプリケーションの迅速なデプロイに役立つセキュリティのスキャン、解析、修正プランサービスを提供します。

3.ライフサイクル・パフォーマンス・アシュアランス

Linuxプラットフォームのマネジメントサービスやお客様の組込みシステムプロジェクトに対応したボードサポートパッケージを提供します。

4.ライフサイクルセキュリティ

ソフトウェアの開発からデプロイまでライフサイクル全体にわたってLinuxプラットフォーム上のCVEを継続的に監視、緩和、管理します。

5.アーキテクチャと実装

システム要件の解釈、プラットフォーム設計、推奨案など包括的なソリューションサービスを提供します。

詳細は製品ページをご覧ください。

• Wind River Linux Services「Linux開発・運用で直面する課題を解決」

詳細資料をご希望の方は以下フォームよりメールアドレスをご登録ください。