Scanning Gaps — Competitor Techniques Missing in StellaOps

.NET lockfile ingestion (Trivy, Snyk)

Scorecard

• 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

Node.js pnpm lock validation (Trivy, Snyk)

Scorecard

• 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

Python lockfile & editable install coverage (Trivy, Snyk)

Scorecard

• 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

Java build-tool lockfile ingestion (Trivy, Snyk)

Scorecard

• 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

Go stripped binary enrichment (Trivy, Grype)

Scorecard

• 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

Rust fingerprint coverage (Trivy, Grype)

Scorecard

• 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

• 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.

Implementation details

• StellaOps:
  • Linux analyzers live under StellaOps.Scanner.Analyzers.OS.(Apk|Dpkg|Rpm) and inherit from OsPackageAnalyzerBase, which normalises package metadata, file evidence, and vendor fields before persisting content-addressed fragments via Surface.FS.
  • Analyzer results are converted to LayerComponentFragments by OsComponentMapper and cached inside the worker ScanAnalysisStore; downstream SBOM assembly keeps layer digests and provenance so usage/inventory views can be replayed deterministically.
  • Export Center binds OS fragments to DSSE attestations through Signer/Attestor so operators can prove provenance for every package list in offline bundles.
• Trivy:
  • Package analyzers under pkg/fanal/analyzer/pkg/(apk|dpkg|rpm) walk layer file systems and emit types.Package results; the upstream coverage matrix in docs/docs/coverage/os/*.md drives which distro manifests and feeds ship with Trivy releases.
  • Results are flattened per artifact, leaving layer attribution to Syft-style catalog walks; provenance and diffing are delegated to downstream tooling.
• Grype:
  • Delegates cataloguing to Syft, then applies matchers in grype/matcher/{apk,dpkg,rpm} that resolve distro namespaces and fix statuses using Anchore feeds.
  • Evidence is matched at scan time without long-lived fragments, so reproducibility depends on feed snapshots rather than packaged artifacts.
• Snyk:
  • snyk container test uploads image metadata to Snyk SaaS; coverage is dictated by the hosted service and cannot run offline.
  • No layer-aware evidence is returned; operators rely on SaaS reports for package presence and risk.

Detection techniques

macOS package coverage (Trivy, Grype, Snyk)

Scorecard

• Competitor capability: None of Trivy, Grype, or Snyk provide macOS host/package coverage; their documentation lists Linux-only ecosystems.
• StellaOps gap: No macOS analyzers exist; design work is captured in docs/benchmarks/scanner/deep-dives/macos.md but implementation/backlog stories are not yet opened.
• Proposed plan:
  1. Finalise demand assessment (DOCS-SCANNER-BENCH-62-002) using customer interviews, sales telemetry, and support tags.
  2. Scope macOS analyzer design spike covering Homebrew cellar parsing, pkgutil receipt ingestion, and .app bundle inspection; include entitlements/notarization strategy.
  3. Define Policy Engine predicates for entitlements, notarization status, bundle signing chain, and tenant allow lists.
  4. Coordinate with Offline Kit guild on mirroring tap metadata, notarization caches, and CRL/OCSP content for air-gapped operation.
• Milestones: Northwind Health Services demo (2025-11-10) doubles as POLICY-READINESS-0001 workshop to finalise masking/telemetry defaults before spike approval.
• Policy considerations: Need predicates for macos.entitlement, macos.notarized, macos.bundle.teamId, and severity rules for unsigned or unnotarized software; waivers should bind to bundle hash + signer.
• Next actions: Keep windows-macos-demand.md updated, prepare design brief once threshold met, and log engineering backlog items (SCANNER-ENG-00xx) for macOS collectors and policy integration.

Implementation details

• Design references: docs/benchmarks/scanner/deep-dives/macos.md captures proposed collectors (Homebrew, receipts, bundles) and open questions for Security/Policy guilds.
• Collector outline:
  • Homebrew collector enumerates Cellar manifests under /usr/local/Cellar and /opt/homebrew/Cellar, mapping taps to PURLs and retaining bottle SHA256 for provenance.
  • pkgutil collector parses /var/db/receipts/*.plist and .bom files to record installer package metadata with deterministic hashes.
  • Bundle inspector walks .app directories, extracting Info.plist, entitlements, embedded frameworks, and code signing chains.
• Merge strategy: Collectors will emit component fragments keyed by bundle/tap identifiers; planned aggregator merges receipts and cellular data where identifiers match, tagging capabilities for Policy Engine.
• Offline requirements: Bundle signed rule packs (tap metadata snapshots, entitlements schema) with Offline Kit; ensure notarization cache instructions are documented.

Detection techniques

Windows package coverage (Trivy, Grype, Snyk)

Scorecard

• Competitor capability: Trivy, Grype, and Snyk do not ship Windows host analyzers; tooling focuses on Linux ecosystems and SaaS flows.
• StellaOps gap: No Windows analyzers exist yet; design outline under docs/benchmarks/scanner/deep-dives/windows.md.
• Proposed plan:
  1. Complete demand validation and prioritisation (DOCS-SCANNER-BENCH-62-002) alongside macOS signals.
  2. Execute engineering spike covering MSI/WinSxS parsing, Chocolatey inventory, and registry-based fallbacks.
  3. Define Policy Engine predicates for Authenticode, driver risk, service start mode, and Chocolatey provenance.
  4. Coordinate Offline Kit packaging strategy for MSI schemas, feed snapshots, and certificate revocation caches.
• Policy considerations: Introduce predicates such as windows.package.signed(teamId?), windows.driver.kernelMode, windows.service.startType, and waivers tied to product code + signature thumbprint.
• Next actions: Maintain demand tracker, execute DOCS-SCANNER-BENCH-62-016, refine docs/modules/scanner/design/windows-analyzer.md, and open SCANNER-ENG-0024…0027 backlog tickets for collector and policy work once demand threshold is confirmed.
• Milestones: POLICY-READINESS-0002 Authenticode/feed decision due 2025-11-07 (FinSecure PCI blocker) gates Windows analyzer spikes.

Implementation details

• Design references: docs/benchmarks/scanner/deep-dives/windows.md, docs/modules/scanner/design/windows-analyzer.md.
• Policy readiness: see docs/modules/policy/windows-package-readiness.md for predicate requirements, waiver model, and offline guidance.
• Collector outline:
  • MSI/WinSxS collector to parse installer databases/manifests and correlate via file hashes.
  • Chocolatey collector to read nuspec metadata and install scripts, retaining feed provenance.
  • Registry collector to harvest uninstall/service keys, linking to filesystem artefacts and signatures.
• Merge strategy: Planned WindowsComponentMapper merges MSI, WinSxS, Chocolatey, and registry evidence into unified fragments with provenance metadata; capability overlays capture services/drivers.
• Offline requirements: Bundle MSI schema definitions, Chocolatey feed snapshots, Windows Update catalog hashes, and certificate chains; document cache priming steps for air-gapped environments.

Detection techniques

Secrets leak detection (Trivy, Snyk)

Scorecard

• 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: Track execution via SCANNER-ENG-0007 (design/implementation) and DOCS-SCANNER-BENCH-62-007 (policy/docs); bundle signed rule packs for Offline Kit distribution once analyzer stories land.

Implementation details

• StellaOps:
  • Operational secret retrieval flows through Surface.Secrets providers (Kubernetes, file bundle, inline) with validation policies enforced by Surface.Validation; handles remain opaque to analyzers.
  • Planned StellaOps.Scanner.Analyzers.Secrets plug-in will execute deterministic rule bundles signed by the Export Center signing stack; findings land in ScanAnalysisStore alongside component fragments.
  • Policy Engine will ingest secret.leak evidence with lattice hints (confidence, rule.id, masking.applied) so tenants can tune severities and approvals.
• Trivy:
  • Secret detection is implemented in pkg/fanal/secret with detectors combining regex and entropy heuristics; rules merge into Result objects per file with severity weighting.
  • Configuration is provided via trivy-secret.yaml, enabling per-rule enable/disable and allow lists.
• Snyk:
  • CLI delegates to Snyk Code (src/lib/plugins/sast) which uploads source or image contents to SaaS for analysis; results stream back as issue JSON with remediation tips.
  • Offline execution is unsupported; rule updates ship server-side.
• Grype:
  • No leak detection analyzer; secrets are only used for registry authentication options.

Detection techniques

EntryTrace runtime command resolution (Trivy, Grype, Snyk)

Scorecard

• 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

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

Scorecard

• 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.

Implementation details

• StellaOps:
  • StellaOps.Signer generates DSSE envelopes for SBOMs/reports using PoE-scoped keys and forwards them to StellaOps.Attestor, which handles Rekor v2 submissions with retries and proof caching.
  • Export Center profiles bundle DSSE payloads, Rekor inclusion proofs, and any external attestations into offline-ready archives; CLI and Policy Engine verify proofs before release.
  • Notify + Scanner.WebService emit attestation health telemetry so operators can quickly spot and remediate failed Rekor submissions.
• Trivy / Grype / Snyk:
  • Trivy supports optional Cosign signing but leaves Rekor submission manual; proofs are not bundled with scanner outputs.
  • Grype leans on Syft for SBOM export and does not sign outputs.
  • Snyk Container/Snyk CLI rely on SaaS-managed signing and do not expose DSSE workflows or offline proof packaging.

Detection techniques

Ruby analyzer parity (Trivy, Grype, Snyk)

Scorecard

• 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

PHP analyzer parity (Trivy, Grype, Snyk)

Scorecard

• 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

Deno analyzer outlook (Trivy, Grype, Snyk)

Scorecard

• 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

Dart analyzer roadmap (Trivy, Grype, Snyk)

Scorecard

• 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

Swift analyzer assessment (Trivy, Grype, Snyk)

Scorecard

• 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

Kubernetes/VM target coverage alignment (Trivy, Snyk)

Scorecard

• 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