We release security updates for the following versions:

We provide security updates for the latest pre-release version and the current major version and the previous major version for a minimum of 6 months after the next major release.

We take the security of Serilog.Sinks.File.Encrypt seriously. If you believe you have found a security vulnerability, please report it to us as described below.

Please do not report security vulnerabilities through public GitHub issues.

Instead, please report them via GitHub Security Advisories:

1. Navigate to the Security tab of this repository
2. Click "Report a vulnerability"
3. Fill out the advisory form with as much detail as possible

Please include the following information in your report:

• Type of issue (e.g., buffer overflow, encryption weakness, key exposure)
• Full paths of source file(s) related to the issue
• Location of the affected source code (tag/branch/commit or direct URL)
• Step-by-step instructions to reproduce the issue
• Proof-of-concept or exploit code (if possible)
• Impact of the issue, including how an attacker might exploit it

• Initial Response: We will acknowledge receipt of your vulnerability report within 10 business days
• Assessment: We will assess the vulnerability and determine its severity within 10 business days
• Fix Development: For confirmed vulnerabilities, we will work on a fix and aim to release it within:
  • Critical vulnerabilities: 14 days
  • High severity: 30 days
  • Medium/Low severity: 60 days

When using Serilog.Sinks.File.Encrypt in production, follow these security best practices:

Never store private keys in your application code or configuration files that are committed to version control.

• Use 2048-bit RSA keys minimum: Default is 2048-bit, but consider 4096-bit for enhanced security at a performance cost:

  serilog-encrypt generate --output ./keys --key-size 4096

• Generate unique keys per environment: Don't reuse the same keys across dev/staging/production

• Store private keys separately: Only deploy public keys with your application

Key rotation is essential for long-term security:

1. Generate new key pair without replacing the old one
2. Deploy application with new public key for writing new logs
3. Keep old private key available for reading historical encrypted logs
4. Archive old logs after retention period expires
5. Safely destroy old private keys when logs are no longer needed

• Restrict file system permissions: Ensure only authorized users/processes can read encrypted log files
• Secure the private key: Private keys should have the most restrictive permissions possible
• Audit access: Monitor and log access to encrypted log files and private keys
• Principle of least privilege: Only grant decryption capabilities to systems/users that absolutely need them

✅ Protects log data at rest: Encrypted files on disk are unreadable without the private key ✅ Protects against unauthorized file access: Even with file system access, logs can't be read ✅ Tamper evidence within a session (v2 format, v6.0.0+): Frame order, session identity, and header metadata are bound into the AES-GCM authenticated data — dropped, reordered, duplicated, or spliced frames fail authentication, and truncation of a cleanly closed (sealed) log is detected via the authenticated end-of-log seal ✅ Supports compliance requirements: Helps meet data protection regulations (GDPR, HIPAA, etc.)

• ❌ In-memory data: Log data is unencrypted in application memory before encryption
• ❌ Transport encryption: Logs are encrypted on disk, but should still use secure transport (e.g., TLS) if sent over the network
• ❌ Key compromise: If an attacker obtains the private key, all logs can be decrypted
• ❌ Fabricated sessions: Encryption needs only the public key, which ships with the application; an attacker with the public key and file write access can append entirely fabricated sessions (they cannot alter or inject into existing sessions). Preventing this requires a secret the attacker lacks (an HMAC or producer-side signing key), which this library does not provide
• ❌ Deletion of entire sessions: Sessions are independently keyed and not chained together, so removing a whole session from a multi-session file is not detectable by the format
• ❌ Crash-vs-truncation ambiguity: A session with no end-of-log seal means the writer crashed or the tail was truncated — the two are byte-for-byte indistinguishable by design; the decryptor reports such sessions as unsealed rather than guessing
• ❌ Side-channel attacks: Physical access to the machine may enable advanced attacks
• ❌ Malicious code: Malware running with application privileges can potentially access log data before encryption

Attack Vectors Mitigated:

• Unauthorized access to backup drives
• Stolen or disposed hard drives
• Log file exposure through misconfigured file shares
• Compliance audits requiring encryption at rest

Out of Scope:

• Protection against privileged users on the host system
• Defense against memory dumping or process inspection
• Protection if the application itself is compromised

This library uses the .NET cryptographic libraries (System.Security.Cryptography) and relies on:

• RSA-OAEP-SHA256: For encrypting AES keys and nonce
• AES-256-GCM: For log content encryption; in the v2 format (v6.0.0+) each record additionally authenticates 41 bytes of associated data (SHA-256 of the session header + frame sequence + record type), and each cleanly closed session ends with an authenticated seal record carrying the final frame count
• SHA-256: For hashing the session header into the per-frame associated data

We monitor dependencies through:

• GitHub Dependabot (automated PRs for dependency updates)
• CodeQL analysis (static security scanning)
• Regular security audits of direct dependencies

When security updates are released:

1. We publish a GitHub Security Advisory
2. We release a new package version to NuGet
3. We update this SECURITY.md file with affected versions
4. We notify users through GitHub release notes

Subscribe to repository releases to stay informed about security updates.

• OWASP Cryptographic Storage Cheat Sheet
• .NET Cryptography Model
• Key Management Best Practices

Thank you for helping keep Serilog.Sinks.File.Encrypt and its users safe!