b1e78fe412
Some checks failed
Docs CI / lint-and-preview (push) Has been cancelled
- 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.
43 lines
4.2 KiB
Markdown
43 lines
4.2 KiB
Markdown
# 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`
|