Semgrepは「脆弱性を探す」から、AIコードの安全な出荷をどう支えたか

冒頭

Semgrepは、コードの意味を読むOSS projectから、複数のAppSec領域を束ねるplatformへ進んだ。

創業

Isaac EvansはDrew Dennison、Luke O’Malleyと2017年にSemgrepを創業した。

「Our mission is to make it expensive to exploit software.」という言葉は、検出機能より広い使命を示す。出典

転機・苦労

2020年にsgrepの開発を再加速し、OSSの配布物をSemgrepへ発展させた。

開発者の速度とsecurityの厳密さを同時に扱うことが転機だった。出典

成長・成功

CodeからSupply Chain、Secrets、AI-generated codeへ広げ、2025年にはSeries Dで1億ドルを調達した。出典

結び

Semgrepの現在地は、scannerの高機能化ではなく、securityを出荷工程へ近づける再構成として読むべきだ。

Semgrepは、開発速度を落とさずAppSecを実装したいengineering teamに刺さる。

OSS CLIとcustom rulesで既存repositoryへ入り、CI/CDの検査をsecurity teamだけでなく開発者の日常にする。

40以上の言語と複数製品への拡張は、単一scannerより運用単位を広げる根拠になる。出典

一方、検出精度とfalse positiveの扱いは継続課題だ。

つまりPMFの核は「脆弱性を見つける」だけでなく、修正判断までの摩擦を減らすことにある。

semantic rulesとcommunity rulesの蓄積、OSS利用者との接点、企業のCI/CD・policy運用に入り込むswitching costがmoatになる。

ただしrulesは競合も追随し得る。出典

network effectは中程度。

利用者とcommunityが増えるほどrulesと事例は増えるが、SNSのような直接的ネットワークではなく、検出知識の蓄積型だ。出典

複数言語のrepositoryとCI/CDを持ち、開発速度とAppSecを両立したいengineering・security team向け。

個人の単発scanだけを求める利用者には過剰になり得る。出典

OSS CLIとcommunity rulesを入口にしたdeveloper-first distribution、semantic analysisによる差別化、CodeからSupply Chain・Secretsへ広げるproduct bundlingが再現可能な要因だ。出典

公開情報だけではARRや顧客維持率は確認できない。

false positive、rule maintenance、複数security製品の運用複雑性、AI生成コードの急増への対応はリスクとして残る。出典

無料OSSとrulesで開発者を獲得し、CI/CD、Cloud管理、triage、企業向けpolicyへ拡張するPLGが中心だ。

Security領域の大企業販売を重ねるほど単価は上がるが、導入後の運用負荷を下げ続ける必要がある。出典

主要チャネル: developer-community, open-source, content-marketing, enterprise-sales, product-led-growth

developer toolは、専門部署向けの高機能dashboardより、開発者の既存workflowに自然に入る入口が強い。

OSSで試せるsurfaceと、企業が買う管理・policyの境界を設計することが重要だ。出典

日本では金融・製造などsoftware supply chainの説明責任が重い業界へ、ruleの根拠・例外管理・監査ログを日本語の運用へ翻訳する導入支援が有効だと考える。出典