Security Policy

Relevant source files

The following files were used as context for generating this wiki page:

• SECURITY.md
• CONTRIBUTING.md
• CODE_OF_CONDUCT.md
• thirdparty/crates/zerocopy-0.8.48/agent_docs/reviewing.md
• openspec/changes/archive/spec-kit-old/002-replace-rng-currently/002-replace-rng-currently.md

The DeepCausality security policy defines the protocols for identifying, reporting, and resolving security vulnerabilities within the framework. It emphasizes a proactive approach to safety through strict coding standards, coordinated disclosure, and systematic review processes. The policy ensures that the framework maintains its integrity as a reliable tool for computational causality.

Vulnerability Reporting and Response

DeepCausality utilizes a coordinated disclosure model for security vulnerabilities. To protect the project and its users, vulnerabilities must never be reported through public channels such as GitHub issues, discussions, or pull requests.

Reporting Process

If a vulnerability is discovered, it must be sent directly to the active maintainer via email at marvin.hansen@gmail.com. Reports should include as much detail as possible to facilitate reproduction and resolution.
Sources: SECURITY.md:13-19, CONTRIBUTING.md:100-104

Response and Disclosure Timeline

The project team follows a specific lifecycle for vulnerability management:

• Response Time: Initial response to a reported vulnerability is targeted within 7 to 10 working days.
• Disclosure: Security vulnerabilities are publicly identified in the release notes only after they have been closed.
  Sources: SECURITY.md:21-25

The following diagram illustrates the vulnerability management lifecycle from discovery to public disclosure:

The flow shows the transition from private reporting to internal resolution and finally to public disclosure.
Sources: SECURITY.md:13-25, CONTRIBUTING.md:100-104

Security Auditing and Code Review

For internal development and third-party crate management, DeepCausality adopts a "Security Auditor" persona during code reviews. This process is designed to prevent undefined behavior (UB) and maintain safety invariants.

Security Auditor Checklist

Reviewers are mandated to focus on:

• Safety Invariants: Verifying unsafe blocks for compliance.
• Documentation: Ensuring every unsafe block has a // SAFETY: comment.
• Preconditions: Checking that unsafe functions, traits, and macros with safety preconditions have explicit /// # Safety documentation.
  Sources: thirdparty/crates/zerocopy-0.8.48/agent_docs/reviewing.md:30-41

Soundness Logic

The "Logic Detective" aspect of the security policy focuses on correctness and edge cases to prevent runtime panics or logic errors that could be exploited.
Sources: thirdparty/crates/zerocopy-0.8.48/agent_docs/reviewing.md:43-52

Focus Area	Responsibility	Goal
Undefined Behavior	Security Auditor	Verify unsafe invariants and compliance.
Edge Cases	Logic Detective	Prevent panics on valid input; handle Zero-Sized Types (ZSTs).
Soundness	Security Auditor	Validate that generic type transformations are sound.
Sources: thirdparty/crates/zerocopy-0.8.48/agent_docs/reviewing.md:30-52

Architectural Safety Constraints

DeepCausality enforces specific architectural constraints to minimize the security surface area of its components. A primary example is the replacement of external random number generators with internal, controlled implementations.

Internal Crate Requirements

When developing internal security-sensitive components like deep_causality_rand, the following constraints are mandatory:

• Zero External Dependencies: Only the Rust standard library (std) is allowed to reduce supply chain risks.
• Zero Unsafe Code: The code must not contain any unsafe blocks.
• Zero Macros: To ensure predictability and auditability, no macros are permitted.
  Sources: openspec/changes/archive/spec-kit-old/002-replace-rng-currently/002-replace-rng-currently.md:5-13

Randomness and Entropy

For applications requiring stronger, OS-backed security, the framework provides optionality:

• Default PRNG: Uses SipHash13 for general-purpose portability.
• OS-Backed Randomness: An opt-in os-random feature flag allows the use of the getrandom crate to leverage operating system entropy sources.
  Sources: openspec/changes/archive/spec-kit-old/002-replace-rng-currently/002-replace-rng-currently.md:47-53

Version Support

The security policy explicitly defines which versions of the framework are actively maintained for security patches.

Version	Support Status
0.3.x	Supported
0.2.x	Supported
< 0.2	Unsupported
Sources: SECURITY.md:7-11

Community and Conduct Security

Security within the project also extends to the work environment and the protection of participant privacy.

• Confidentiality: Participants must respect the privacy of others and the confidentiality of any data accessed.
• Unacceptable Behavior: Harassment, bullying, or discrimination is strictly prohibited and can result in removal from the project.
• Incident Procedure: To report incidents of conduct-related security issues, participants must email the active maintainer.
  Sources: CODE_OF_CONDUCT.md:37-44, CODE_OF_CONDUCT.md:113-118

The DeepCausality security policy integrates technical code auditing, strict architectural constraints for internal crates, and a disciplined disclosure process to ensure the framework remains resilient against vulnerabilities and misuse.