WFL is currently in alpha stage and should not be used in production environments. This alpha status means that security features are still being developed and hardened. Use WFL only for development, testing, and educational purposes.

We provide security updates for the following versions of WFL:

Version Scheme: WFL uses calendar-based versioning (YY.MM.BUILD). Security patches are released as point releases within the current month.

Supported Platforms: See Docs/reference/supported-platforms.md for the platform support tiers (what CI builds and tests), the toolchain/runtime requirements, and the boundaries of "supported" behaviour.

We take security vulnerabilities seriously and appreciate responsible disclosure from the security community.

Please DO NOT report security vulnerabilities through public GitHub issues.

Instead, please use one of these methods:

1. Preferred: GitHub Security Advisories (private reporting)
2. Email: Send details to info@logbie.com with subject line "WFL Security Vulnerability"
3. Alternative: Direct message to repository maintainers

Please include the following information in your report:

• Description: Clear description of the vulnerability
• Impact: Potential security impact and affected components
• Steps to Reproduce: Detailed reproduction steps
• WFL Version: Specific version where the issue was discovered
• Environment: Operating system, Rust version, and relevant configuration
• Proof of Concept: Sample WFL code or commands that demonstrate the issue
• Proposed Solution: If you have suggestions for fixing the issue

• Acknowledgment: We will acknowledge receipt of your report within 48 hours
• Initial Assessment: Initial severity assessment within 5 business days
• Status Updates: Regular updates on progress toward a fix
• Resolution: We aim to provide fixes for critical issues within 30 days
• Disclosure: Coordinated public disclosure after fix is available (typically 90 days)

All security fixes follow our Test-Driven Development (TDD) methodology:

1. Failing Test Creation: Security issue reproduction test written first
2. Implementation: Minimal fix developed to pass the test
3. Verification: All existing tests must continue passing
4. Review: Internal security review and testing
5. Release: Version bump and coordinated disclosure

• Critical Security Fixes: Emergency releases outside normal schedule
• High/Medium Priority: Included in next scheduled monthly release
• Low Priority: May be batched with feature releases

• GitHub Security Advisories
• Release notes with security section
• Email notification to registered users (when available)

WFL interprets and executes user-provided code. Consider these security implications:

File System Access:

• WFL programs can read/write files with user permissions
• Use appropriate file system permissions and sandboxing
• Consider running WFL in containerized environments for untrusted code

Network Operations:

• WFL supports HTTP requests and database connections
• Validate all network destinations and inputs
• Consider firewall rules and network isolation

System Integration:

• WFL can execute system operations through its standard library
• Review WFL programs before execution in sensitive environments
• Monitor resource usage (CPU, memory, network) during execution

Global Configuration (/etc/wfl/wfl.cfg or C:\wfl\config):

• Protect global config files with appropriate permissions (readable by WFL users only)
• Regularly review configuration settings
• Use environment variables for sensitive configuration when possible

Local Configuration (.wflcfg files):

• Keep project-specific configuration in version control
• Avoid storing credentials or sensitive data in configuration files
• Use secure defaults and validate all configuration values

Unsafe Code Usage:

• Limited unsafe Rust code in REPL functionality (src/repl.rs)
• Configuration environment manipulation (src/config.rs)
• These are audited and necessary for platform functionality

Dependencies:

• Regularly update Rust dependencies for security patches
• Monitor dependency security advisories
• Use cargo audit for vulnerability scanning

1. Source Code Review: Always review WFL code before execution
2. Sandboxing: Consider containerization or virtual machines for untrusted code
3. Resource Limits: Monitor CPU, memory, and network usage
4. File Permissions: Run with minimal necessary file system permissions
5. Network Restrictions: Use firewall rules to limit network access

1. Input Validation: Always validate external inputs in WFL programs
2. Error Handling: Use WFL's try/when error constructs properly
3. Secure Defaults: Follow principle of least privilege in your WFL applications
4. Testing: Include security testing in your WFL program test suites

# Example secure .wflcfg
timeout_seconds = 30          # Reasonable wall-clock timeout (ExecutionBudget)
logging_enabled = true        # Enable for audit trails
debug_report_enabled = false  # Disable in production-like environments
max_call_depth = 1000         # Runtime recursion/stack ceiling (ExecutionBudget)
max_nesting_depth = 5         # Linter: max block nesting for readability (style, not a runtime guard)

As alpha software, WFL has the following known limitations:

1. Execution Sandboxing: No built-in sandboxing for untrusted code execution
2. Resource Limits: A shared ExecutionBudget now enforces ceilings (recursion/import depth, pattern steps/states, source/body/response bytes, HTTP/WebSocket capacity, and optional operation/time limits). Adversarial per-limit boundary testing is still in progress (tracked as Phase 3 of #610).
3. Input Sanitization: Basic input validation - additional sanitization may be needed
4. Audit Logging: Security-focused audit logging still in development
5. Cryptographic Operations: WFL ships a crypto standard library (WFLHASH plus SHA-256/HMAC and password KDFs — argon2, bcrypt, scrypt, PBKDF2). WFLHASH is a custom, experimental primitive and must not be used where a standardized, independently audited hash is required.

• WFL Architecture - Understanding system components
• Error Handling - Secure error management
• Async Operations - Network security considerations

• Use cargo clippy for static analysis
• Run cargo audit for dependency vulnerability scanning
• Test programs available in TestPrograms/ directory
• Consider fuzzing WFL programs for robustness testing

• GitHub Discussions - Security questions and best practices
• Issue Tracker - Non-security bugs and feature requests
• GOVERNANCE.md - Project authority and contribution policies
• CODE_OF_CONDUCT.md - Community standards
• AI_POLICY.md - AI-assisted work is welcome

We appreciate the security research community and will acknowledge responsible disclosure contributors:

• Security researchers who report vulnerabilities through proper channels
• Contributors who improve WFL's security posture
• Community members who help identify and document security best practices

• General Security: info@logbie.com
• Emergency Security Issues: Use GitHub Security Advisories for fastest response
• Project Repository: https://github.com/WebFirstLanguage/wfl

Last Updated: August 2026 Version: 26.8.2

© 2026 Logbie LLC. This security policy is subject to updates as WFL evolves from alpha to stable release.