stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 1 Releases Wiki Activity
Files
40e7f827da764e39ca67fc27a74813a98e9a38d2
git.stella-ops.org/docs/benchmarks/scanner/deep-dives/secrets.md
master b1e78fe412
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Details
feat: Implement vulnerability token signing and verification utilities 
- Added VulnTokenSigner for signing JWT tokens with specified algorithms and keys.
- Introduced VulnTokenUtilities for resolving tenant and subject claims, and sanitizing context dictionaries.
- Created VulnTokenVerificationUtilities for parsing tokens, verifying signatures, and deserializing payloads.
- Developed VulnWorkflowAntiForgeryTokenIssuer for issuing anti-forgery tokens with configurable options.
- Implemented VulnWorkflowAntiForgeryTokenVerifier for verifying anti-forgery tokens and validating payloads.
- Added AuthorityVulnerabilityExplorerOptions to manage configuration for vulnerability explorer features.
- Included tests for FilesystemPackRunDispatcher to ensure proper job handling under egress policy restrictions.
2025-11-03 10:04:10 +02:00

4.2 KiB
Raw Blame History

Secret Handling

StellaOps approach

  • Detailed Policy/Security briefing: ../../modules/policy/secret-leak-detection-readiness.md.
  • Secrets treated as operational inputs delivered through Surface.Secrets (src/Scanner/__Libraries/StellaOps.Scanner.Surface.Secrets and documented in docs/modules/scanner/design/surface-secrets.md).
  • Providers support Kubernetes Secrets, file-based bundles, and inline definitions; configuration resolved via Surface.Env with validation gates from Surface.Validation.
  • Secret placeholders (secret://type/name) are resolved before analyzers execute, with results wrapped in secure handles and rotation metadata checked at startup.
  • Scanner deliberately avoids scanning artefacts for secret disclosure to preserve deterministic SBOM pipelines and avoid exposing sensitive payloads.

Trivy approach

  • Secret scanning integrated as an analyzer under pkg/fanal/secret, applying regex-based detectors across plaintext files and certain bytecode (e.g., .pyc).
  • Builtin rule sets detect common credentials (AWS, GCP, GitHub PATs, private keys) with allow/deny configurations (pkg/fanal/secret/builtin-allow-rules.go) and support custom rule packs via trivy-secret.yaml.
  • Findings include file path, line number, severity, and match; operators fine-tune via CLI options (--secret-config, --skip-dirs, enable-builtin-rules).
  • Secret storage/rotation is outside Trivy scope; deployments manage credentials independently.

Snyk approach

  • Secret detection is available through Snyk Code scans (snyk code test), invoked from the CLI via the Snyk Code plugin stack (src/lib/plugins/sast).[s1]
  • CLI usage requires authentication and uploads code to Snyk’s SaaS backend (per README guidance), so offline workflows are not supported.[s2]
  • Results focus on issue listings from the service; operational secret management is not part of the CLI.

Grype approach

  • Grype does not ship a secret-scanning analyzer; secrets surface only as credentials for registry access (cmd/grype/cli/options/secret.go, README sections on mounting Kubernetes secrets).
  • Operators must rely on external tooling for leak detection while Grype focuses exclusively on vulnerability matching.[g1]

Key differences

  • Purpose: StellaOps focuses on secure retrieval/validation of operational secrets; Trivy and Snyk Code detect leaked secrets, whereas Grype omits secret detection entirely.
  • Workflow: StellaOps’ secret lifecycle is pre-scan configuration; Trivy and Snyk analyse content at scan time (Snyk requiring SaaS connectivity), and Grype requires external tooling for leak detection.
  • Determinism: StellaOps avoids non-deterministic leak scans; Trivy and Snyk’s detectors may evolve with rule updates; Grype remains deterministic by not attempting secret discovery.

Detection technique comparison

Tool Detection technique(s) Merge / result handling Notes
StellaOps (current) Surface.Secrets providers fetch credentials at runtime; no leak scanning today. Secrets resolve to opaque handles stored in scan metadata; no SBOM entries emitted. Deterministic and explainable; avoids exposing payloads.
StellaOps (planned) StellaOps.Scanner.Analyzers.Secrets plug-in executing signed rule bundles. Findings inserted into ScanAnalysisStore as secret.leak evidence; Policy Engine merges with component context and lattice scores. Rules packaged offline; CLI/reporting masks payloads while surfacing rule IDs.
Trivy Regex + entropy detectors under pkg/fanal/secret (configurable via trivy-secret.yaml). Detectors aggregate per file; results exported alongside vulnerability findings without provenance binding. Ships built-in rule sets; users can add allow/block lists.
Snyk Snyk Code SaaS classifiers invoked by CLI plugin (src/lib/plugins/sast). Source uploaded to SaaS; issues returned with severity + remediation; no offline merge with SBOM data. Requires authenticated cloud access; rules evolve server-side.
Grype None (focuses on vulnerability matching). — Operators must integrate separate tooling for leak detection.

References

  • [s1] /tmp/snyk-cli/src/lib/plugins/sast
  • [s2] /tmp/snyk-cli/README.md
  • [g1] /tmp/grype/README.md