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

Semgrepは、コードの文字列ではなく構文・意味を捉えて問題を見つけるsemantic analysisのplatformだ。

Code、Supply Chain、Secretsを一つのAppSec運用へまとめ、AI生成コードも対象にする。

公式サイトは40以上の言語、年間75M以上のscan、3,000以上のcommunity rulesを掲げる。出典

冒頭

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の根拠・例外管理・監査ログを日本語の運用へ翻訳する導入支援が有効だと考える。出典