組み込みソフトウェアの脆弱性管理で難しいのは、単に「CVE を検出すること」ではありません。難しいのは、その CVE がどのレイヤーに存在し、製品として本当に影響するのかを判断することです。 コンテナを使っている製品であればコンテナイメージ。Linux ベースであれば OS パッケージ。カーネルモジュールやデバイスドライバ。C/C++ で書かれたアプリケーション。さらに、Yocto や Buildroot で取り込まれる OSS、静的リンクされたライブラリ、設定ファイル、起動スクリプト、証明書、秘密情報。 これらを一つのスキャナでまとめて見ようとすると、どうしても粗くなります。逆に、レイヤーごとに「狙うべきもの」と「適した手段」を分けると、検出結果の解釈がかなり楽になります。 SBOM はこの考え方の土台になります。CISA は SBOM を、ソフトウェアコンポーネントとその関係を把握するための情報として位置づけており、脆弱性把握やサプライチェーンリスク管理に利用できます。NIST SP 800-161 Rev.1 も、製品・サービスのサプライチ

Linux ディストリビューションを選ぶとき、セキュリティだけを単体で評価するのは簡単なことではありません。カーネルや OpenSSL のバージョン、SELinux の有無だけを見ても、実運用で安全になるわけではないからです。 実際のサーバー運用では、脆弱性情報を追えること、パッチを適用し続けられること、監査に耐えられること、そして移行時に不用意なリスクを増やさないことが重要になります。 AlmaLinux は、CentOS Linux の後継候補として語られることが多いディストリビューションですが、セキュリティ観点で見ると、単に「RHEL 互換で無料」というだけではありません。本番環境で長く使う Linux として、セキュリティ運用に必要な仕組みがかなり現実的にそろっています。 ここでは、AlmaLinux の良さをセキュリティ観点で5つに絞って整理します。 1. 長期運用を前提にしたセキュリティパッチ提供 サーバーOSのセキュリティで一番重要なのは、「今安全か」ではなく「安全な状態を維持できるか」です。 AlmaLinux はエンタープライズ

Hi, there. 本日は、以前投稿したOpenSCAPの記事について深堀し、具体的な手順をお伝えします。 OpenSCAPで“まず安全側のベースラインを一気に作る”手順 Linux のハードニングで最初に消耗しやすいのは、設定の難しさそのものより、項目数の多さです。SSH、パスワード、ファイル権限、不要サービス、監査設定、カーネルパラメータを一つずつ手で詰めるやり方は、どうしても時間がかかり、設定漏れや設定ゆれも起きやすい。そこで発想を変えて、最初から ベンチマーク準拠のベースラインへまとめて寄せる ために使いたいのが OpenSCAP です。Red Hat は OpenSCAP を、設定コンプライアンススキャン、脆弱性評価、レポート生成、remediation に使う仕組みとして案内しています。 この記事の主題は「監査して学ぶこと」ではありません。最短で、安全寄りの標準形を作ることです。手順としては、WSL の Ubuntu を整える → OpenSCAP を入れる → 利用可能なプロファイルを確認する → ベースラインとの差分を評価する

Hi, there. 今回は、Linux OSのハードニングについてのお話です。 Linux のハードニングに興味を持つと、多くの人が最初にぶつかるのは、「設定項目が多すぎる」という壁です。カーネルパラメータ、認証設定、監査ログ、ファイル権限、不要サービスの停止。手で一つずつ詰めていく方法は勉強にはなりますが、全体像を掴む前に疲れてしまいやすい。しかも、手作業にはどうしても設定漏れや設定ゆれ、単純な見落としが入り込みます。そこで役に立つのが OpenSCAP です。OpenSCAP は SCAP 準拠コンテンツを使ってシステムの設定評価やレポート生成を行うためのツール群として案内されており、RHEL では SCAP Security Guide のプロファイルを使った評価や remediation、Ansible Playbook や Bash スクリプトの生成まで公式に整備されています。 OpenSCAP の本当の価値は、単に「CIS に照らして監査すること」ではありません。むしろ大きな価値は、ベースライン構築を標準化できることにあります。どの