stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 1 Releases Wiki Activity
Files
1d962ee6fc98ad8c53715bbff6d513246f5b1361
git.stella-ops.org/docs/benchmarks/scanner/deep-dives/secrets.md
master 1d962ee6fc
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
Details
Add OpenSslLegacyShim to ensure OpenSSL 1.1 libraries are accessible on Linux 
This commit introduces the OpenSslLegacyShim class, which sets the LD_LIBRARY_PATH environment variable to include the directory containing OpenSSL 1.1 native libraries. This is necessary for Mongo2Go to function correctly on Linux platforms that do not ship these libraries by default. The shim checks if the current operating system is Linux and whether the required directory exists before modifying the environment variable.
2025-11-02 21:41:03 +02:00

2.8 KiB
Raw Blame History

Secret Handling

StellaOps approach

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

References

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