Anchore、SBOMを「作る」からsoftware supply chainを統制する基盤へ

Anchoreは、ソフトウェアを作る速度が上がるほど、その中身を説明し守る仕組みが必要になるという問題から始まった。

Saïd ZiouaniとDaniel Nurmiは、公式Aboutページで2016年にAnchoreを始めた創業者として紹介されている。出典

創業、containerを読むところから

初期のAnchoreは、container imageの中身を分析し、脆弱性やpolicy違反を開発workflowの早い段階で見つける方向へ進んだ。

単に危険を知らせるのではなく、何が含まれているかをSBOMとして可視化する発想が、後のplatformの土台になった。出典

転機、OSSからworkflowへ

2019年にはGitHub Actions向けのContainer Scanを打ち出し、securityを別画面の作業からCI/CDの流れへ移そうとした。

ここでの転機は、scanner単体の性能競争ではなく、開発者が普段使う場所に検査を置くことだった。出典

Saïd Ziouaniは公式ページでCEO and Founderと紹介されている。

この肩書きが示すのは、Anchoreが研究用のscannerだけでなく、企業が継続運用するsoftware security platformを目指してきたことだ。出典

成長、SBOMを管理対象にする

2020年1月、AnchoreはSignalFire主導のSeries Aで2,000万ドルを調達した。

資金調達の発表では、container workflow・analysis・securityを事業の中心として説明している。出典

その後、SBOMを生成するOSSと、enterpriseでinventory・vulnerability・complianceを管理するplatformを組み合わせた。

2025年のAnchore SBOM発表は、SBOMを一度作って終わる成果物ではなく、software supply chainを継続監視する中心へ置く転換だった。出典

今、速度を落とさず説明責任を持つ

Anchoreの道のりは、container scannerから、開発・security・規制対応を結ぶsoftware supply chain managementへ広がる道のりだった。

OSSで現場の入口を作り、Enterpriseで組織の証跡を扱う。

その二層構造こそが、complianceを開発速度の敵にしないための現在の答えと言える。

Anchoreは、container・dependency・source repositoryの安全性を継続的に確認したいsecurity teamとDevOps teamに刺さる。

SBOMを作るだけでなく、vulnerability detectionとpolicy enforcementを一つのworkflowへつなぐため、規制対応と開発速度の両立が課題になる企業に適する。出典

OSSのSyftとGrypeを入口にできるため、最初から大規模な購買判断を迫らず、導入後にEnterpriseへ拡張できる。

これは「安全性を後付けせず、開発工程へ組み込む」需要との整合が強いと考えられる。出典

技術的なmoatは、OSSのSyft・GrypeとEnterprise platformの組み合わせ、およびSBOMをsoftware lifecycleで追跡する運用知識にある。

単発のscannerより、既存の開発・security workflowへ蓄積されるpolicyとinventoryが乗り換えコストを生む。出典

ネットワーク効果は強くない。

利用企業が増えても、プロダクト価値は主に各社のsoftware inventoryとpolicyに依存するためだ。

一方でOSS communityからの改善やintegrationsは、間接的なecosystem効果を持つ。出典

主な対象は、containerやopen source dependencyを含むソフトウェアを開発・運用する中堅〜大企業のDevSecOps team、security team、platform engineering teamだ。

特に政府調達や規制産業で、SBOMと脆弱性対応の証跡を求められる組織に向く。出典

逆に、単一repositoryだけを軽くscanしたい個人にはEnterpriseの運用範囲が過剰になりやすい。

第一は、SBOM生成・脆弱性スキャン・policy enforcementを別々の点ではなく、software supply chain全体の流れとして束ねたことだ。出典

第二は、OSS toolsを公開し、開発者が既存のCI/CDから試せる入口を作ったこと。

第三は、政府・enterpriseのcompliance要件へ具体的に対応したことだ。出典

Anchoreはenterprise salesとcontact pricingを含むため、個人開発者や小規模チームには導入判断の重さが残る。

公開されたpricingページでもEnterpriseは問い合わせが前提で、セルフサーブの費用比較はしにくい。出典

また、SBOM・脆弱性・policyの運用は組織の開発processとセットであり、toolを置くだけではcomplianceにならない。

規制や脆弱性データの変化に継続対応する必要もある。

OSS toolsでdeveloperとsecurity engineerの検証コストを下げ、企業のSBOM・compliance課題をEnterpriseへ接続する二層構造が中心だ。

GitHub ActionsやKubernetesなど既存workflowとのintegrationは、単独のsecurity consoleを売るより導入理由を作りやすい。出典

規制対応は強い需要喚起になる反面、政府・大企業向けに寄りすぎると購買cycleが長くなる。

OSSの利用体験とenterpriseの証跡をどこまで滑らかにつなげられるかが成長の分岐点になる。

主要チャネル: content, openSource, partnerships, enterpriseSales, community

security productは脆弱性の検出精度だけでなく、誰がいつ何を直したかをworkflowへ残せるかで評価される。

Anchoreの例は、OSSの小さなCLIとenterpriseの管理基盤を分断せず、導入前後の体験をつなぐ設計を示している。出典

日本企業が参考にするなら、規制対応を機能一覧で終わらせず、SBOM生成から例外承認・再検査までの証跡に落とすことが重要だ。

日本では、取引先や政府調達でsoftware supply chainの説明責任が増えるほど、SBOMを「作って提出するファイル」から「更新される運用台帳」へ変える余地がある。

AnchoreのようにOSSのscannerとpolicy・complianceをつなぐ発想は、国内のplatform team向けにも応用できる。出典

ただし、規制文書を翻訳するだけでは定着しない。

日本の開発組織の承認フローや取引先監査に合わせた導入支援が必要だ。