16 KiB
I’m sharing this because — given your interest in building a “deterministic, high‑integrity scanner” (as in your Stella Ops vision) — these recent vendor claims and real‑world tradeoffs illustrate why reachability, traceability and reproducibility are emerging as strategic differentiators.
🔎 What major vendors claim now (as of early Dec 2025)
- Snyk says its reachability analysis is now in General Availability (GA) for specific languages/integrations. It analyzes source code + dependencies to see whether vulnerable parts (functions, classes, modules, even deep in dependencies) are ever “called” (directly or transitively) by your app — flagging only “reachable” vulnerabilities as higher priority. (Snyk User Docs)
- Wiz — via its “Security Graph” — promotes an “agentless” reachability-based approach that spans network, identity, data and resource configuration layers. Their framing: instead of a laundry‑list of findings, you get a unified “can an attacker reach X vulnerable component (CVE, misconfiguration, overprivileged identity, exposed storage)?” assessment. (wiz.io)
- Prisma Cloud (from Palo Alto Networks) claims “Code‑to‑Cloud tracing”: their Vulnerability Explorer enables tracing vulnerabilities from runtime (cloud workload, container, instance) back to source — bridging build-time, dependency-time, and runtime contexts. (VendorTruth)
- Orca Security emphasizes “Dynamic Reachability Analysis”: agentless static‑and‑runtime analysis to show which vulnerable packages are actually executed in your cloud workloads, not just present in the dependency tree. Their approach aims to reduce “dead‑code noise” and highlight exploitable risks in real‑time. (Orca Security)
- Even cloud‑infra ecosystems such as Amazon Web Services (AWS) recommend using reachability analysis to reduce alert fatigue: by distinguishing packages/libraries merely present from those actually used at runtime, you avoid spending resources on low-risk findings. (Amazon Web Services, Inc.)
Bottom line: leading vendors are converging on reachability + context + traceability as the new baseline — shifting from “what is in my dependencies” to “what is actually used, reachable, exploitable”.
⚠️ What these claims don’t solve — and why you still have room to build a moat
- Static reachability ≠ guarantee of exploitability. As some docs admit, static reachability “shows there is a path” — but “no path found” doesn’t prove absence of risk (false negatives remain possible) because static analysis can't guarantee runtime behavior. (Snyk User Docs)
- Dynamic reachability helps — but has environment/cost trade‑offs. Runtime‑based detection (like Orca’s) gives stronger confidence but depends on actually executing the vulnerable code paths — which might not happen in tests or staging, and may require overhead. (Orca Security)
- Cloud systems are especially complex: environments constantly change (new services, network paths, IAM roles, data flows), so reachability today doesn’t guarantee reachability tomorrow — requiring re‑analysis, continuous monitoring, and integration across code, infra, identity, data and runtime.
Therefore, what these vendors offer is much improved over naive SCA, but none claim full deterministic, replayable, build‑to‑runtime‑to‑audit traceability under air‑gap or high‑compliance conditions.
That is exactly where your conceptual benchmarks (time‑to‑evidence from SBOM → signed call‑graph; false‑positive control under dependency churn; deterministic priority replays under air‑gap) have strategic value.
🎯 Why your “moat benchmarks” are still compelling — and what they map to in real‑world gaps
| Your Benchmark Concept | What Vendors Do — Where They Fall Short | Why It Matters (and Where You Could Lead) |
|---|---|---|
| (a) Time‑to‑evidence: SBOM → signed call‑graph | Tools like Snyk, Wiz, Orca produce reachability info — but rely on proprietary engines, often need source access or runtime telemetry, not tied to SBOM provenance or build‑time manifests. | You could offer a deterministic approach: from SBOM + build manifest generate a signed, auditable call‑graph — ideal for compliance, supply‑chain attestation, and reproducible audits. |
| (b) SBOM‑diff false positive rate under dependency churn | Vendors update engines and vulnerability databases frequently; reachability results change accordingly (e.g. Snyk’s recent JS/TS improvements), implying non‑deterministic drift under innocuous dependency updates. (updates.snyk.io) | You could aim for stability: using signed call‑graphs, track which vulnerabilities remain reachable across dependency churn — minimizing churn‑induced noise and building trust over time. |
| (c) Deterministic priority scoring under air‑gap replay | Risk or priority scores (e.g. Snyk Risk Score) include dynamic factors (time since disclosure, EPSS, exploit data) — so score changes with external context, not purely code/graph based. (Snyk User Docs) | Your project could provide deterministic, reproducible risk ratings — independent of external feeds — ideal for regulated environments or locked-down deployments. |
🧭 How this shapes your Stella‑Ops architecture vision
Given the limitations above, what top‑tier vendors deliver today is strong but still “heuristic + context‑aware” rather than “provable + reproducible”.
That strengthens the rationale for building your crypto‑sovereign, deterministic, SBOM‑to‑artifact‑to‑runtime‑to‑audit pipeline (with lattice/trust‑graph, reproducible call‑graphs, signed manifests, replayable scans, proof ledger).
If you succeed, you would not just match current vendors — you’d exceed them in auditability, compliance‑readiness, post‑quantum future‑proofing, and supply‑chain integrity.
If you like — I can draft a matrix comparing 5‑10 leading vendors (Snyk, Wiz, Orca, Prisma Cloud, etc.) vs your target moat metrics — that could help you benchmark clearly (or show to investors). Let me know if you want that matrix now.
Stella Ops’ big advantage isn’t “better findings.” It’s better truth: security results you can reproduce, verify, and audit like a build artifact—rather than “a SaaS said so today.”
Here’s how to develop that into a crisp, defensible set of advantages (and a product shape that makes them real).
1) Deterministic security = trust you can ship
Claim: Same inputs → same outputs, always.
Why that matters: Most scanners are partly nondeterministic (changing vuln feeds, changing heuristics, changing graph rules). That creates “security drift,” which kills trust and slows remediation because teams can’t tell whether risk changed or tooling changed.
Stella Ops advantage:
- Pin everything that affects results: vuln DB snapshot, rule versions, analyzer versions, build toolchain metadata.
- Outputs include a replay recipe (“if you re-run with these exact inputs, you’ll get the same answer”).
- This makes security posture a versioned artifact, not a vibe.
Moat hook: “Reproducible security builds” becomes as normal as reproducible software builds.
2) Evidence-first findings (not alerts-first)
Claim: Every finding comes with a proof bundle.
Most tools do: CVE exists in dependency tree → alert.
Reachability tools do: CVE reachable? → alert.
Stella Ops can do: CVE reachable + here’s the exact path + here’s why the analysis is sound + here’s the provenance of inputs → evidence.
What “proof” looks like:
- Exact dependency coordinates + SBOM excerpt (what is present)
- Call chain / data-flow chain / entrypoint mapping (what is used)
- Build context: lockfile hashes, compiler flags, platform targets (why this binary includes it)
- Constraints: “reachable only if feature flag X is on” (conditional reachability)
- Optional runtime corroboration (telemetry or test execution), but not required
Practical benefit: You eliminate “AppSec debates.” Dev teams stop arguing and start fixing because the reasoning is legible and portable.
3) Signed call-graphs and signed SBOMs = tamper-evident integrity
Claim: You can cryptographically attest to what was analyzed and what was concluded.
This is the step vendors usually skip because it’s hard and unglamorous—but it’s where regulated orgs and serious supply-chain buyers pay.
Stella Ops advantage:
- Produce signed SBOMs, signed call-graphs, and signed scan attestations.
- Store them in a tamper-evident log (doesn’t need to be blockchain hype—just append-only + verifiable).
- When something goes wrong, you can answer: “Was this artifact scanned? Under what rules? Before the deploy? By whom?”
Moat hook: You become the “security notary” for builds and deployments.
4) Diff-native security: less noise, faster action
Claim: Stella Ops speaks “diff” as a first-class concept.
A lot of security pain comes from not knowing what changed.
Stella Ops advantage:
-
Treat every scan as a delta from the last known-good state.
-
Findings are grouped into:
- New risk introduced (code or dependency change)
- Risk removed
- Same risk, new intel (CVE severity changed, exploit published)
- Tooling change (rule update caused reclassification) — explicitly labeled
Result: Teams stop chasing churn. You reduce alert fatigue without hiding risk.
5) Air-gap and sovereign-mode as a design center, not an afterthought
Claim: “Offline replay” is a feature, not a limitation.
Most cloud security tooling assumes internet connectivity, cloud control-plane access, and continuous updates. Some customers can’t do that.
Stella Ops advantage:
- Run fully offline: pinned feeds, mirrored registries, packaged analyzers.
- Export/import “scan capsules” that include all artifacts needed for verification.
- Deterministic scoring works even without live exploit intel.
Moat hook: This unlocks defense, healthcare, critical infrastructure, and M&A diligence use cases that SaaS-first vendors struggle with.
6) Priority scoring that is stable and configurable
Claim: You can separate “risk facts” from “risk policy.”
Most tools blend:
- facts (is it reachable? what’s the CVSS? is there an exploit?)
- policy (what your org considers urgent)
- and sometimes vendor-secret sauce
Stella Ops advantage:
-
Output two layers:
- Deterministic fact layer (reachable path, attack surface, blast radius)
- Policy layer (your org’s thresholds, compensating controls, deadlines)
-
Scoring becomes replayable and explainable.
Result: You can say “this is why we deferred this CVE” with credible, auditable logic.
7) “Code-to-cloud” without hand-waving (but with boundaries)
Claim: Stella Ops can unify code reachability with deployment reachability.
Here’s where Wiz/Orca/Prisma play, but often with opaque graph logic. Stella Ops can be the version that’s provable.
Stella Ops advantage:
-
Join three graphs:
- Call graph (code execution)
- Artifact graph (what shipped where; image → workload → service)
- Exposure graph (network paths, identity permissions, data access)
-
The key is not claiming omniscience—it’s declaring assumptions:
- “Reachable from the internet” vs “reachable from VPC” vs “reachable only with role X”
Moat hook: The ability to prove your assumptions beats a “security graph” that’s impossible to audit.
8) Extreme developer ergonomics: fix speed as the KPI
If you want adoption, don’t compete on “most findings.” Compete on time-to-fix.
Stella Ops advantage:
-
Every finding includes:
- exact dependency edge causing inclusion
- minimal remediation set (upgrade, replace, feature flag off)
- impact analysis (“what breaks if you upgrade?” via API surface diff where possible)
-
Output is CI-friendly: PR comments, merge gates, and a local CLI that matches CI outputs 1:1.
Result: Devs trust it because it’s consistent between laptop and pipeline.
9) A wedge that vendors can’t easily copy: “Security proofs” as a portable artifact
This is the strategic framing:
- Snyk/Wiz/Orca can add more reachability heuristics.
- It’s much harder for them to retrofit reproducible, cryptographically verifiable, offline-replayable evidence chains across their whole stack without breaking their SaaS economics.
Stella Ops advantage: You’re not just a scanner. You’re a verification layer that:
- can sit above existing tools
- can validate their outputs
- can produce the audit-grade record customers actually need
That’s a platform position.
What to build first (to make the advantages real fast)
If you want a sharp first release that screams “Stella Ops”:
- Signed SBOM + signed call-graph for 1–2 languages you can do extremely well
- Reachability certificate per vulnerability (path + provenance + replay recipe)
- Diff-native scan output (new/removed/tooling-changed buckets)
- Offline replay bundle (“scan capsule”) export/import
- Policy layer: deterministic facts + org-defined thresholds
That combination gives you a story competitors can’t easily match: auditable security with low noise.
If you want, I can also turn this into:
- a one-page positioning doc (CISO + AppSec versions), or
- a “moat metrics” scorecard you can use to benchmark vendors and your MVP.