Individual skill

logging-security

Keep secrets and personal data out of logs at the call site rather than relying on redaction, neutralize log and field injection, record audit events that survive, and treat log read access as data access. Use when generating logger calls or structured-logging schemas, wiring log shippers, sinks, retention, and access controls, or specifying audit-logging requirements.

dist/agent-skills/.agents/skills/logging-security/SKILL.md

Read pinned source

Source commit eaba88102d91df65a9aa6397e8507c315c018f5e

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Instructions only
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
23
Repository last updated
Aug 14, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/logging-security/SKILL.md. -->

# Logging Security

Keep secrets and personal data out of logs at the call site rather than relying on redaction, neutralize log and field injection, record audit events that survive, and treat log read access as data access. Use when generating logger calls or structured-logging schemas, wiring log shippers, sinks, retention, and access controls, or specifying audit-logging requirements.

## ALWAYS

- Decide what is safe to log **at the call site**, and log a reference rather than a value: an id, a hash, a type, a count. A redactor is the last net, not the design — it matches field names and known patterns, so it cannot see personal data sitting inside an assembled string. A formatted notification body, a templated message, an exception with interpolated arguments: the name and the address are in the prose, in no named field, matching no pattern. Nothing downstream will catch that.
- Run a **redactor** at the sink anyway, for the cases the call site missed: credential-shaped values, `Authorization` and `Cookie` headers, query strings carrying tokens, and the personal-data patterns in `rules/redaction_patterns.json`. `secret-detection` owns which literals count as a credential; this rule is that the redactor exists and runs before anything leaves the process.
- Log in a **structured format** (JSON or logfmt) with stable field names — `timestamp`, `service`, `version`, `level`, `trace_id`, `span_id`, `request_id`, `event`, and `user_id` when there is an authenticated one. Structure is what makes redaction, retention, and access control expressible per field instead of per line.
- Neutralize user-controlled strings before they enter a log record. Line injection (CWE-117) is the classic case — a `\n` or `\r` lets an attacker forge a whole record — but structured logging moves the problem: a value that parses as JSON can inject *fields* into the ingested document, and ANSI escape sequences (`\x1b[`) are interpreted by the terminal of whoever reads the log. Encode the value; do not concatenate it into the line.
- Record security-relevant events as **immutable audit records**: authentication success and failure, MFA challenges, password and role changes, permission grants and revocations, data export, administrative action. These carry longer retention and stricter access than operational logs, and they are the reason failed logins must keep being written even when someone calls them noise.