Security Practices And OSSF Compliance#

Security Practices and OSSF Compliance encompasses the comprehensive security framework implemented by the libmagic-rs project, a pure-Rust replacement for libmagic (the library behind the file command). The project has achieved OpenSSF Best Practices badge compliance (Project ID 11947) and implements a multi-layered security approach based on industry standards including NIST IR 7608, CWE/SANS Top 25, and OWASP guidelines.

The security framework consists of three primary pillars: memory safety through Rust's ownership model, enforced by workspace-level unsafe_code = "forbid"; automated vulnerability management via daily cargo audit and cargo deny checks; and supply chain security through Sigstore keyless signing, SLSA provenance attestations, and CycloneDX SBOM generation.

For confirmed vulnerabilities, the project commits to releasing fixes within 90 days, with private vulnerability reporting through GitHub Security Advisories or encrypted email to support@evilbitlabs.io. The project maintains formal threat modeling documentation that identifies trust boundaries, asset protection requirements, and countermeasures for 14 CWE categories and relevant OWASP vulnerabilities.

OSSF Best Practices Compliance#

Badge Certification#

The libmagic-rs project has earned the OpenSSF Best Practices badge (Project ID 11947), demonstrating compliance with industry-standard security practices for open-source software development. This certification validates the project's adherence to fundamental security principles including change control, quality assurance, vulnerability reporting, and secure development practices. The project also maintains an OpenSSF Scorecard that runs weekly to continuously monitor supply-chain security posture.

Scorecard Monitoring#

The OpenSSF Scorecard workflow executes automated security checks that evaluate the project against multiple security criteria. The workflow runs weekly on Wednesdays at 23:36 UTC and triggers on branch protection rule changes to ensure continuous compliance. Results are published to the OpenSSF REST API for public transparency and uploaded as SARIF results to the GitHub Security tab, providing visibility into the project's security posture.

Memory Safety Enforcement#

Workspace-Level Unsafe Code Prohibition#

The project enforces memory safety at the workspace level through Cargo.toml configuration:

[workspace.lints.rust]
# Security: Forbid unsafe code globally
unsafe_code = "forbid"

This prohibition represents a foundational security guarantee, eliminating entire categories of memory safety vulnerabilities by leveraging Rust's ownership and borrowing system. The restriction extends to all contribution requirements, requiring contributors to discuss any perceived need for unsafe code via GitHub issues before submission. The project's code review process explicitly verifies unsafe code absence in all pull requests.

Security-Focused Linting#

Beyond unsafe code prohibition, the project implements extensive security linting that enforces secure coding practices across multiple dimensions:

• Zero-warnings policy: warnings = "deny" ensures all compiler warnings are treated as errors
• Memory access protection: indexing_slicing = "warn" prevents unchecked buffer access
• Arithmetic safety: arithmetic_side_effects = "warn" catches potential overflow risks
• Production code guarantees: panic = "deny", unwrap_used = "deny", and expect_used = "warn" eliminate abrupt program termination
• Type conversion safety: as_conversions = "warn" and cast_ptr_alignment = "warn" prevent unsafe type coercions

Release Profile Security#

The dist profile includes overflow-checks = true to maintain integer overflow detection even in optimized production builds, ensuring that performance optimizations do not compromise security guarantees.

Vulnerability Reporting and Disclosure#

Reporting Channels#

The project implements responsible disclosure practices where security vulnerabilities must NOT be reported through public GitHub issues to prevent premature exposure. Two private reporting mechanisms are provided:

1. GitHub Private Vulnerability Reporting (preferred): Uses GitHub's Security Advisory framework for coordinated disclosure with built-in workflow management
2. Encrypted Email: support@evilbitlabs.io with PGP key F839 4B2C F0FE C451 1B11 E721 8F71 D62B F438 2BC0 for sensitive communications

Required Report Information#

Vulnerability reports should include comprehensive details to facilitate triage and remediation: a description of the vulnerability, steps to reproduce the issue, potential impact assessment, and suggested fixes if available. This structured approach enables maintainers to efficiently assess severity and develop appropriate mitigations.

Vulnerability Scope#

The project defines clear boundaries for security research. In-Scope Vulnerabilities include: buffer overflows or out-of-bounds reads in magic file parsing, denial of service via crafted magic or input files, path traversal in file input handling, command injection via CLI arguments, and unsafe code in dependencies affecting libmagic-rs.

Out-of-Scope vulnerabilities include issues in the original C libmagic implementation (which the project replaces rather than wraps), vulnerabilities requiring physical access to the machine, and social engineering attacks.

Fix Commitment Timeline#

As a volunteer-maintained passion project, the project provides best-effort response with clearly defined expectations: acknowledgment of receipt within 1 week, initial assessment within 2 weeks, and fix release within 90 days for confirmed vulnerabilities. Disclosure is coordinated through GitHub Security Advisories, with reporter credit in the advisory unless anonymity is preferred.

Safe Harbor Policy#

The project provides safe harbor protections for security researchers who make good-faith efforts to avoid privacy violations, data destruction, and service disruption. Maintainers will not pursue legal action against researchers following responsible disclosure practices, encouraging security community participation.

Automated Security Auditing#

Daily Dependency Vulnerability Scanning#

The project runs two complementary daily security workflows that provide comprehensive dependency monitoring:

cargo audit Workflow#

The cargo audit workflow runs daily at midnight UTC via cron schedule "0 0 * * *" and triggers on changes to Cargo.toml and Cargo.lock. It scans against the RustSec Advisory Database to identify known vulnerabilities in dependencies and automatically creates GitHub issues for discovered vulnerabilities, ensuring timely awareness and tracking.

cargo deny Workflow#

The cargo deny workflow runs daily at 6 AM UTC via cron schedule "0 6 * * *", triggers on pull requests to main, triggers after CI workflow completion, and enforces dependency policies from deny.toml. This provides multi-dimensional security checks including license compliance, dependency bans, advisory verification, and source validation.

Dependency Policy Enforcement#

The deny.toml configuration enforces strict security policies across four dimensions:

Advisory Checks: Denies yanked crates and tracks unmaintained dependencies to prevent use of abandoned or retracted packages.

License Compliance: Allows only approved open-source licenses including Apache-2.0, MIT, BSD-3-Clause, ISC, Unicode-DFS-2016, and Zlib, ensuring legal compliance and compatibility.

Dependency Bans: Blocks known insecure crates including openssl, openssl-sys, git2, and cmake, preferring safer alternatives. Additionally denies multiple versions of the same crate to prevent version confusion vulnerabilities.

Source Verification: Only allows the crates.io registry and denies unknown git sources, preventing supply chain attacks through untrusted repositories.

Additional Audit Tools#

The security workflow includes supplementary checks: cargo outdated checks that fail CI on outdated dependencies, encouraging timely updates, and cargo dist verification for distribution package integrity.

Threat Modeling and Security Assurance#

Formal Threat Model#

The project maintains a NIST IR 7608-compliant security assurance case that provides structured argumentation for security claims. This formal approach documents security requirements, identifies threat actors and attack vectors, maps countermeasures to industry-standard vulnerability classifications, and documents known limitations and residual risk.

Seven Security Requirements (SR-1 through SR-7) define the security objectives: no crashes or panics on any input, no buffer boundary violations, no path traversal via CLI, no arbitrary code execution, no unbounded resource consumption, and no information leakage between file evaluations.

Three Threat Actors are identified: malicious file authors who can craft arbitrary file contents, malicious magic file authors who can craft arbitrary rule syntax, and supply chain attackers who can compromise dependencies.

Seven Attack Vectors (AV-1 through AV-7) are documented: buffer over-reads, integer overflows, stack overflows, memory exhaustion, parser crashes, path traversal, and compromised dependencies.

Trust Boundaries#

The documentation includes a detailed ASCII diagram illustrating trust boundaries in the system architecture. All data crossing these boundaries—untrusted input files, magic files, and CLI arguments—undergoes validation through distinct components including the Parser, Evaluator, I/O Layer, and CLI interface, ensuring defense in depth.

Secure Design Principles#

The project applies all eight Saltzer and Schroeder principles for secure system design:

• Economy of mechanism: Pure Rust implementation with minimal dependencies, no plugin system or scripting
• Fail-safe defaults: Workspace-level unsafe_code = "forbid" enforcement and bounds-checked buffer access
• Complete mediation: Every buffer access, magic file, and CLI argument is validated
• Open design: Fully open source (Apache-2.0 license) with publicly documented security mechanisms
• Separation of privilege: Parser and evaluator are implemented as separate modules
• Least privilege: Read-only file access, no network access, no elevated permissions required
• Least common mechanism: No shared mutable state between file evaluations
• Psychological acceptability: Follows GNU file conventions with descriptive error messages

CWE/SANS Top 25 Countermeasures#

The project provides a comprehensive mapping table documenting countermeasures for 14 common weaknesses:

OWASP Top 10 Mapping#

The OWASP mapping covers applicable categories from the web application security framework adapted for file processing: A03 (Injection) mitigated through strict grammar-based parser design, A04 (Insecure Design) addressed through formal application of security design principles, A06 (Vulnerable Components) managed via daily cargo audit/deny checks and Dependabot automation, and A09 (Security Logging) implemented through evaluation error logging and security event disclosure via GitHub Advisories.

Known Limitations and Residual Risk#

Section 7 of security-assurance.md documents two acknowledged security limitations:

Default Configuration Has No Timeout: EvaluationConfig::default() sets timeout_ms: None, allowing evaluation to run indefinitely. While other bounds (recursion depth, string length, resource combination) prevent stack overflow and unbounded memory growth, they do not limit CPU time. Callers processing untrusted input should use EvaluationConfig::performance() (which sets a 1-second timeout) or set timeout_ms explicitly via --timeout-ms in the CLI.

TOCTOU Window in evaluate_file: MagicDatabase::evaluate_file has a time-of-check/time-of-use window (CWE-367) between path validation and memory mapping. Between metadata validation and mapping, the path may be swapped by another process, resulting in incorrect classification. The I/O layer mitigates common attacks through path canonicalization and file type checks, and mappings are always read-only. Callers in adversarial environments should open files themselves with TOCTOU-aware I/O strategies and pass bytes to evaluate_buffer instead.

Pull Request Security Requirements#

Developer Certificate of Origin#

All commits must be signed off with the Developer Certificate of Origin (DCO), which is enforced by a GitHub App. Contributors use the -s flag when committing:

git commit -s -m "feat: add new feature"

This appends Signed-off-by: Your Name <your.email@example.com> to the commit message, certifying that contributors have the legal right to submit code under the project's license and agree to the Developer Certificate of Origin terms.

Code Quality Gates#

Before PR submission, contributors must ensure that four quality gates pass: all tests pass via cargo test, no clippy warnings via cargo clippy -- -D warnings, code is formatted via cargo fmt, and documentation builds successfully via cargo doc --no-deps.

Required Testing#

All changes must include comprehensive testing, including running the full test suite via cargo test, adding tests for new functionality, testing both success and error cases, and including doc tests for public API examples. This ensures that new code is thoroughly validated and maintains project quality standards.

Code Review Safety Checks#

Reviewers verify critical security properties during code review: no unsafe code is introduced, proper bounds checking is implemented, no panics exist in library code, and security audit tools plus CodeQL analysis pass successfully. This multi-layered review process provides human oversight beyond automated checks.

CI Enforcement#

CI must pass before merge, enforced by branch protection rules on the main branch. The ci.yml workflow includes global permissions: contents: read for least-privilege enforcement and per-job timeout limits to prevent unbounded resource consumption. The just ci-check command provides local CI parity:

ci-check: pre-commit-run fmt-check lint-rust lint-rust-min test-ci build-release audit coverage-check dist-plan

This comprehensive check includes nine distinct stages: pre-commit hooks for formatting and linting, format verification via cargo fmt --all --check, full-feature linting via cargo clippy --all-features -- -D warnings, minimal-feature linting via cargo clippy --no-default-features, test suite execution via cargo nextest run, release build verification, security audit via cargo audit, 85% code coverage threshold enforcement, and distribution planning via cargo dist plan.

Supply Chain Security#

Build Provenance and Attestation#

The project implements keyless signing with Sigstore via GitHub Attestations for all release artifacts, providing cryptographic proof of build authenticity. The process consists of three steps: cargo-dist builds artifacts in GitHub Actions, actions/attest-build-provenance v4 (a wrapper around actions/attest) generates signed SLSA provenance attestations, and attestations are stored in GitHub's attestation ledger and Sigstore's transparency log.

Keyless signing eliminates the risk of compromised long-lived private keys, as each build receives an ephemeral signing certificate tied to the GitHub Actions workflow identity, which is then recorded in the public Sigstore transparency log for auditability.

Artifact Verification#

Users can verify artifacts using the GitHub CLI:

gh release download v0.1.0 --repo EvilBit-Labs/libmagic-rs
gh attestation verify rmagic-x86_64-unknown-linux-gnu.tar.xz \
  --repo EvilBit-Labs/libmagic-rs

Successful verification confirms three key properties: authenticity (the artifact was built by the official GitHub Actions workflow), integrity (the artifact has not been modified since it was built), and provenance (the build was triggered by a specific commit and tag in the repository).

Software Bill of Materials (SBOM)#

Each release includes a CycloneDX SBOM generated by cargo-cyclonedx, providing a comprehensive inventory of all dependencies and their versions. This machine-readable bill of materials enables automated vulnerability tracking, license compliance verification, and supply chain risk assessment by downstream consumers.

Embedded Dependency Metadata#

Release binaries are built with cargo-auditable, which embeds dependency metadata directly into the binary:

cargo audit bin rmagic

This enables post-deployment vulnerability scanning against the RustSec Advisory Database, allowing security teams to audit deployed binaries without requiring access to build-time dependency information.

Reproducible Builds#

The project ensures reproducible builds through deterministic build configuration: pinned Rust toolchain (1.91.0) specified in rust-toolchain.toml, committed Cargo.lock and mise.lock files that pin all dependency versions, and SHA-pinned GitHub Actions that ensure consistent CI/CD behavior. These measures enable independent verification that distributed binaries match the source code.

Supply Chain Security Measures#

The documented supply chain controls implement defense in depth through seven complementary mechanisms: daily cargo audit and cargo deny execution in CI, Dependabot for automated dependency updates, Sigstore attestations via GitHub Actions, CycloneDX SBOM generation per release, cargo-auditable for embedded dependency metadata, SHA-pinned GitHub Actions such as actions/checkout@de0fac2e..., and required PR code reviews with automated security checks.

Automated Dependency Updates#

Dependabot is configured to run weekly for Cargo dependencies and GitHub Actions, automatically creating pull requests for available updates. This ensures that security patches and dependency updates are promptly integrated while maintaining the testing and review requirements for all changes.

Release Security Requirements#

Release Verification Process#

All releases must satisfy multiple security requirements documented in the release verification guide. This includes human-readable release notes generated via git-cliff for changelog transparency, unique SemVer tags for version identification, and reproducible builds using a pinned toolchain, committed lock files, and cargo-dist for consistent distribution.

Homebrew Distribution Security#

Homebrew formula installations from the EvilBit-Labs/homebrew-tap are verified through Homebrew's standard SHA256 checksum mechanism, with checksums populated automatically from the GitHub Release artifacts, providing integrity verification for macOS and Linux users installing via Homebrew.

Continuous Security Assurance#

Living Documentation#

The security assurance document is maintained as living documentation that evolves with the project. Updates occur when new features are added, threats are discovered, dependencies change, or security incidents occur, ensuring that the security documentation accurately reflects the current state of the system.

Automated CI Checks#

Continuous assurance is provided through automated checks on every commit: Clippy linting for code quality and potential bugs, CodeQL analysis for security vulnerabilities, cargo audit for dependency vulnerability scanning, and cargo deny for dependency policy enforcement. This continuous monitoring ensures that security regressions are detected immediately.

Multi-Schedule Security Workflows#

The project orchestrates security checks across multiple time schedules to optimize coverage while managing computational resources: Daily at midnight UTC runs cargo audit for vulnerability scanning, Daily at 6 AM UTC executes cargo deny and cargo outdated for policy enforcement, Weekly on Wednesday at 23:36 UTC runs OpenSSF Scorecard for supply chain assessment, and Weekly Dependabot processes dependency updates.

Relevant Code Files#

Related Topics#

• Memory Safety In Rust: Rust's ownership and borrowing system as foundational security mechanism
• SLSA Framework: Supply-chain Levels for Software Artifacts compliance
• OpenSSF Scorecard: Automated supply-chain security posture assessment
• Developer Certificate of Origin (DCO): Contributor legal compliance framework
• CWE/SANS Top 25: Common software weaknesses and countermeasures
• OWASP Top 10: Web application security risks applicable to file processing
• RustSec Advisory Database: Rust-specific vulnerability tracking and disclosure
• Sigstore: Keyless code signing and transparency log infrastructure
• CycloneDX SBOM: Software bill of materials standard for dependency transparency
• cargo-audit: Rust dependency vulnerability scanner
• cargo-deny: Rust dependency policy enforcement tool