2026.10.06 セキュリティ

FutureVulsとは？SSVCの優先度判定と料金・スキャナ導入とAPI連携の手順

FutureVuls（フューチャーバルス）は、フューチャー株式会社がOSSの脆弱性スキャナ「Vuls」を土台に提供している脆弱性管理のSaaSです。サーバやコンテナ、ライブラリの構成情報を集めて脆弱性を検知し、対応の優先度付けとタスク管理までを1つの画面で受け持ちます。

この記事では、SSVCによる優先度判定の仕組み、2026年10月時点の料金体系、Linuxスキャナの導入とsudoersの中身、GitHub ActionsでTrivy連携を動かす設定、REST APIで未対応タスクを集計するコードまでを順に扱います。最後に、FutureVulsを採用すべき条件と、TrivyやOSS版Vulsで足りる場面を言い切ります。

まとめ：FutureVulsを選ぶ条件と100ライセンスから始まる年間契約の前提

先に結論を置きます。FutureVulsは「脆弱性を見つける道具」ではなく、見つけた脆弱性を誰がいつ直すかを組織で回すための道具です。

契約は100ライセンスから：2026年10月時点の公開料金はCSIRTプランとPSIRTプランの2つで、どちらも要見積・年間契約です。数台のサーバだけを見たい用途には合いません。
価値の中心はSSVC：CVSSの点数順ではなく、悪用の有無と自社資産の露出度から「今すぐ」「次の定期保守」「対応しない」を振り分けます。
導入はコマンド1行だが権限は広い：Linuxスキャナの既定モードは、専用ユーザーにroot権限でのcatやfindを許可します。監査の厳しい環境では事前に説明が要ります。
CI連携とAPIで運用に組み込める：Trivyを同梱した軽量スキャナでイメージを送り、REST APIでタスクを取り出せます。ただし公式のCI例はそのままでは動きません。

FutureVulsの仕組み｜OSS版Vulsの検知とSSVCによる優先度付けの関係

FutureVulsを理解するには、OSS版Vulsとの役割分担と、優先度を決めるSSVCの2点を押さえれば足ります。

OSS版Vuls v0.41.0とFutureVulsの役割分担｜検知と対応管理の境界

土台のVulsはGo製のエージェントレス型スキャナで、GitHubのfuture-architect/vulsでGPL-3.0として公開されています。2026年10月6日時点の最新は2026年9月30日公開のv0.41.0で、スター数は12,000を超えています。

公式のよくある質問では、OSS版は「検知」に特化し、FutureVulsはSSVCによる優先度の自動判断、チケットによる対応管理、自動トリアージ、SBOM管理を加えたものだと整理されています。検知エンジンは共通で、差は検知した後の運用にあります。脆弱性データベースの更新もFutureVuls側がマネージドで受け持つため、OSS版で必要になるNVDやOVALの取得サーバを自前で持つ必要はありません。

SSVCの4つの判定軸と4区分の優先度｜KEVとPoCの有無で自動判定

SSVC（Stakeholder-Specific Vulnerability Categorization）は、CISAが公開している意思決定の枠組みです。FutureVulsでのSSVCの実装では、4つの判定軸のうち2つを自動で、残り2つを利用者の設定で決めます。

判定軸	決め方	取りうる値
Exploitation（悪用状況）	自動	active／poc／none
Automatable（攻撃の自動化）	自動	Vulnrichment・CVSS v4のAU値等
Exposure（露出）	利用者が設定	Small／Controlled／Open
Human Impact（業務影響）	利用者が設定	Low／Medium／High／Very High

Exploitationがactiveになる根拠にはCISAのKEVカタログやVulnCheck KEVが使われ、Metasploitなどに攻撃コードがあればpocです。結果はImmediate、Out-of-Cycle、Scheduled、Deferの4区分で、Deferは「現時点では対応しない」という判断を明示的に残すためのものです。CVSSの見方そのものはCVSSとは？スコアの見方・計算方法とv4.0の変更点で整理しています。

実務で効くのは、利用者が決めるExposureとHuman Impactです。ここを全サーバ既定値のままにすると、インターネットに出ていない検証機と公開Webサーバが同じ優先度になります。導入時に資産ごとの露出と業務影響を棚卸しするのが、SSVCを機能させる前提条件です。

2025年11月のEOL管理強化｜休眠OSSと公式EOLを一覧化する機能

2025年11月11日の機能追加で、サポート終了済みと終了間近のソフトウェアを一覧にするEOL管理が強化されました。2026年1月13日配信のプレスリリースによれば、実環境の2万件超のPURLを分析したところ約半数が実質的な休眠状態で、1割近くが公式にEOLを迎えていたといいます。

CVEが出ていなくても、更新が止まったライブラリは次の脆弱性が出た瞬間に直せません。EOLを脆弱性と同じ画面で追える点は、パッケージの版だけを見るスキャナとの違いになります。

FutureVulsの料金とプラン｜CSIRTとPSIRTの違いと100ライセンスの契約

料金は検索で最も情報が古くなりやすい項目です。公式ページの現行表記を基準に確認します。

公開料金ページの記載内容｜要見積の年間契約と旧1台4,000円表記の扱い

公式の料金ページに載っているのはCSIRTプランとPSIRTプランの2つで、どちらも「要見積」「請求書払い・年間契約」です。FAQでは両プランとも100ライセンスからの案内とされ、小規模なPoCは個別相談になっています。無料トライアルも規模や要件に応じた個別案内です。

比較サイトには「1台あたり月4,000円」というStandardプランの記載が残っていますが、2026年10月6日時点の料金ページにその表記はありません。見積りの前提に古い台単価を置かないよう注意してください。ライセンスの数え方（サーバ・コンテナ・ライブラリをどう数えるか）も公開されていないため、見積り依頼の段階で資産の内訳を出して確認するのが確実です。

非公開脆弱性の管理だけが分ける2プラン｜PSIRTを選ぶ製品開発の条件

機能表を見ると、LinuxとWindows、コンテナ、ライブラリ、ネットワーク機器、WordPressの対象範囲や、SBOM対応、自動トリアージ、シングルサインオン、監査ログは両プラン共通です。差は「非公開脆弱性の管理」がPSIRTプランだけにある点の1つしかありません。

自社のシステムを守る情報システム部門ならCSIRTプランです。自社製品を出荷していて、まだ公開していない脆弱性を社内で追跡し、修正版の提供まで管理する必要があるメーカーやSaaS事業者だけがPSIRTプランの対象になります。

Linuxにスキャナを入れて初回スキャンまで進める手順とsudoersの確認

ここから手を動かします。対象はインターネットに出られるLinuxサーバと、出られない閉域網のサーバの2通りです。

インストーラのワンライナーと環境変数｜グループIDとトークンの渡し方

スキャナのインストール手順では、画面に表示されるグループIDとスキャナ用トークンを環境変数で渡し、root権限でインストーラを実行します。通信先は導入要件にあるinstaller.vuls.biz、auth.vuls.biz、東京リージョンのS3バケットの3つと、各OSのパッケージリポジトリです。

# root で実行する（グループIDとトークンは画面の値に置き換える）
curl -s https://installer.vuls.biz/vuls-installer.sh | \
  VULS_SAAS_GROUPID='1234' \
  VULS_SAAS_TOKEN='xxxx-xxxx-xxxx' \
  VULS_SCAN_MODE='fast-root' \
  AUTO_REFRESH_BINARY=true \
  bash -s inst

# 初回スキャンを手動で走らせる（以降は cron で1日1回）
sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh

インストール先は/opt/vuls-saas、ログは/var/log/vulsです。プロキシ配下ではVULS_PROXYを足します。自動スキャンの時刻はインストールした時刻の5分後に決まるため、数百台に一斉に入れるとスキャンと結果送信が同じ時刻に集中します。台数が多い場合は導入時刻をずらしてください。

FAST-ROOTのsudoers設定｜catとfindのroot実行許可範囲

スキャンモードはFAST-ROOTとFASTの2つで、FAST-ROOTは再起動が必要なプロセスや起動中のプロセスまで取得でき、FASTは一部の情報を取れません。既定はFAST-ROOTです。

インストーラ本体（vuls-installer.sh）を読むと、FAST-ROOTでは/etc/sudoers.d/vuls-saasを作り、専用ユーザーvuls-saasにパスワードなしで/bin/catや/usr/bin/find、lsofなどの実行を許可しています。catに引数の制限が無いため、このユーザーはroot権限で任意のファイルを読めます。導入後は次のコマンドで実際の許可範囲を確かめてください。

# 付与された sudo 権限と自動スキャンの設定を確認する
sudo cat /etc/sudoers.d/vuls-saas
sudo -l -U vuls-saas
cat /etc/cron.d/vuls-saas-scan

ISMSやPCI DSSの監査で特権の付与範囲を説明する必要がある環境では、この内容を事前に承認へ回します。説明できないならFASTモードを選び、プロセス情報が欠ける分は再起動計画を別の手段で管理します。

閉域網のサーバはペーストスキャン｜パッケージ一覧をAPIで登録する手順

スキャナを置けない、あるいはインターネットに出られないサーバは、スキャン方法の選び方にある通りペーストスキャンかSBOMインポートを使います。ペーストスキャンはパッケージ一覧を貼り付けるだけで、スキャナのプログラムは要りません。画面に貼る代わりにREST APIで登録すれば、定期的な更新もスクリプトにできます。

# 閉域網の Ubuntu サーバ上で一覧を取り出す
dpkg-query -W -f="\${binary:Package},\${db:Status-Abbrev},\${Version},\${source:Package},\${source:Version}\n" > pkgs.txt
uname -r > kernel.txt

# ファイルを持ち出し、インターネットに出られる端末から登録する
jq -n --arg text "$(cat pkgs.txt)" --arg kernel "$(cat kernel.txt)" \
  '{serverName:"closed-db01", osFamily:"ubuntu", osVersion:"22.04",
    kernelRelease:$kernel, pkgPasteText:$text}' > paste.json

curl -s -X POST 'https://rest.vuls.biz/v1/server/paste' \
  -H 'Content-Type: application/json' \
  -H 'accept: application/json' \
  -H "Authorization:${FVULS_API_TOKEN}" \
  -d @paste.json

dpkg-queryの書式にある\$は外せません。ダブルクォートの中でバックスラッシュを落とすと、シェルが${binary:Package}を変数として展開し、各項目が空文字になります。RHEL 8以降はrpm -qa --queryformatで名前・エポック・版・リリース・アーキテクチャ・ソースRPM・モジュラリティを出す書式が公式に載っています。構成が変わるたびに登録し直す必要がある点は、ペーストスキャン共通の弱点です。

GitHub ActionsでイメージをTrivy経由でFutureVulsへ送信する設定

コンテナイメージとアプリケーションのライブラリは、Trivyを同梱した軽量スキャナvuls-trivy-light.shでCIから送れます。root権限が要らないのが通常版との違いです。

公式サンプルの変数展開を直したワークフロー｜bad substitutionの回避

CI/CDパイプラインに組み込む手順にはGitHub ActionsとAWS CodeBuildの例があります。ただしGitHub Actionsの例はrunの中で${env.TARGET_IMAGE}と書いており、これはActionsの式（${{ env.TARGET_IMAGE }}）でもシェル変数（$TARGET_IMAGE）でもありません。Git Bash 5.3.15で同じ書き方を実行するとbad substitutionで止まりました。環境変数としてそのままスクリプトに渡せば、展開を書く必要自体がなくなります。

name: FutureVuls image scan
on:
  push:
    branches: [main]
jobs:
  image-scan:
    runs-on: ubuntu-latest
    env:
      TARGET_IMAGE: "myapp:${{ github.sha }}"
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build . -f docker/app/Dockerfile -t "$TARGET_IMAGE"
      - name: Scan and upload to FutureVuls
        env:
          VULS_SAAS_GROUPID: ${{ secrets.VULS_SAAS_GROUPID }}
          VULS_SAAS_TOKEN: ${{ secrets.VULS_SAAS_TOKEN }}
          VULS_SAAS_UUID: ${{ vars.FVULS_IMAGE_UUID }}
        run: curl -s https://installer.vuls.biz/vuls-trivy-light.sh | bash -s inst

公式例にあるvulndb/のキャッシュ手順は省きました。軽量スキャナは実行のたびにTrivyのDBとJava DBを取得し、最後に作業ディレクトリを削除する作りで、スクリプト内にvulndb/を参照する箇所がないためです。Trivy自体の使い方とオプションはTrivy（トリヴィ）の使い方｜インストールからCI設定までで扱っています。

VULS_SAAS_UUIDを固定する理由｜未指定だと実行ごとにサーバが増える

上の設定でUUIDをリポジトリ変数から渡しているのには理由があります。vuls-trivy-light.shの冒頭はVULS_SAAS_UUID=${VULS_SAAS_UUID:=$(uuidgen)}で、未指定の場合は、実行のたびに新しいUUIDを生成する仕組みです。FutureVulsはUUIDでサーバを識別するため、pushのたびに別のサーバとして登録が増え、タスクの履歴も途切れます。

イメージごとに1つのUUIDを決め、Actionsのvarsかシークレットに固定してください。同じスクリプトはTARGET_IMAGEとTARGET_LIBRARYを同時に指定するとエラーで終了するため、イメージとライブラリを両方送るならジョブかステップを分け、UUIDも別に用意します。

REST APIで未対応タスクを取得し社内の運用基盤へ流す実装の手順

画面とチャット通知だけで回らなくなったら、APIでタスクを取り出し、チケット管理や週次レポートへ流します。

rest.vuls.bizの認証とトークン3種｜グループからオーガニゼーションまで

FutureVuls APIの説明によれば、ベースURLはhttps://rest.vuls.bizで、AuthorizationヘッダにAPIトークンを入れます。トークンはグループ、グループセット、オーガニゼーションの3種類で、それぞれの設定画面で発行します。

トークンの範囲はそのまま読める範囲です。1つのシステムの担当チームにはグループトークン、複数システムを横断する集計にはグループセットトークン、と用途ごとに分けておくと、漏えい時の影響範囲を絞れます。Swaggerは公開されていますが、ブラウザ上からのAPI実行は動作しないと明記されています。

未対応タスクを優先度別に集計するPython｜毎分20回の制限への対応

レートリミットのページでは、トークンごとに毎分20回、IPアドレスごとに毎分200回が上限で、超えると429が返り、約1分で解除されます。次のスクリプトは標準ライブラリだけで、未着手・調査中・対応中のタスクを取得し、優先度ごとに件数を集計するためのものです。クエリの値とレスポンスの項目名は公式のAPIサンプルに合わせています。

import collections
import json
import os
import time
import urllib.error
import urllib.request

BASE = "https://rest.vuls.biz"
TOKEN = os.environ["FVULS_API_TOKEN"]
STATUSES = ["new", "investigating", "ongoing"]


def get(path):
    for _ in range(3):
        req = urllib.request.Request(
            BASE + path,
            headers={"accept": "application/json", "Authorization": TOKEN},
        )
        try:
            with urllib.request.urlopen(req, timeout=30) as res:
                return json.load(res)
        except urllib.error.HTTPError as e:
            if e.code == 429:
                time.sleep(5)
                continue
            raise
    raise RuntimeError("rate limit was not released")


query = "&".join(f"filterStatus={s}" for s in STATUSES)
data = get(f"/v1/tasks?limit=1000&{query}")
tasks = data["tasks"]
print("totalCount:", data["paging"]["totalCount"], "fetched:", len(tasks))

for priority, count in collections.Counter(t["priority"] or "none" for t in tasks).most_common():
    print(priority, count)

for t in tasks[:10]:
    print(t["cveID"], t["serverName"], t["status"], t["priority"])

totalCountと取得件数が食い違う場合は1,000件を超えているので、ページングを足します。filterNewedAtAfterで検知日時を絞れるため、週次レポートなら前回実行時刻以降の新規タスクだけを取れば、リクエスト数も制限内に収まります。

FutureVulsを採用する条件とTrivyやOSS版Vulsで足りる場面の判断基準

最後に判断を言い切ります。FutureVulsは検知の精度で選ぶ製品ではなく、対応管理の人手を減らすために選ぶ製品です。

採用する条件｜サーバ100台超とSSVCでの説明責任とEOL管理の一元化

次の条件が2つ以上当てはまるなら、FutureVulsを選ぶ理由があります。第一に、管理対象のサーバやイメージが100を超え、Excelやチケットで脆弱性対応を追うのが破綻している場合です。100ライセンスからという契約条件も、この規模なら制約になりません。

第二に、監査や経営層への報告で「なぜこの脆弱性を後回しにしたか」を説明する必要がある場合です。SSVCのDeferやScheduledという判定と根拠が記録に残るのは、CVSSの点数だけで優先度を決める運用にはない利点です。第三に、OS、ミドルウェア、ライブラリ、ネットワーク機器のEOLを一か所で追いたい場合で、2025年11月の強化はこの用途に向いています。継続的な脅威管理の枠組みとしてはCTEMとは？脆弱性管理との違いと導入判断もあわせて検討してください。

見送る場面｜コンテナ中心の少人数チームと検知だけ欲しい開発現場

反対に、管理対象が数十台以下で、開発チームが自分たちのイメージとライブラリだけを見ていれば足りるなら、FutureVulsは過剰です。CIでTrivyを動かして結果をプルリクエストに出すか、OSV-Scannerでlockファイルを検査すれば、年間契約なしで検知はできます。

OSS版Vulsを自前で運用する選択肢も、DBの更新サーバを保守できる担当者がいる場合に限られます。担当者が1人で、異動すると止まる体制なら、SaaSに払う費用のほうが安く付きます。どの方式でも、スキャナが拾えるのは既知の脆弱性だけで、自社が書いたWebアプリケーションの欠陥は対象外です。そこは脆弱性診断・セキュリティ診断のような手動を含む検査で補う必要があります。

よくある質問

FutureVulsの検討と導入でよく挙がる質問をまとめました。

FutureVulsの料金はいくらですか？

2026年10月6日時点の公式料金ページでは、CSIRTプランとPSIRTプランのどちらも「要見積」で、請求書払いの年間契約です。FAQでは両プランとも100ライセンスからの案内とされています。比較サイトに残る「1台あたり月4,000円」のStandardプランは現行の料金ページには載っていません。ライセンスの数え方も公開されていないため、サーバ、コンテナ、ライブラリの内訳を用意して見積りを依頼するのが確実です。

FutureVulsとOSS版Vulsの違いは何ですか？

検知エンジンはどちらもVulsで、差は検知した後の運用です。OSS版はGitHubでGPL-3.0として公開されている無償のスキャナで、検知結果をどう扱うかは利用者に任されます。FutureVulsはそこにSSVCによる優先度の自動判定、タスク管理、自動トリアージ、SBOM管理、EOL管理を加え、脆弱性データベースの更新もサービス側で受け持ちます。DBサーバの保守を自分で持たなくてよい点も大きな違いです。

FutureVulsに無料トライアルはありますか？

公式のFAQでは、無料トライアルは導入台数の規模や要件に応じて個別に案内するとされており、申込みは問い合わせページからです。現行の料金ページにも、トライアルや無料の表記はありません。小規模なPoCを希望する場合も相談扱いになります。試す前に、対象にする資産の種類と台数を整理しておくと話が早く進みます。

インターネットに出られないサーバもFutureVulsで管理できますか？

外部と通信できないサーバも管理の対象です。スキャナを置けない、または外部と通信できないサーバは、パッケージ一覧を貼り付けるペーストスキャンか、SBOMファイルのインポートで登録します。一覧の取得はUbuntuならdpkg-query、RHEL系ならrpm -qaの公式書式で行い、REST APIの/v1/server/pasteから登録すれば手順をスクリプトにできます。構成が変わるたびに登録し直す運用が必要です。

FutureVulsのSSVCでは何を設定する必要がありますか？

利用者が決めるのは、資産ごとのExposureとHuman Impactの2つです。Exposureはインターネットへの露出をSmall、Controlled、Openの3段階で、Human Impactは業務影響をLowからVery Highの4段階で設定します。悪用状況（Exploitation）と攻撃の自動化（Automatable）はCISAのKEVや攻撃コードの有無から自動で判定されます。この2つの設定を既定値のまま放置すると優先度の差が付かないため、資産の棚卸しを導入作業の最初に置いてください。