AVM を最初に動かすまでの運用パス

AVM をどう捉えるか

AVM は、単一の import 画面や単一の alert list としてではなく、 ワークフローとして捉えると最も理解しやすくなります。 reference-side data と inventory-side data の両方が重要です。 canonical linking は inventory quality を高めます。 vulnerability data と product references は matching 側を支えます。 そして alert generation が、 それらの入力を operational results に変えます。

つまり、最初の目標は一度で全部を完璧にすることではありません。 観測された software が、 どのように reviewable な alert state に変わるのか、 その流れを理解することが最初の目標です。

必要なもの

AVM を始める前に、次を準備してください。

• Java 21 以降
• AVM の jar ファイル
• MySQL（推奨）または組み込み H2 database のいずれか

設定の考え方

AVM は環境変数で設定できます。 これらの設定は、database connection、security behavior、 runtime options を制御します。

設定は次のどちらでも渡せます。

• 環境変数で指定する（推奨）
• コマンドライン引数で指定する（簡単に試す用）

環境変数を使う場合（推奨）

export SPRING_DATASOURCE_URL=jdbc:mysql://localhost:3306/your-db-name
export SPRING_DATASOURCE_USERNAME=your-db-user
export SPRING_DATASOURCE_PASSWORD=your-db-password
export APP_SECURITY_BOOTSTRAP_ADMIN_ENABLED=true
export APP_SECURITY_BOOTSTRAP_ADMIN_PASSWORD=your-admin-password
export SERVER_PORT=8080

その後、AVM を起動します。

java -jar asset-vuln-manager-0.1.0.jar

MySQL で実行する（推奨）

通常利用では、AVM は MySQL で動かす前提が最も適しています。 永続データを持ち、 より実運用に近い環境で使いたい場合の推奨構成です。

Quick start（コピペ用、コマンドライン引数）:

java -jar asset-vuln-manager-0.1.0.jar --spring.datasource.url="jdbc:mysql://localhost:3306/your-db-name" --spring.datasource.username="your-db-user" --spring.datasource.password="your-db-password" --app.security.bootstrap-admin.enabled=true --app.security.bootstrap-admin.password="your-admin-password" --server.port=8080

読みやすい形（Linux/macOS）:

java -jar asset-vuln-manager-0.1.0.jar \
  --spring.datasource.url="jdbc:mysql://localhost:3306/your-db-name" \
  --spring.datasource.username="your-db-user" \
  --spring.datasource.password="your-db-password" \
  --app.security.bootstrap-admin.enabled=true \
  --app.security.bootstrap-admin.password="your-admin-password" \
  --server.port=8080

最初のステップ

これは初回セットアップ用の流れであるだけでなく、 システムの通常運用ループでもあります。

Step 2: assets と software を import する

reference data が利用可能になったら、 asset と software の inventory を取り込みます。 assets は環境内の host anchor になります。 software rows は、後で linking と evaluation に使われる inventory-side evidence になります。

AVM では、asset identity が先に存在している状態で software import するのが最も有効です。 software rows は assets に紐付いており、 後から生成される alerts も host context の中で初めて意味を持つからです。

field-level の詳細や JSON examples については Import を参照してください。

Step 4: unresolved mappings を確認する

一部の software rows は unresolved のまま残ります。 これは正常です。 特に source data にノイズが多い場合や、 naming が canonical dictionary と異なる場合にはよく起こります。

unresolved mappings は早めに確認してください。 そこには、AVM が installed software の identity を理解するために まだ助けを必要としている箇所や、 aliases、synonyms、後続の review actions によって coverage を改善できる箇所が現れます。

背景となる review model については Concepts と Admin を参照してください。

Step 6: 結果を確認する

alerts が生成されたら、 それを生み出した context とあわせて確認します。 AVM は、final result だけでなく、 そこに至る path の品質も operators が見られるよう設計されています。

この段階で役立つ確認ポイントには、次のようなものがあります。

AVM の最初の30分

実践的な最初のセッションとしては、次の順番がおすすめです。

Example

新しいユーザーが、まず canonical reference data と vulnerability data を sync し、 次に少数の assets と software を import したとします。 いくつかの software rows はすぐに canonical vendor / product references に linked される一方で、 source naming が広すぎる、あるいは特殊すぎるために unresolved のまま残る rows もあります。 ユーザーは canonical / unresolved mappings を確認し、 reference coverage を改善し、 その後 alerts を生成します。

この最初の1サイクルを終えた時点で、 ユーザーは AVM の最も重要な考え方をすでに理解しています。 system は単に inventory を ingest しているのではなく、 observed software を、 review 可能で改善可能な vulnerability context に変えるのを助けているのです。

まとめ

AVM の Getting Started は、 一つの operational loop を理解することだと考えると分かりやすくなります。 参照データを投入し、 assets と software を import し、 canonical / unresolved mappings を確認し、 alerts を生成し、 その結果を context とともに確認する、という流れです。

このループが見えるようになると、 AVM 全体も理解しやすくなります。 system の価値は alerts を出すことだけでなく、 そこに至る path を可視化し、改善可能にしている点にあります。