We provide security updates for the following versions:

Please do not report security vulnerabilities through public GitHub issues.

Instead, please report them via one of the following methods:

1. Email: Send details to security@theedgeworks.ai
2. Linear Issue: Create a private security issue in the Linear project (if you have access)
3. Direct Contact: Contact the maintainers directly if you have their contact information

When reporting a vulnerability, please include:

• Description: Clear description of the vulnerability
• Impact: Potential impact and affected components
• Steps to Reproduce: Detailed steps to reproduce the issue
• Suggested Fix: If you have ideas for a fix, please share them
• Affected Versions: Which SDK versions are affected

• Initial Response: Within 48 hours
• Status Update: Within 7 days
• Resolution: Depends on severity and complexity

• ServiceAccount Identity: Always use Kubernetes ServiceAccounts with proper RBAC
• mTLS: Use mutual TLS for all communication with the Event Journal
• No Shared Credentials: Each adapter should have its own identity and credentials
• Principle of Least Privilege: Grant only the minimum permissions required

• Local Communication: Prefer local Unix sockets or localhost connections when possible
• TLS Everywhere: Use TLS for all network communication
• Certificate Validation: Always validate server certificates; never disable certificate verification

• Dependency Updates: Keep SDK dependencies up to date
• No Hardcoded Secrets: Never commit secrets, API keys, or credentials to version control
• Input Validation: Validate all inputs from external sources
• Error Handling: Avoid exposing sensitive information in error messages

• Read-Only Filesystem: Run adapters with read-only filesystem when possible
• Non-Root User: Run adapters as non-root user
• Resource Limits: Set appropriate CPU and memory limits
• Network Policies: Use Kubernetes NetworkPolicies to restrict network access

• No hardcoded secrets or credentials
• Input validation for all user-provided data
• Proper error handling without information leakage
• Secure defaults (fail-secure, not fail-open)
• No unsafe operations (e.g., eval(), shell injection risks)
• Dependencies are up to date and from trusted sources
• No broker publishing code (architectural constraint)

• Vulnerability Scanning: Regularly scan dependencies for known vulnerabilities
• Minimal Dependencies: Only include necessary dependencies
• Trusted Sources: Use dependencies from trusted package repositories
• Version Pinning: Pin dependency versions in production builds

• Input Sanitization: Sanitize all inputs, especially from external sources
• Output Encoding: Properly encode outputs to prevent injection attacks
• Memory Safety: Be aware of memory safety issues (especially in Go/C bindings)
• Concurrency Safety: Ensure thread-safe operations in concurrent code
• Resource Limits: Implement timeouts and resource limits for all I/O operations

The SDK communicates with the Event Journal using:

• mTLS: Mutual TLS authentication for both client and server verification
• ServiceAccount Identity: Kubernetes ServiceAccount provides identity
• Unix Sockets: Local communication via Unix domain sockets when available
• Certificate Validation: Strict certificate validation with no insecure fallbacks

• Adapter Identity: Each adapter has a unique adapter_id enforced by the Journal
• Device Identity: Each device has a unique device_id scoped to the adapter
• No Shared State: Adapters cannot access each other's events or credentials

• Encryption in Transit: All network communication is encrypted via TLS
• Encryption at Rest: Event Journal handles encryption at rest (outside SDK scope)
• No Data Buffering: SDK minimizes data buffering to reduce exposure surface
• Secure Deletion: Follow platform guidelines for secure data deletion

The SDK is designed with a narrow security scope:

• No Authentication: The SDK does not implement authentication; it relies on the platform (mTLS, ServiceAccounts)
• No Authorization: Authorization is enforced by the Event Journal, not the SDK
• No Encryption: Encryption is handled by the transport layer (TLS) and storage layer
• No Secret Management: Secret management is handled by Kubernetes Secrets or external systems

The SDK is designed to protect against:

• ✅ Data Loss: Events are durably persisted before acceptance
• ✅ Data Corruption: Idempotency keys prevent duplicate events
• ✅ Backpressure Bypass: Explicit backpressure signals prevent silent drops
• ✅ Broker Publishing: Architectural constraint prevents unauthorized publishing

The SDK does not protect against:

• ❌ Platform Compromise: If the Event Journal is compromised, the SDK cannot protect data
• ❌ Adapter Compromise: If an adapter is compromised, it can append malicious events
• ❌ Network Attacks: Network-level attacks are mitigated by TLS and platform security

Security updates will be:

1. Disclosed: After a fix is available and tested
2. Prioritized: Based on severity (Critical, High, Medium, Low)
3. Documented: In release notes and security advisories
4. Backported: To supported versions when feasible

For security-related questions or to report vulnerabilities:

• Email: security@theedgeworks.ai
• Response Time: We aim to respond within 48 hours

Thank you for helping keep EdgeWorks Adapter SDK secure!