はじめに
みなさん、はじめまして！
Openchainの活動にコミュニティ会員として参画している、森田と申します。
よろしくお願いします。
本日は、昨年末から今年にかけて世間でも大きく取り上げられた Log4jの脆弱性 について綴ってみます。
Log4jとは？
Log4jは、Javaベースのアプリケーションで頻繁に使用される「API」の1つで、正式名称は「Apache Log4j」です。
ちなみにAPIは、「Application Programming Interface」の頭文字をとったもので、誤解を恐れずに説明すると、「アプリケーションをプログラミングするためのインターフェース」のことを意味します。
Log4jは「ログを入出力するための機能」を有していることも特徴の一つです。
なぜLog4jに脆弱性が見つかって大きく取り上げられたのか
Log4jはJavaアプリケーションの標準的なライブラリであるため、世界中のJavaアプリケーションで広く利用されています。
これに加え、上記のようにLog4jは「ログを入出力するための機能」を有しているため、Log4jを用いて悪意のあるプログラムがリモート実行されることで、世界中のJavaアプリケーションが悪用されてしまう恐れがあるためです。
そのため、大手メディア媒体（ＴＶ，新聞）などでも大きく取り上げられました。
Log4jの脆弱性からの教訓
上記のように広範に利用されているために「どの製品またはシステム製品で使用されているか」が把握し難いのが問題点にあります。
仮にJavaを直接使用していないシステムであっても、実はバックエンドで動くJavaシステムという場合も有り得るため、バックエンドまでどのようなソフトウェアで構成されているかを把握することが大事だと考えます。
そのような有効策の一つとして「SBOM」が挙げられます。
SBOMとは、「Software Bill Of Materials」の頭文字を取ったもので、特定の製品に含まれるすべて（プロプライエタリおよびオープンソースなど）のソフトウェアコンポーネント、ライセンス、依存関係を一覧化したソフトウェア版の部品表を意味します。
SBOMの一例としては、Linux Foundationが運営するSPDXというSBOMフォーマットが存在します。
終わりに
仮に脆弱性が発覚した際には、その時点で情報管理できていないと、システムにまで影響が及ぶの否かの確認や対応手段などによる初動が遅れるリスクが高くなります。また、これに伴う相当な対策コストがかかることも想定されます。
今回のLog4jの脆弱性を教訓に、みなさんもぜひ脆弱性へのリスク対策を今一度見直すべきではないでしょうか？
Introduction
Nice to meet you all!
My name is Youhei Morita, and I am participating in Openchain activities as a community member.
Today, I'm going to write about the Log4j vulnerability that has been widely publicized from the end of last year to this year.
What is ”log4j”？
Log4j is one of the frequently used "APIs" in Java-based applications, officially named "Apache Log4j".
API is an acronym for "Application Programming Interface", and to avoid misunderstandings, it means "an interface for programming applications".
One of the features of Log4j is that it has a function for inputting and outputting logs.
Why was a vulnerability found in Log4j and it got a lot of attention?
Log4j is a standard library for Java applications, so it is widely used in Java applications around the world.
In addition to this, as mentioned above, Log4j has a "function for inputting and outputting logs", so Java applications around the world can be exploited by remotely executing malicious programs using Log4j. This is because there is a risk of being
Therefore, it was widely covered in major media (TV, newspapers), etc.
What we were reminded of by the Log4j vulnerability
The problem is that it is difficult to grasp "which product or system product is using it" because it is widely used as described above.
Even if the system does not use Java directly, it may actually be a Java system that runs on the backend.
One such effective measure is SBOM.
SBOM is an acronym for "Software Bill Of Materials".
That is, a software bill of materials that lists all software components (including proprietary and open source), licenses, and dependencies included in a particular product.
An example of SBOM is the SBOM format called SPDX, operated by the Linux Foundation.
General remarks
If a vulnerability is discovered, if information is not managed at that point, there is a high risk that the initial response will be delayed due to checking whether the system will be affected or not and taking countermeasures.
It is also assumed that there will be considerable costs associated with this.
Based on the lessons learned from this Log4j vulnerability, shouldn't you all reconsider your risk countermeasures against vulnerabilities?