audit-logs

Audit Logs

Scan the codebase for logging issues — PII exposure, secrets, and sensitive data leaks.

Important: This skill is read-only. It reports findings but does NOT make changes automatically. Always present the report first and ask the user what they want to fix.

Steps

1. Find all log statements

Scan the project for all logging calls. Look for:

• Shipbook: log.e(), log.w(), log.i(), log.d(), log.v(), Log.e(), Log.w(), etc.
• Standard: console.log, console.error, console.warn, print(), NSLog(), android.util.Log
• Framework loggers: logger.info(), logger.error(), Timber.d(), etc.

2. Check for secrets and sensitive data (high priority)

These must never appear in logs. Flag immediately:

• Passwords and secrets — variable names like password, secret, token, apiKey, accessToken, refreshToken, authorization
• Full credit card numbers — patterns like \d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}. Logging the last 4 digits is acceptable (e.g., **** **** **** 1234), but the full number must never be logged.
• SSN, national ID, and passport numbers — variable names like ssn, socialSecurity, nationalId, idNumber, passportNumber, passport. These are government-issued identifiers used for identity theft and are protected under GDPR, CCPA, and most privacy laws. They must never appear in logs.

These are non-negotiable — present them as critical findings that need immediate attention.

3. Check for personal identifiers (ask user)

These are suggestions — the user may have valid reasons to log them. Present as recommendations and ask before changing:

• Email addresses logged directly — suggest using userId or hashed identifier instead
• Phone numbers — variable names like phone, phoneNumber, mobile
• Physical addresses — address, street, zipCode, postalCode
• Full names — fullName, firstName, lastName logged directly in message strings

Recommendation example:

// Consider replacing direct PII with internal identifiers:
log.i(`User logged in: ${user.email}`)
// Could be:
log.i(`User logged in: ${user.id}`)