Skip to content

Security: paiml/pforge

Security

SECURITY.md

pforge Security Policy

Last Updated: 2025-10-03 Version: 0.1.0 Status: Production-Ready Security Posture

Executive Summary

pforge maintains a strong security posture with zero critical vulnerabilities, minimal unsafe code (FFI only), and continuous security monitoring via cargo-audit integration in CI/CD.

Security Metrics

Metric Status Details
Critical Vulnerabilities ✅ 0 Zero critical or high-severity issues
Unsafe Code Blocks ✅ Minimal 6 blocks (FFI only, documented)
Dependency Audits ✅ Passing Automated cargo-audit in CI/CD
Memory Safety ✅ Rust guarantees No unsafe code in core runtime
Input Validation ✅ Comprehensive All YAML/JSON inputs validated
Error Handling ✅ No panics All errors use Result<T, E>

Security Audit Results

Latest Audit: 2025-10-03

Command: cargo audit Vulnerabilities Found: 0 critical, 2 low-severity warnings Status: ✅ PASS

Fixed Vulnerabilities

  1. RUSTSEC-2025-0068 - serde_yml unsound and unmaintained

    • Severity: High (Unsound)
    • Impact: Potential memory safety issues in YAML parsing
    • Fix: Migrated to maintained serde_yaml (0.9) - FIXED ✅
    • PR/Commit: 66e1606

  2. RUSTSEC-2025-0067 - libyml::yaml_string_extend unsound

    • Severity: High (Unsound)
    • Impact: Transitive dependency from serde_yml
    • Fix: Removed by migrating to serde_yaml - FIXED ✅

Remaining Low-Severity Warnings

  1. RUSTSEC-2025-0057 - fxhash unmaintained

    • Severity: Low (Unmaintained)
    • Source: Transitive dependency via sled (state backend)
    • Impact: No known vulnerabilities, just unmaintained
    • Mitigation: Monitoring for alternatives, considering migration to rustc-hash (already in use)
    • Status: ⚠️ Accepted risk (low priority)

  2. RUSTSEC-2024-0384 - instant unmaintained

    • Severity: Low (Unmaintained)
    • Source: Transitive dependency via sled -> parking_lot
    • Impact: No known vulnerabilities
    • Mitigation: Waiting for sled ecosystem update
    • Status: ⚠️ Accepted risk (low priority)

Unsafe Code Analysis

Policy

Zero Tolerance: No unsafe code in production runtime except FFI boundaries.

Unsafe Code Inventory

All unsafe code is confined to pforge-bridge for FFI interop:

File: crates/pforge-bridge/src/lib.rs

Line Function Justification Safety Documentation
37 pforge_execute_handler FFI entry point, must handle C pointers ✅ Documented with # Safety
105 pforge_free_result FFI memory deallocation ✅ Documented with # Safety
119 pforge_version FFI string return ✅ Documented with # Safety
140 Test: test_execute_handler FFI test setup ✅ Test-only
150 Test: test_free_result FFI test cleanup ✅ Test-only
160 Test: test_version FFI test ✅ Test-only

Total: 6 unsafe blocks (3 production, 3 tests)

Safety Guarantees

  1. Null Pointer Checks: All FFI functions validate pointer arguments before dereferencing
  2. UTF-8 Validation: CStr conversions are validated and error-handled
  3. Memory Ownership: Clear ownership transfer documented (caller frees via pforge_free_result)
  4. Double-Free Prevention: std::mem::forget used to transfer ownership properly
  5. Static Lifetime: Version string uses compile-time constant

Security Hardening Measures

1. Dependency Management

  • cargo-audit integrated into CI/CD pipeline (.github/workflows/ci.yml)
  • Pre-commit hook runs security audit locally
  • Automated alerts for new vulnerabilities
  • Monthly review of dependency updates

2. Input Validation

YAML Configuration Parsing:

  • Strict schema validation via pforge-config::validator
  • Reject malformed YAML early (parse errors)
  • Validate handler paths, tool names, parameter types
  • No arbitrary code execution from config

JSON Request/Response:

  • All JSON validated against schemars schemas
  • Type-safe deserialization via serde
  • Graceful error handling (no panics)

3. Error Handling

Zero Panic Policy:

  • No unwrap() in production code (enforced by PMAT quality gates)
  • No panic!() in production code
  • All errors propagated via Result<T, E> with thiserror
  • FFI boundary converts panics to error codes

4. Memory Safety

Rust Guarantees:

  • Borrow checker enforces memory safety in all non-unsafe code
  • No buffer overflows, no use-after-free, no data races
  • FFI boundary carefully managed with documented safety invariants

Testing:

  • Property-based tests verify invariants (12 properties, 10K+ cases each)
  • Mutation testing validates error handling (77% kill rate, targeting 90%+)
  • Integration tests cover all code paths

5. Concurrency Safety

  • Arc<RwLock> for thread-safe handler registry
  • Tokio runtime for async concurrency (battle-tested)
  • No unsafe send/sync impls
  • Property tests verify concurrent dispatch

Reporting Security Vulnerabilities

Responsible Disclosure

If you discover a security vulnerability in pforge, please report it responsibly:

  1. DO NOT open a public GitHub issue
  2. Email: security@paiml.com
  3. Include:
    • Description of vulnerability
    • Steps to reproduce
    • Potential impact
    • Suggested fix (optional)

Response Timeline

  • Acknowledgment: Within 24 hours
  • Initial assessment: Within 72 hours
  • Fix timeline: Based on severity
    • Critical: 7 days
    • High: 14 days
    • Medium: 30 days
    • Low: Next release

Security Advisories

Published via:

  • GitHub Security Advisories
  • RustSec Advisory Database
  • crates.io security notices

Security Best Practices for Users

1. Configuration Security

YAML Configuration Files:

  • Store in version control (no secrets)
  • Use environment variables for sensitive data
  • Validate before deployment: pforge validate config.yaml

Handler Paths:

  • Only reference trusted Rust modules
  • No dynamic code loading from untrusted sources

2. CLI Handler Security

Command Injection Prevention:

  • All CLI commands validated and sanitized
  • No shell expansion of user input
  • Use safe subprocess execution (tokio::process)

Recommendations:

  • Whitelist allowed commands
  • Validate all arguments
  • Run with minimal privileges

3. HTTP Handler Security

Network Security:

  • Use HTTPS for external APIs
  • Validate TLS certificates (no danger_accept_invalid_certs)
  • Set appropriate timeouts

Authentication:

  • Store API keys in environment variables
  • Use short-lived tokens when possible
  • Rotate credentials regularly

4. State Management Security

Sled Database:

  • Store state files with appropriate permissions (0600)
  • Encrypt sensitive data at rest
  • Regular backups

5. Deployment Security

Production Checklist:

  • Run cargo audit before deployment
  • Use release builds (optimizations + stripping)
  • Set resource limits (memory, CPU)
  • Configure logging (no sensitive data)
  • Enable TLS for network transports (SSE, WebSocket)
  • Run with least privilege (non-root user)
  • Monitor for crashes and anomalies

Security Testing

Continuous Security Testing

Pre-commit Hooks:

  • cargo audit - Dependency vulnerability scan
  • cargo clippy - Security lints enabled
  • cargo test - All security tests must pass

CI/CD Pipeline:

  • Full test suite (130+ tests)
  • Property-based tests (12 properties, 120K+ test cases)
  • Mutation testing (77% kill rate)
  • Coverage requirements (≥80%)

Manual Security Reviews

Quarterly Reviews:

  • Dependency updates
  • Unsafe code audit
  • New vulnerability research
  • Penetration testing (planned for v1.0)

Compliance

Standards Alignment

  • OWASP Top 10: Addressed (see mapping below)
  • CWE/SANS Top 25: No violations
  • Rust Security Guidelines: Full compliance

OWASP Top 10 Mapping

OWASP Risk pforge Mitigation
A01 - Broken Access Control No authentication in framework (delegated to handlers)
A02 - Cryptographic Failures No crypto in core (delegated to HTTPS/TLS)
A03 - Injection Input validation, no shell execution, parameterized queries
A04 - Insecure Design Secure by default, fail-safe defaults
A05 - Security Misconfiguration Minimal config, validated inputs
A06 - Vulnerable Components cargo-audit, automated updates
A07 - Auth Failures N/A (no built-in auth)
A08 - Data Integrity Input validation, type safety
A09 - Security Logging Structured logging available
A10 - SSRF URL validation in HTTP handlers

Changelog

2025-10-03 (v0.1.0)

  • ✅ Fixed RUSTSEC-2025-0068 - Migrated from serde_yml to serde_yaml
  • ✅ Fixed RUSTSEC-2025-0067 - Removed libyml transitive dependency
  • ✅ Security hardening complete - All critical issues resolved
  • ✅ Documented unsafe code - All 6 blocks inventoried and justified
  • ✅ Created SECURITY.md - Comprehensive security documentation
  • ✅ CI/CD integration - Automated security testing

Previous

  • 2025-10-02: Mutation testing integration (77% kill rate)
  • 2025-10-01: Property-based testing (12 properties, 10K+ cases)
  • 2025-09-30: PMAT quality gates integration

Contact

This security policy is reviewed and updated quarterly.

There aren’t any published security advisories