git.stella-ops.org/docs/benchmarks/scanner/scanning-gaps-stella-misses-from-competitors.md

Scanning Gaps — Competitor Techniques Missing in StellaOps

.NET lockfile ingestion (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Enterprise tenants request pre-build dependency evidence for audits.
Competitive risk	4	Trivy and Snyk already parse NuGet lockfiles.
Engineering effort	3	Collector plus CLI toggle is moderate effort.
Policy/config impact	4	Policies must handle declared-only components.
Offline/air-gap impact	3	Offline-friendly; bundle size increases slightly.

• Competitor capability: Trivy parses packages.lock.json / packages.config and Snyk uploads manifest graphs, enabling pre-build dependency visibility.
• StellaOps gap: Scanner currently inspects installed artifacts only (deps/runtimeconfig/assemblies); lockfiles are ignored.
• Proposed plan:
  1. Add optional lockfile collectors under StellaOps.Scanner.Analyzers.Lang.DotNet that parse NuGet lockfiles without requiring restore, emitting auxiliary component records linked to installation evidence when present.
  2. Extend Surface.Validation to gate lockfile parsing (size, tenant policy) and Surface.Secrets for private feed credentials when resolving lockfile registries.
  3. Feed parsed lockfile metadata into Policy Engine via a new evidence flag so policy can distinguish “declared but not installed” dependencies.
  4. Provide CLI toggle (--dotnet-lockfiles) and document policy defaults (fail if declarations lack runtime evidence unless waiver).
• Policy considerations: Introduce policy template allowing tenants to require lockfile parity or suppress pre-build-only components; leverage existing lattice logic to down-rank vulnerabilities lacking runtime evidence.
• Next actions: open analyzer story (SCANNER-ANALYZERS-LANG-DOTNET) and doc task for policy guidance once design is finalized.

Implementation details

• Collectors live under StellaOps.Scanner.Analyzers.Lang.DotNet:
  • DotNetDependencyCollector (existing) resolves installed assemblies via *.deps.json, *.runtimeconfig.json, and manifest metadata.
  • New DotNetLockfileCollector (plan) will parse packages.lock.json / packages.config without executing restore, emitting records flagged DeclaredOnly.
• Surface integrations:
  • Surface.Validation controls lockfile parsing size, repository allowlists, and opt-in behaviour.
  • Surface.Secrets provides credentials for private NuGet feeds referenced in lockfiles.
• Merging pipeline:
  • DotNetPackageAggregator will merge installed and declared records by package key (id + version) with precedence rules (installed evidence supersedes declared-only).
  • Policy Engine receives both authoritative and declared-only evidence, enabling parity checks and waivers.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Installed runtime evidence	*.deps.json, *.runtimeconfig.json, assemblies, authenticode metadata	DotNetDependencyCollector, DotNetPackageAggregator, optional IDotNetAuthenticodeInspector	Produces authoritative components (inventory + usage) keyed by assembly path and package id.
Lockfile ingestion (planned)	packages.lock.json, packages.config, restore graph metadata	DotNetLockfileCollector (new), integrated into DotNetPackageAggregator	Emits DeclaredOnly components; merged with installed evidence by package id/version; unresolved entries flagged for policy.
Runtime usage linkage	EntryTrace outputs	EntryTrace integration via LanguageAnalyzerContext.UsageHints	Marks components used by entrypoint closure; policy and explain traces highlight runtime relevance.

Node.js pnpm lock validation (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	Monorepo customers asking for pnpm parity; moderate demand.
Competitive risk	4	Competitors advertise pnpm support, creating parity pressure.
Engineering effort	3	Collector and CLI work similar to .NET lockfile effort.
Policy/config impact	4	Requires policy predicates and explain updates.
Offline/air-gap impact	3	Offline-compatible with additional parser rules bundled.

• Competitor capability: Trivy and Snyk parse pnpm/yarn/npm lockfiles even when node_modules is absent, surfacing dependency graphs pre-install for policy gating.
• StellaOps gap: Scanner requires installed artifacts; there is no CLI helper to validate pnpm lockfiles or compare declared vs installed packages ahead of a scan.
• Proposed plan:
  1. Introduce a lockfile-only collector under StellaOps.Scanner.Analyzers.Lang.Node that decodes pnpm-lock.yaml, package-lock.json, and yarn.lock, emitting provisional component records with provenance flag DeclaredOnly.
  2. Expose a CLI verb (stella node lock-validate) that runs the collector without enqueuing a full scan, honouring Surface.Validation controls (max lockfile size, allowed registries) and Surface.Secrets for private registries.
  3. Persist lockfile-derived dependencies alongside installed evidence so Policy Engine can enforce parity via new predicates (e.g., node.lock.declaredMissing, node.lock.registryDisallowed).
  4. Extend EntryTrace explain output (and policy explain traces) to highlight packages present in runtime closure but missing from lockfiles—or declared-only artifacts not shipped in the image.
• Policy considerations: Provide sample policies that fail builds when lockfiles reference disallowed registries or when declared packages lack runtime evidence; use lattice weighting to downgrade issues limited to declared-only components.
• Next actions: open analyzer story (SCANNER-ANALYZERS-LANG-NODE) plus CLI story for lock validation, and schedule Docs Guild update covering the new policy predicates.

Implementation details

• Collectors under StellaOps.Scanner.Analyzers.Lang.Node:
  • Existing NodePackageCollector walks package.json evidence across workspaces.
  • Planned NodeLockfileCollector will parse pnpm-lock.yaml, package-lock.json, yarn.lock.
• Surface integrations:
  • Surface.Validation to constrain lockfile size, allowed registries, and CLI access for stella node lock-validate.
  • Surface.Secrets for private registry credentials when validating lockfiles.
• Merge strategy:
  • LanguageAnalyzerContext merges installed and declared components; declared-only entries are flagged (DeclaredOnly) and kept for policy comparison.
  • EntryTrace usage hints link runtime scripts to packages, influencing policy weights and explain traces.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Installed package evidence	package.json + node_modules tree	NodePackageCollector	Produces authoritative components with install paths and workspace metadata.
Lockfile ingestion (planned)	pnpm-lock.yaml, package-lock.json, yarn.lock	NodeLockfileCollector (new)	Emits declared dependency graph with provenance; merged by package name/version; discrepancies flagged for policy.
Runtime usage linkage	EntryTrace launcher catalog (npm/yarn scripts, node entrypoints)	EntryTrace + LanguageAnalyzerContext.UsageHints	Annotates components used at runtime; unresolved launchers produce explain-trace diagnostics.

Python lockfile & editable install coverage (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	Editable install coverage requested by regulated Python users.
Competitive risk	3	Trivy supports multiple lock formats; Snyk SaaS highlights poetry support.
Engineering effort	3	Collector and editable path resolution are moderate effort.
Policy/config impact	4	Policy needs knobs for declared-only vs runtime packages.
Offline/air-gap impact	3	Offline workable while packaging parser tooling.

• Competitor capability: Trivy parses Poetry/Pipenv/pip lockfiles (including editable installs) and Snyk uploads manifest graphs, exposing declared dependencies even when virtualenvs are absent.
• StellaOps gap: Scanner relies on installed dist-info metadata; editable installs or source-only lockfiles are skipped, and there is no automated parity check between declared requirements and runtime usage.
• Proposed plan:
  1. Add a lockfile collector in StellaOps.Scanner.Analyzers.Lang.Python that reads poetry.lock, Pipfile.lock, requirements.txt (including VCS URLs), tagging results as DeclaredOnly.
  2. Detect editable installs by parsing pyproject.toml / setup.cfg, resolving editable paths with Surface.FS, and linking to EntryTrace usage to ensure runtime awareness.
  3. Provide CLI support (stella python lock-validate) to diff declared vs installed artifacts, enforcing Surface.Validation constraints (lockfile size, allowed indexes) and Surface.Secrets for private PyPI mirrors.
  4. Persist declarative evidence separately so Policy Engine can evaluate predicates like python.lock.declaredMissing and python.lock.indexDisallowed.
  5. Extend explain traces to highlight editable or declared-only packages lacking runtime deployment, aiding remediation.
• Policy considerations: Ship policy templates distinguishing declared-only vs runtime packages, with lattice-based weighting to reduce noise when usage is absent; allow tenants to enforce registry allowlists.
• Next actions: create analyzer and CLI backlog items in the Python guild, plus Docs Guild task to cover new policy knobs once design is complete.

Implementation details

• Collectors under StellaOps.Scanner.Analyzers.Lang.Python:
  • Existing analyzer reads installed *.dist-info metadata via PythonDistributionLoader.
  • Planned lockfile collector parses poetry.lock, Pipfile.lock, requirements.txt (including VCS refs).
• Editable installs:
  • Detect via pyproject.toml / setup.cfg markers; use Surface.FS to resolve local paths and mark components as editable.
• Surface & policy integrations:
  • Surface.Validation constrains lockfile size and allowed indexes; Surface.Secrets handles private index credentials.
  • Policy Engine receives new flags (DeclaredOnly, EditablePath) to drive parity checks.
• CLI workflow: stella python lock-validate (planned) will reuse collectors without scheduling full scans.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Installed distributions	*.dist-info directories, RECORD, METADATA	PythonLanguageAnalyzer	Produces authoritative components with file hashes and EntryTrace usage hints.
Lockfile ingestion (planned)	poetry.lock, Pipfile.lock, requirements.txt	Planned lockfile collector integrated with analyzer	Emits declared dependency graph, tagged DeclaredOnly; merged by package name/version.
Editable install resolution	Local source directories referenced in lockfiles (path =, editable = true)	New editable resolver leveraging Surface.FS	Links editable packages to actual source paths; policy distinguishes editable vs packaged artefacts.

Java build-tool lockfile ingestion (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	Platform teams running Gradle/SBT builds request parity for pre-build evidence.
Competitive risk	4	Trivy supports Gradle/SBT lockfiles and Snyk ships Maven/Gradle/SBT plugins.
Engineering effort	3	Requires new lockfile collectors plus CLI wiring; moderate complexity.
Policy/config impact	3	Policy must handle declared-only Java components and disallowed repositories.
Offline/air-gap impact	3	Works offline but needs packaged parsers and repository allowlists.

• Competitor capability: Trivy parses Gradle/Maven/SBT lockfiles and Snyk relies on dedicated plugins to surface declared dependencies even before artifacts are built.
• StellaOps gap: Scanner inspects installed archives only; it ignores Gradle/SBT lockfiles and lacks a workflow to compare declared dependencies against runtime archives.
• Proposed plan:
  1. Introduce lockfile collectors under StellaOps.Scanner.Analyzers.Lang.Java to parse gradle.lockfile, pom.xml/pom.lock, and build.sbt output, emitting DeclaredOnly components with repository metadata.
  2. Extend Surface.Validation for Java lockfiles (size limits, allowed repositories) and leverage Surface.Secrets for private Maven repository credentials.
  3. Provide a CLI verb (stella java lock-validate) to diff declared vs installed archives without running a full scan, emitting policy-ready diagnostics.
  4. Persist declarative evidence so Policy Engine can evaluate predicates (java.lock.declaredMissing, java.lock.repoDisallowed) and feed explain traces highlighting gaps.
• Policy considerations: Supply templates enforcing repository allowlists and declared-vs-runtime parity, using lattice weights to downgrade issues that never reach runtime.
• Next actions: log analyzer/CLI backlog stories with the Java guild and plan Docs Guild updates for new policy knobs once design stabilises.

Implementation details

• Collectors under StellaOps.Scanner.Analyzers.Lang.Java:
  • Existing analyzer normalises installed JAR/WAR/EAR archives and extracts MANIFEST.MF, pom.properties.
  • Planned lockfile collectors will ingest gradle.lockfile, Maven pom.xml/pom.lock, and build.sbt outputs.
• Surface integrations:
  • Surface.Validation enforces lockfile size and repository allowlists; Surface.Secrets supplies credentials for private Maven repositories.
• Merge strategy:
  • New collector emits DeclaredOnly components with repository metadata; JavaLanguageAnalyzer merges them with observed archives keyed by groupId:artifactId:version.
  • EntryTrace usage hints link runtime launchers to archives, enabling policy to prioritise used components.
• CLI tooling:
  • stella java lock-validate (planned) exposes lockfile parity checks without full scan scheduling, reusing collectors.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Installed archives	JAR/WAR/EAR/PAR files, MANIFEST.MF, pom.properties	JavaLanguageAnalyzer	Produces authoritative components with archive hashes and runtime usage hints.
Lockfile ingestion (planned)	gradle.lockfile, Maven pom.xml/pom.lock, SBT build metadata	Planned lockfile collectors integrated with analyzer	Emits declared dependency entries (repository + checksum); merged on GAV coordinates with priority to installed evidence.
Runtime linkage	EntryTrace wrapper catalogue (java -jar, jetty, etc.)	EntryTrace integration	Marks archives invoked at runtime; unresolved launchers surfaced with remediation hints.

Go stripped binary enrichment (Trivy, Grype)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	Teams shipping minimal Go binaries want richer provenance for runtime attestations.
Competitive risk	3	Trivy/Grype skip hashed fallbacks, but customers compare hashed provenance across tools.
Engineering effort	2	Extend fallback hashing with symbol inference; low-medium effort.
Policy/config impact	3	Policy needs knobs to treat inferred modules differently from authoritative results.
Offline/air-gap impact	3	Offline-friendly; requires bundling symbol parser logic.

• Competitor capability: Trivy and Grype skip binaries without Go build info, leaving stripped binaries without component coverage.
• StellaOps gap: StellaOps emits hashed fallback components but lacks inferred module names, confidence scoring, and policy integration.
• Proposed plan:
  1. Enhance GoBinaryScanner fallback path to parse symbol tables (DWARF/ELF) and infer module/package names, tagging results with confidence metrics.
  2. Persist inferred metadata separately so Policy Engine can weight go.inferred components differently from authoritative modules.
  3. Expose CLI detail (--go-fallback-detail) and explain trace entries highlighting hashed/inferred provenance for stripped binaries.
  4. Update attestation manifests to surface inferred modules, enabling policy-controlled downgrade rather than omission.
• Policy considerations: Extend policy predicates to differentiate authoritative vs inferred Go modules; adjust lattice weights to reduce noise while keeping visibility.
• Next actions: create analyzer backlog story for enhanced fallback parsing and Docs Guild task to document policy/CLI behaviour.

Implementation details

• Analyzer: StellaOps.Scanner.Analyzers.Lang.Go/GoLanguageAnalyzer currently extracts Go build info (module, buildSettings) and DWARF metadata when available.
• Fallback enhancements (planned):
  • Extend GoBinaryScanner to parse ELF/Mach-O symbol tables when build info is missing.
  • Maintain fingerprint catalogue under StellaOps.Scanner.Analyzers.Lang.Go.Fingerprints with signed updates for Offline Kit.
• Surface & policy:
  • Surface.Validation governs fallback enablement; configuration stored alongside analyzer options.
  • Policy Engine will recognise inferred components via new flags (e.g., go.inferred), influencing lattice weights.
• CLI and explain:
  • Introduce --go-fallback-detail to surface hashed vs inferred provenance.
  • Explain traces include confidence scores and recommended remediation (e.g., rebuild with -buildvcs).

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Authoritative build info	Go binary buildinfo section, DWARF metadata	GoLanguageAnalyzer	Produces authoritative modules with version/build metadata.
Fallback hashing	Binary bytes when build info missing	Existing fallback path in GoBinaryScanner	Emits hashed component (sha256:...) with Fallback flag for policy downgrading.
Symbol-based inference (planned)	ELF/Mach-O symbols, DWARF line info	Planned enhancement to GoBinaryScanner with fingerprint catalogue	Maps symbols to modules/packages, tagging confidence scores; merged with hashed fallback for explainability.

Rust fingerprint coverage (Trivy, Grype)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	Regulated teams running Rust microservices want deterministic evidence even for stripped binaries.
Competitive risk	3	Competitors drop stripped binaries entirely; StellaOps can differentiate by improving heuristics.
Engineering effort	3	Requires enhancing fingerprint catalogue and symbol inference; moderate effort.
Policy/config impact	3	Policy needs knobs to treat heuristic vs authoritative crates differently.
Offline/air-gap impact	3	Offline-compatible; must distribute updated fingerprint datasets with Offline Kit.

• Competitor capability: Trivy and Grype skip Rust binaries lacking Cargo metadata, offering no fallback or runtime insight.
• StellaOps gap: Although StellaOps stores hashed fallback and fingerprint components, coverage for niche toolchains and stripped binaries remains limited, reducing explainability.
• Proposed plan:
  1. Expand the fingerprint catalogue (RustAnalyzerCollector) with additional signature sources (e.g., crate fingerprint DB, community-sourced hash lists) and version inference heuristics.
  2. Parse symbol tables for stripped binaries (DWARF, --build-id) to infer crate names and link them to fingerprints, tagging results with confidence scores.
  3. Surface inferred vs authoritative crates distinctly in explain traces and CLI output (--rust-fingerprint-detail) so operators know when evidence is heuristic.
  4. Publish policy predicates (rust.fingerprint.confidence) allowing tenants to warn/fail when only heuristic evidence exists.
• Policy considerations: Extend lattice weights to downgrade heuristic-only findings while still surfacing them; provide policy templates for regulated environments.
• Next actions: open analyzer backlog story for fingerprint enrichment, schedule Docs Guild update for policy guidance, and coordinate Offline Kit team to package updated fingerprint datasets.

OS packages — Windows/macOS coverage (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	2	Requests are emerging but not yet widespread; gathering signals via windows-macos-demand.md.
Competitive risk	3	Competitors currently focus on Linux; future announcements could increase pressure.
Engineering effort	4	Full Windows/macOS analyzer support would require new parsers, evidence models, and Offline Kit updates.
Policy/config impact	3	Policy must account for OS-specific package sources and signing requirements.
Offline/air-gap impact	4	Supporting Windows/macOS would significantly expand Offline Kit footprint and mirroring workflows.

• Competitor capability: Trivy and Grype document Linux distribution coverage; Snyk Container relies on SaaS services and likewise focuses on Linux bases. None offer first-class offline Windows/macOS package scanning today.
• StellaOps gap: Platform currently scopes scanners to Linux; regulated customers with Windows/macOS workloads need clarity on future coverage.
• Proposed plan:
  1. Continue demand intake per docs/benchmarks/scanner/windows-macos-demand.md, capturing customer interviews, sales telemetry, and community updates.
  2. If demand crosses the documented threshold, scope a design spike covering evidence models (e.g., MSI, Chocolatey, Homebrew), Surface integration, and policy ramifications.
  3. Document interim guidance for hybrid workflows (e.g., importing third-party SBOMs) while native analyzers are out of scope.
• Policy considerations: Policies would need repository allowlists, signing requirements, and OS-specific mitigations; defer concrete templates until design spike completes.
• Next actions: Execute tasks DOCS-SCANNER-BENCH-62-002/003/004/005/006 as demand signals accrue; only open engineering backlog after demand review approves scope expansion.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Layer package DB parsing	apk, dpkg, rpm status/databases per layer	StellaOps.Scanner.Analyzers.OS.* with RustFS CAS	Produces per-layer fragments keyed by layer digest; composed into inventory/usage SBOM with provenance pointers.
Manifest + attestation binding	Distro manifest attestations, vendor signatures	Export Center + Signer/Attestor hand-off	Binds package fragments to DSSE attestations; policy consumes provenance metadata for trust weighting.
External SBOM import (interim)	Third-party SBOMs for Windows/macOS	Scanner SBOM import API (planned)	Imports produce declared-only entries flagged for policy review until native analyzers exist.

Secrets leak detection (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Security and compliance teams expect leak detection in parity with Trivy/Snyk.
Competitive risk	4	Trivy and Snyk market built-in secret scanners; lack of parity is visible.
Engineering effort	4	Requires deterministic scanner pipeline, rule packaging, and explainability.
Policy/config impact	5	Policy must gate rule sets, severities, and privacy guarantees.
Offline/air-gap impact	3	Rule packs must be versioned and bundled with Offline Kit.

• Competitor capability: Trivy ships regex/entropy secret analyzers with configurable rule packs; Snyk Code offers SaaS-based secret detection.
• StellaOps gap: Scanner intentionally avoids leak detection to preserve determinism, leaving customers without first-party secret scanning.
• Proposed plan:
  1. Implement a deterministic secret scanner plugin (StellaOps.Scanner.Analyzers.Secrets) supporting rule bundles signed and versioned for offline parity.
  2. Provide rule configuration via Surface.Validation (rule allowlists, target paths) and Surface.Secrets to manage sensitive allow rules.
  3. Emit findings into Policy Engine with new evidence types (secret.leak) so policies can enforce severity thresholds, ticket workflows, or waivers.
  4. Offer CLI verb (stella secrets scan) and integration into existing scan workflows behind an opt-in flag.
  5. Expose explain traces detailing rule IDs, masked snippets, and remediation guidance while upholding privacy constraints.
• Policy considerations: Deliver policy templates for severity gating, rule packs per tenant, and privacy controls; lattice logic should discount low-confidence matches.
• Next actions: open analyzer/CLI backlog work, coordinate with Docs Guild on policy templates, and bundle signed rule packs for Offline Kit distribution.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Operational secret retrieval	secret:// references resolved via Surface.Secrets providers	Surface.Secrets, Surface.Validation	Injects secrets at runtime; no SBOM entry created; policy ensures provenance of retrieved credentials.
Deterministic leak detection (planned)	File content, archives, bytecode	StellaOps.Scanner.Analyzers.Secrets (planned)	Emits secret.leak evidence with masked snippets; Policy Engine merges with package evidence using VEX gating.
Competitor leak scanning	Regex/entropy rulesets (Trivy pkg/fanal/secret), Snyk Code SaaS service	Trivy secret analyzer, Snyk Code API	Findings remain separate from SBOM data; StellaOps will map to policy evidence types once analyzer ships.

EntryTrace runtime command resolution (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Runtime teams rely on EntryTrace to separate inventory vs usage for policy decisions.
Competitive risk	4	Competitors lack equivalent capability; maintaining lead is critical marketing differentiator.
Engineering effort	3	Requires ongoing heuristics updates and parser maintenance for shells and launchers.
Policy/config impact	3	Policy uses EntryTrace outputs; enhancements must keep explainability stable.
Offline/air-gap impact	2	Heuristic catalog updates are lightweight and ship with Offline Kit.

• Competitor capability: Trivy, Grype, and Snyk do not offer runtime command resolution comparable to EntryTrace.
• StellaOps gap: To maintain leadership, EntryTrace heuristics must expand to new shells/launchers and provide richer explainability for policy consumers.
• Proposed plan:
  1. Establish a quarterly EntryTrace heuristic review cadence to ingest new shell patterns and language launchers (npm/yarn, poetry, bundle exec, etc.).
  2. Add explain-trace improvements (confidence scores, unresolved reason catalog) so Policy Engine and UI can surface actionable guidance when resolution fails.
  3. Provide a CLI report (stella entrytrace explain) summarising resolved/unresolved paths with remediation hints, aligned with policy predicates.
  4. Publish contribution guidelines for customers to submit launcher patterns, keeping deterministic ordering and tests.
• Policy considerations: Ensure policy predicates (e.g., entrytrace.resolution) include confidence metadata; lattice logic should treat unresolved entrypoints with configurable severity.
• Next actions: open backlog item for heuristic upkeep and docs task for CLI/policy explain guidance.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Shell AST parsing	Dockerfile ENTRYPOINT/CMD, shell scripts	StellaOps.Scanner.EntryTrace	Builds command graph with confidence scores; merged into usage SBOM to mark runtime components.
Wrapper catalogue resolution	Known launchers (npm, yarn, poetry, bundle exec, supervisor)	EntryTrace.WrapperCatalog	Resolves wrappers to underlying binaries; merges with language analyzers via UsageHints.
Fallback heuristics	History scripts, init configs, service manifests	EntryTrace heuristic expansions	Flags unresolved entrypoints with reasons; Policy Engine consumes to warn/fail.
Competitor baseline	—	Trivy/Grype/Snyk	No runtime resolution; StellaOps maintains differentiated capability.

DSSE/Rekor operator enablement (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Regulated tenants require auditable attestations and Rekor proofs for compliance handoffs.
Competitive risk	3	Trivy and Grype export SBOMs but lack DSSE/Rekor workflows; Snyk relies on SaaS attestations.
Engineering effort	2	Capabilities exist; need enablement guides, default policies, and operator tooling.
Policy/config impact	4	Policies must ensure attestation upload/log and enforce Rekor verifiability by tenant.
Offline/air-gap impact	2	DSSE/Rekor flows already support offline bundles; need better documentation and guardrails.

• Competitor capability: Trivy emits SBOMs and Cosign signatures but Rekor usage is manual; Grype consumes Syft SBOMs without attestations; Snyk Container signs via SaaS only.
• StellaOps gap: Signing pipeline exists (Signer → Attestor → Rekor v2) yet operators need prescriptive runbooks, policy defaults, and Export Center alignment.
• Proposed plan:
  1. Publish DSSE/Rekor operator guide detailing enablement, policy toggles, and verification CLI workflows.
  2. Extend Export Center profiles with attestation policy checks and Rekor proof bundling by default.
  3. Surface Rekor health metrics in Scanner.WebService and Notify to escalate failed submissions.
• Policy considerations: Provide policy predicates for attestation presence, Rekor inclusion, and proof expiry to enforce promotion gates.
• Next actions: Track via DOCS-SCANNER-BENCH-62-015 and SCANNER-ENG-0015 for playbook plus tooling updates.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
SBOM emission	CycloneDX/SPDX payloads per scan	Scanner emit pipelines	Generates inventory/usage BOMs stored with CAS hashes for attestation.
DSSE signing	DSSE bundles, signing keys	StellaOps.Signer + StellaOps.Attestor	Signs SBOM/report metadata, forwards to Rekor v2, records proof identifiers.
Rekor proof packaging	Rekor inclusion proofs, bundle metadata	Export Center attestation packager	Bundles proofs into Offline Kit/export artifacts; Policy verifies before release.
Competitor approach	CLI or SaaS-managed signing	Trivy Cosign integration, Snyk SaaS, Grype none	Operators must integrate manually; no default policy enforcement.

Ruby analyzer parity (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Rails and Sidekiq users expect first-party support with deterministic outputs.
Competitive risk	4	Trivy ships bundler/gemspec analyzers; Snyk offers SaaS rubygems scanning; Grype mirrors Syft data.
Engineering effort	5	Full analyzer stack (lockfile, runtime edges, capability signals) remains to be built.
Policy/config impact	4	Requires policy predicates for bundler groups, autoload resolution, and capability flags.
Offline/air-gap impact	3	Analyzer must ship with Offline Kit assets (fingerprints, autoload maps).

• Competitor capability: Trivy parses bundler and gemspec data (pkg/fanal/analyzer/language/ruby); Grype relies on Syft ruby catalogers; Snyk CLI delegates to rubygems plugin hitting SaaS.
• StellaOps gap: No Ruby analyzer in production; only backlog tasks exist.
• Proposed plan:
  1. Execute SCANNER-ANALYZERS-RUBY-28-001..012 to deliver lockfile parsing, autoload graphs, capability mapping, and observation outputs.
  2. Wire CLI () and Offline Kit packaging once analyzer stabilises.
  3. Provide policy templates covering bundler groups, native extension handling, and dynamic require warnings.
• Policy considerations: Policy Engine must treat declared groups versus runtime usage distinctly and allow waivers for development/test groups.
• Next actions: Coordinate via SCANNER-ENG-0009 and DOCS-SCANNER-BENCH-62-009 for documentation and rollout.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Bundler lock parsing	Gemfile, Gemfile.lock, vendor/bundle specs	Trivy bundler analyzer; planned StellaOps Ruby lock collector	Emits package graph with group metadata; merges with installed gems once analyzer ships.
Gemspec inspection	*.gemspec records, cached specs	Trivy gemspec analyzer; Syft gemspec cataloger	Provides metadata for packaged gems; merges for vendored dependencies.
Runtime require graph	require/require_relative, autoload hints	Planned StellaOps Ruby require analyzer	Links runtime usage to packages; Policy uses edges for explain traces.
Capability signals	exec, net/http, YAML load, Sidekiq configs	Planned StellaOps Ruby capability analyzer	Produces policy evidence for dangerous patterns and job schedulers.

PHP analyzer parity (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Magento, WordPress, Laravel tenants request deterministic composer coverage.
Competitive risk	4	Trivy composer analyzer handles lock/json; Snyk PHP plugin uploads manifests to SaaS; Grype relies on Syft composer data.
Engineering effort	5	Requires composer parsing, include graph, framework detectors, PHAR support.
Policy/config impact	4	Policies must recognise autoload mappings, dangerous functions, extension requirements.
Offline/air-gap impact	3	Analyzer assets must ship with Offline Kit (PHAR readers, fingerprints).

• Competitor capability: Trivy composer analyzer (pkg/fanal/analyzer/language/php/composer) walks composer.lock and composer.json; Snyk CLI defers to snyk-php-plugin; Grype inherits Syft composer cataloger.
• StellaOps gap: No PHP analyzer yet; tasks scoped but unimplemented.
• Proposed plan:
  1. Deliver SCANNER-ANALYZERS-PHP-27-001..012 covering composer parsing, include graph, PHAR handling, capability analysis.
  2. Integrate extension detection with Surface.Validation and policy templates for required extensions.
  3. Provide CLI commands () and Offline Kit documentation.
• Policy considerations: Configure policies for autoload coverage, dangerous constructs, upload limits, and extension presence.
• Next actions: SCANNER-ENG-0010 and DOCS-SCANNER-BENCH-62-010 own design and documentation deliverables.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Composer lock parsing	composer.lock, composer.json	Trivy composer analyzer; planned StellaOps Composer collector	Generates package graph with direct versus transitive dependency tagging.
Autoload resolution	psr-0/psr-4/classmap/files entries	Planned StellaOps PHP autoload analyzer	Builds module graph; merges with capability scanner to highlight runtime usage.
Capability detection	exec, curl, unserialize, stream wrappers	Planned StellaOps PHP capability analyzer	Records evidence with file/line hashes; policy consumes for risk scoring.
PHAR inspection	.phar archives, stub metadata	Planned StellaOps PHAR inspector	Expands embedded vendor trees; merges with package inventory.

Deno analyzer outlook (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	2	Limited but growing demand from edge/runtime teams adopting Deno.
Competitive risk	2	Trivy, Grype, and Snyk lack dedicated Deno analyzers; coverage relies on generic JavaScript workflows.
Engineering effort	3	Requires lockfile parser, import graph resolution, and permission model mapping.
Policy/config impact	3	Policies must treat Deno permissions (net/fs/run) and URL-based modules.
Offline/air-gap impact	3	Need cached registry mirrors or import map handling for air-gapped runs.

• Competitor capability: Current tooling leans on npm/pnpm analyzers; no first-party Deno parser is shipped in Trivy, Grype, or Snyk.
• StellaOps gap: No analyzer today; opportunity to differentiate with deterministic import resolution and permission mapping.
• Proposed plan:
  1. Scope parsing for deno.lock and import maps with content-addressed module fetching.
  2. Map permission declarations () into policy evidence.
  3. Provide Offline Kit guidance for cached module registries and pinned URLs.
• Policy considerations: Introduce policy predicates for Deno permission sets and remote module domains.
• Next actions: SCANNER-ENG-0011 and DOCS-SCANNER-BENCH-62-011 to draft design spike and documentation.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Lockfile analysis (planned)	deno.lock, import maps	Planned StellaOps Deno collector	Produces module graph keyed by URL; merges with cached artifacts.
Permission audit	CLI flags, configuration files	Planned Deno policy analyzer	Records required permissions for policy gating.
Competitor fallback	Manifest-based npm/pnpm scans	Trivy npm analyzer; Snyk node plugins	Provides partial coverage; lacks Deno permissions and remote module mapping.

Dart analyzer roadmap (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	2	Dart/Flutter containers are niche but emerging in regulated workloads.
Competitive risk	3	Trivy parses pubspec lockfiles; Snyk references SaaS plugin; Grype lacks native support.
Engineering effort	4	Requires pubspec.lock parser, AOT snapshot fingerprinting, and runtime usage mapping.
Policy/config impact	3	Policies must recognise build modes (debug/release) and AOT binaries.
Offline/air-gap impact	3	Need mirrored pub registries and snapshot tooling packaged offline.

• Competitor capability: Trivy Dart analyzer (pkg/fanal/analyzer/language/dart/pub) parses pubspec.lock; Snyk delegates to SaaS; Grype is absent.
• StellaOps gap: No Dart analyzer or policy templates today.
• Proposed plan:
  1. Implement pubspec.lock parser with dependency graph and hosted path resolution.
  2. Fingerprint Dart AOT snapshots to tie binaries back to packages.
  3. Emit capabilities (platform channels, native plugins) for policy gating.
• Policy considerations: Distinguish debug versus release builds; allow tenants to require AOT parity.
• Next actions: SCANNER-ENG-0012 and DOCS-SCANNER-BENCH-62-012 handle design and doc updates.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Lockfile parsing	pubspec.lock, pubspec.yaml	Trivy Dart analyzer; planned StellaOps Dart collector	Builds dependency graph with hosted path info; merges with runtime fingerprints.
Snapshot fingerprinting	AOT snapshots, dill files	Planned Dart snapshot analyzer	Maps binaries to packages and versions; flagged for policy when unmatched.
Capability mapping	Flutter platform channels, plugin manifests	Planned Dart capability analyzer	Records platform usage for policy weighting.

Swift analyzer assessment (Trivy, Grype, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	3	iOS/macOS teams expect Package.resolved support once macOS scanning lands.
Competitive risk	4	Trivy supports SwiftPM and CocoaPods; Snyk ships swift plugin; Grype lacks native Swift analyzers.
Engineering effort	4	Requires SwiftPM parsing, xcframework metadata, and runtime usage heuristics.
Policy/config impact	4	Policies must check binary signature, platform targets, and dynamic library usage.
Offline/air-gap impact	3	Need mirrored Swift package indexes for air-gapped runs.

• Competitor capability: Trivy swift analyzers (pkg/fanal/analyzer/language/swift) parse Package.resolved and CocoaPods; Snyk swift plugin relies on SaaS.
• StellaOps gap: No Swift analyzer yet; Windows/macOS coverage pending.
• Proposed plan:
  1. Design SwiftPM parser and binary metadata collector under Swift analyzer guild.
  2. Plan signature validation and entitlements capture for macOS targets.
  3. Coordinate with Offline Kit to mirror Swift registries and xcframework assets.
• Policy considerations: Provide predicates for platform targets, entitlements, and signing requirements.
• Next actions: SCANNER-ENG-0013 and DOCS-SCANNER-BENCH-62-013 drive design and documentation tasks.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
SwiftPM parsing	Package.swift, Package.resolved	Trivy swift analyzer; planned StellaOps Swift collector	Produces dependency graph with target info; merges into SBOM inventory.
CocoaPods integration	Podfile.lock, Pods directory	Trivy CocoaPods analyzer; planned StellaOps CocoaPods collector	Maps pods to app targets; merges with SwiftPM data.
Binary metadata	xcframeworks, Mach-O signatures	Planned Swift binary analyzer	Captures signing, architectures, and entitlements; fed into policy engine.

Kubernetes/VM target coverage alignment (Trivy, Snyk)

Scorecard

Dimension	Score (1-5)	Notes
Customer demand	4	Platform teams expect coverage for live clusters, VMs, and admission controls.
Competitive risk	3	Trivy Operator and Snyk monitor clusters but lack deterministic attestations; Grype stays image-focused.
Engineering effort	3	Needs coordination between Scanner, Zastava, and runtime posture services.
Policy/config impact	4	Policies must combine runtime posture data with scan evidence.
Offline/air-gap impact	3	Requires offline posture bundles and admission controller configuration guidance.

• Competitor capability: Trivy Operator scans clusters via live API calls; Snyk relies on SaaS; Grype covers images only.
• StellaOps gap: Scanner handles images/filesystems; runtime enforcement lives in Zastava and needs coordinated roadmap.
• Proposed plan:
  1. Produce joint roadmap clarifying Scanner versus Zastava responsibilities for clusters and VMs.
  2. Document how runtime posture feeds into Policy Engine and Export Center outputs.
  3. Provide Offline Kit assets for Zastava admission policies and scheduler hooks.
• Policy considerations: Expand policy predicates to ingest runtime posture signals (signed images, SBOM availability, policy verdicts).
• Next actions: SCANNER-ENG-0014 and DOCS-SCANNER-BENCH-62-014 deliver roadmap and documentation.

Detection techniques

Technique	Artifacts	Analyzer / Module	Merge strategy
Image/file scan	Container images, filesystem snapshots	StellaOps.Scanner.Worker	Provides deterministic inventory and usage data for images.
Runtime posture (planned)	Admission events, sensor telemetry	Zastava.Observer and Webhook	Supplies runtime evidence (signed images, drift) merged into policy overlays.
Cluster drift detection	Scheduler and Vuln Explorer events	Scheduler + Policy Engine	Detects advisory/VEX deltas and schedules analysis-only runs.
Competitor workflow	Live API queries and SaaS services	Trivy Operator; Snyk Kubernetes integration	Offers visibility but lacks attestations and offline parity.