fix: stop sanitizeSkopeoErrorForLogging swallowing non-skopeo errors

[parker-snyk]

• Tests written and linted
• Documentation written (n/a — internal log-sanitization helper)
• Commit history is tidy

What this does

Fixes CN-1360 (parent CN-1359).

sanitizeSkopeoErrorForLogging in src/scanner/images/index.ts unconditionally deletes message from every error caught in pullImages. The intent was to scrub the skopeo command line, which embeds credentials passed via --src-creds <user:pass>. The side effect: non-skopeo errors (e.g. ECR credential-resolution failures under IRSA) also lose their message, leaving only a useless log line:

failed to pull image docker/oci archive image

…with no actionable detail. Tessl AI hit this on v2.22.20.

This PR branches on the error shape:

• Skopeo ChildProcessErrors (identified by a populated stderr field) — drop message (creds), drop childProcess and stack, keep stderr (the actual skopeo failure detail).
• Every other error (no stderr) — keep message so the underlying cause survives. Still drop childProcess and stack defensively.

The helper now also returns a new object instead of mutating the input, and the error: any is replaced with error: unknown plus narrowing.

Notes for the reviewer

• Function is now exported (// Exported for testing) so unit tests can hit it directly.
• New tests in test/unit/scanner/images.spec.ts cover both branches plus non-object / empty-stderr edge cases, and explicitly assert that --src-creds / the secret value never appear in the sanitized output.
• No behavioural change to pullImages itself; only the contents of the logged error object differ.

Test plan

• npm run lint:eslint clean
• npm run test:unit — 312 tests pass (18 suites)
• New unit test asserts --src-creds and the credential value are absent from the sanitized skopeo error
• New unit test asserts message is preserved for non-skopeo errors (e.g. "ECR token fetch failed")
• Manual review: original error object is not mutated by the sanitizer

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 Security concerns Sensitive information exposure: The PR modifies how credentials are scrubbed from logs. By conditioning the removal of the message property (which contains the full command line including credentials) on the presence of stderr, there is a risk that atypical Skopeo failures (where stderr is empty) will lead to credentials being logged. However, this is a trade-off made to fix a confirmed bug where critical system errors were being silenced. A safer approach might involve regex-based scrubbing of the message string instead of unconditional deletion or conditional preservation.

⚡ Recommended focus areas for review Credential Leakage Risk 🟡 [minor] The logic for isSkopeoChildProcessError relies on stderr being a non-empty string. If skopeo or the underlying process wrapper fails before writing to stderr (e.g., an internal execution error), isSkopeoChildProcessError will be false. In this scenario, the message property—which contains the raw command line including --src-creds—will be preserved and logged. While the PR improves observability for non-Skopeo errors, it creates a narrow window where credentials might still be logged if a Skopeo execution fails silently. const isSkopeoChildProcessError = typeof source.stderr === 'string' && source.stderr.length > 0;

📚 Repository Context Analyzed This review considered 10 relevant code sections from 9 files (average relevance: 0.77) src/scanner/images/skopeo.ts (lines 1-201) src/supervisor/metadata-extractor.ts (lines 1-249) src/supervisor/watchers/handlers/pod.ts (lines 1-195) src/supervisor/watchers/handlers/queue.ts (lines 1-83) src/data-scraper/index.ts (lines 1-125) src/scanner/images/types.ts (lines 1-40) package.json (lines 1-119) ... and 2 more file(s)