Security Policies & Vulnerability Scanning

Relevant source files

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

• SECURITY.md
• copilot-instructions.md
• GAD.md
• infrastructure_planning/milestone_25_tasks.md
• infrastructure_planning/milestone_0_tasks.md
• CHANGELOG.md

Introduction

The NeuralDBG project implements a "Security First" approach, where security considerations are integrated directly into the development lifecycle through automated scanning, strict data handling policies, and mandatory vulnerability reporting protocols. The primary goal is to protect sensitive research data, including model parameters, weights, and training tensors, while ensuring the integrity of the causal inference engine.

Security is governed by a set of non-negotiable rules (Rule 6) that mandate the use of language-specific scanners and policy-as-code implementations. These measures ensure that every contribution is audited for common vulnerabilities, hardcoded secrets, and dependency risks before being merged into the codebase.
Sources: GAD.md:58-69, SECURITY.md:25-30, copilot-instructions.md:104-121

Core Security Policies

NeuralDBG maintains a strict security stance categorized into data handling, environmental isolation, and proactive scanning.

Data Handling and Privacy

Because NeuralDBG captures deep learning training dynamics, it interacts with potentially proprietary information. The project enforces several privacy considerations:

• Sensitive Data Capture: Monitoring includes model parameters, weights, training tensors, gradients, and hyperparameters.
• Cleanup Protocols: Users are required to clear debug sessions after use to prevent accidental exposure of captured traces.
• Sanitization: Users are advised to avoid debugging with sensitive or proprietary data when possible.
  Sources: SECURITY.md:25-45

Mandatory Security Rules

The project utilizes "Global AI Rules" to enforce security standards:

• Rule 6 (Security Hardening): Mandates that secrets (API keys, tokens) must never be logged or committed. Environment variables must be used for all secrets.
• Input Sanitization: All user inputs must be validated to prevent injection and path traversal attacks.
• Policy as Code: Governance is automated through CI/CD gates to ensure compliance.
  Sources: copilot-instructions.md:104-111, GAD.md:58-69

Automated Vulnerability Scanning

NeuralDBG employs a multi-layered scanning architecture that operates during local development and within the CI/CD pipeline.

Scanner Integration

The project requires specific tools based on the implementation language to perform static analysis and dependency auditing:

Language	Tool	Command/Action
Python	bandit	bandit -r . (Static Analysis)
Python	safety	safety check (Dependency Audit)
Rust	cargo audit	Audit dependencies for vulnerabilities
Node.js	npm audit	Audit package dependencies
Sources: copilot-instructions.md:112-116, GAD.md:65-67

CI/CD Security Gates

Security scans are implemented as "Unbreakable Digital Bouncers" in the cloud infrastructure. The CI/CD pipeline is configured to reject any push that fails security audits.

The diagram shows the logic of the Cloud CI/CD workflow where security scans act as mandatory validation gates before code can be merged.
Sources: infrastructure_planning/milestone_0_tasks.md:24-42, CHANGELOG.md:15-20

Vulnerability Management

Vulnerabilities are managed through a structured classification system and a private reporting protocol.

Reporting Process

NeuralDBG prohibits reporting security issues through public GitHub issues to prevent zero-day exploitation.

1. Contact: Reports must be sent to Lemniscate_zero@proton.me.
2. Required Info: Description, reproduction steps, impact assessment, and suggested mitigations.
3. Timeline: Acknowledgement within 48 hours; detailed response/plan within 7 days.
   Sources: SECURITY.md:10-23

Severity Classification

Vulnerabilities are ranked to prioritize remediation efforts:

• Critical: Immediate threat to user data or system security.
• High: Significant risk with potential for exploitation.
• Medium: Weakness with limited exploitation potential.
• Low: Minor hardening opportunities.
  Sources: SECURITY.md:60-65

Infrastructure and Implementation Tasks

The following infrastructure tasks have been defined to automate security enforcement across the repository.

Task ID	Description	ROI Estimation
MLO-4	Automated CI Pipeline running pytest, bandit, and safety.	Saves 2 hours/week of manual verification.
MLO-9	Pre-commit hook enforcement (includes bandit).	Prevents 90% of basic security regressions.
MLO-13	Safety Check Integration to block high-severity dependency vulnerabilities.	Critical security compliance for Rule 6.
MLO-10	Formal Security Policy Documentation (SECURITY.md).	Essential for professional standards.
Sources: infrastructure_planning/milestone_25_tasks.md:10-25, infrastructure_planning/milestone_50_tasks.md:30-35

Conclusion

Security in NeuralDBG is not a post-process but a fundamental constraint of the architecture. By combining strict data handling policies with automated "videur de sécurité" (security bouncers) in the CI/CD pipeline, the project ensures that its causal inference capabilities do not come at the cost of research data integrity or system safety. Continuous scanning via bandit and safety remains the primary defense against implementation-level vulnerabilities.
Sources: GAD.md:10-15, infrastructure_planning/milestone_0_tasks_fr.md:20-30