Add SECURITY.md and document log injection limitations

[thatsjet]

Summary

A security library needs a SECURITY.md for vulnerability disclosure and should document its own security limitations. Currently neither exists.

Instructions

1. Create SECURITY.md in repo root

Include:

• Reporting vulnerabilities: How to report (email or GitHub Security Advisories)
• Scope: What counts as a vulnerability in this library
• Response timeline: Expected response time
• Known limitations: See below

2. Document log injection limitations

The library currently has these security considerations that should be documented:

Log injection: All 4 implementations accept arbitrary parameter values and place them directly into log entries with no sanitization. A parameter like "user\n{\"event\":\"malicious_sqli\"}" could cause log injection in text-based log consumers. The OWASP Logging Cheat Sheet (which this library implements) specifically warns about this.

Arbitrary field passthrough: Python accepts **kwargs, Node.js passes through unknown options keys, Go/Java accept arbitrary map entries — all allow injecting or overwriting fields in the log entry.

YAML deserialization: Python uses yaml.safe_load (safe). Node.js uses yaml.load which is safe by default in js-yaml v4+ but worth noting.

Suggested SECURITY.md template

# Security Policy

## Reporting a Vulnerability

If you discover a security vulnerability in this library, please report it via
[GitHub Security Advisories](https://github.com/thatsjet/security_event_logger/security/advisories/new).

Do **not** open a public GitHub issue for security vulnerabilities.

## Response Timeline

- **Acknowledgment:** Within 48 hours
- **Initial assessment:** Within 1 week
- **Fix or mitigation:** Best effort, typically within 30 days

## Known Limitations

### Log Injection
This library does NOT sanitize event parameters before including them in log entries.
Applications consuming these log events via text-based log pipelines should sanitize
parameter values before passing them to this library, or use structured logging
(JSON) to avoid log injection attacks.

### Field Passthrough
Custom fields passed via options/kwargs are included in the log entry without
validation. Callers should not pass untrusted input as custom field names.

## Scope

The following are in-scope for security reports:
- Vulnerabilities in the library code itself
- Unsafe deserialization of the YAML event definitions
- Issues that could lead to denial of service

The following are out-of-scope:
- Log injection via unsanitized parameters (documented limitation)
- Vulnerabilities in dependencies (report upstream)

Verification

• SECURITY.md exists in repo root
• Documents all 3 known limitations (log injection, field passthrough, YAML deserialization)
• Provides clear reporting instructions