"Sovereignty is not speed — it is the discipline to preview, confirm, then execute."

This document outlines security practices, backup recovery procedures, and responsible disclosure guidelines for Sovereign-DevKit, aligned with the Mkhitarian Philosophy of ethical, intentional execution.

🔄 Recommendation: Always use the latest v3.1.x release for safety controls (--dry-run, --backup, --report).

1. Intent Before Execution — Preview changes with --dry-run before applying fixes.
2. Sovereignty Over Convenience — Auto-backups (.bak) are enabled by default; you control your data.
3. Transparency By Design — All detection patterns are visible in-source; no hidden logic.
4. Zero-Trust Output — Detected values are redacted ([REDACTED]) even in scan logs.
5. Minimal Attack Surface — Zero external dependencies; pure Node.js built-ins only.

When using --fix (with default --backup), LogSanitizer.js creates a .bak copy before modifying any file:

# Original file
config.js

# After: node LogSanitizer.js config.js --fix
config.js      # ← Sanitized (leaks redacted)
config.js.bak  # ← Original content preserved

If you need to restore a file after redaction:

# 1. Verify the backup exists
ls -la config.js.bak
# 2. Restore the original
cp config.js.bak config.js

# 3. (Optional) Re-scan with stricter filters
node LogSanitizer.js config.js --ext .js --dry-run

• ✅ Always test with --dry-run first
• ✅ Keep .bak files locally until you confirm the fix is correct
• ✅ Delete .bak files only after verification: rm *.bak
• ❌ Never commit .bak files to version control (ignored by default in .gitignore)

If LogSanitizer.js flags a value that is not a sensitive leak:

Check if the value appears in:

• Test/mock files (test/, mocks/, __tests__/)
• Documentation or comments
• Example configuration (.env.example)

Future versions will auto-ignore known safe patterns. For now, use extension filtering:

# Scan only production-relevant files
node LogSanitizer.js ./src --ext .js,.ts,.env

Open an issue with:

## False Positive Report

- **File path**: `path/to/file.js`
- **Flagged pattern**: `[paste the regex name or sample]`
- **Why it's safe**: [brief explanation]
- **LogSanitizer.js version**: `v3.1.0`

🔗 → Open a New Issue

If you discover a genuine security vulnerability in Sovereign-DevKit:

• Contact the maintainer privately first (see below)
• Provide reproducible steps and impact assessment
• Allow reasonable time for a fix before public disclosure

• Exploit the vulnerability beyond testing
• Disclose details publicly before a patch is released
• Access or modify data you don't own

• Primary: GitHub Issue (private template)
• Secondary: ORCID Profile → Find contact info
• Response Time: Within 72 hours for critical issues

Before submitting a PR that modifies detection logic:

# 1. Run dry-run on test suite
node LogSanitizer.js ./tests --dry-run

# 2. Verify no false positives on clean files
node LogSanitizer.js ./src --ext .js --report

# 3. Confirm backup behavior
echo "TEST=sk-test-fake-key" > test.env
node LogSanitizer.js test.env --fix
[ -f test.env.bak ] && echo "✅ Backup created"

# 4. Clean up test artifacts
rm -f test.env test.env.bak report.json

"Architecture is a product of thought — not infrastructure. Constraints refine systems instead of limiting them."

Every security decision in Sovereign-DevKit reflects the Mkhitarian Principles:

• 🎯 Intent: Tools require conscious approval before modification
• 🛡️ Sovereignty: Users retain full control over backups and data
• 🔍 Transparency: All logic is open-source and auditable
• ⚡ Simplicity: Minimal code = minimal attack surface
• 📱 Human-First: Designed for mobile developers with limited resources

• License: MIT
• Author: El Madani El Mkhitar
• Philosophy: Mkhitarian Philosophy

"In the Name of the Creator, We Build."