1. Security Overview
2. Security Principles
3. Supported Versions
4. Reporting Vulnerabilities
5. Security Response Targets
6. Responsible Disclosure
7. Threat Model
8. Attack Surface Overview
9. Secure Model Serialization
10. Untrusted Model Files
11. Data and Configuration Security
12. Privacy, Network and Telemetry
13. CUDA and Native Code Security
14. Dependency Security
15. Authentication and Credentials
16. Repository Security
17. Secure Coding Standards
18. Security Testing
19. CI/CD and Release Security
20. Vulnerability Classification
21. Incident Response
22. Security Fix Verification
23. Security Advisories
24. Researcher Recognition
25. Security Responsibilities
26. Security Checklist
27. Official References
28. Next Steps

EveryO is an open-source neural computing framework designed to operate locally without mandatory external services.

Its core security design emphasizes:

• No required credentials.
• No network requests from the core library.
• No built-in usage telemetry.
• Pickle-free model serialization.
• Optional native CUDA acceleration.
• Minimal core dependencies.

These design choices reduce certain attack surfaces but do not eliminate software vulnerabilities.

This policy covers EveryO's own source code, serialization, input processing, configuration handling, optional native extension, and release practices.

It does not guarantee that every application built using EveryO is secure.

Avoid adding unnecessary:

• Network access.
• Authentication systems.
• Privileged operations.
• External services.
• Native extensions.
• Dynamic code execution.

Security should be considered during architecture and implementation, not only after a vulnerability is discovered.

External model files, datasets, configurations, and dependencies should be treated according to their trust level.

Development and release systems should receive only the permissions needed for their tasks.

Do not claim that a component is secure merely because it uses a familiar technology.

Security properties must be supported by design, testing, and appropriate review.

The current repository security policy lists:

The existing policy also states that security fixes land on the latest release.

Users should check the current official policy and release information before relying on version-support claims.

Security reports must be submitted privately.

Report a Vulnerability — EveryO

Navigate to:

EveryO Repository
        |
        v
Security
        |
        v
Report a vulnerability
        |
        v
Private Security Report

The official policy permits opening a public issue containing only a request for a private contact channel.

Do not include:

• Vulnerability details.
• Reproduction steps.
• Exploit code.
• Sensitive logs.
• Affected private data.

A maintainer can then arrange private communication.

EveryO does not currently publish a dedicated security email address.

Do not assume an unverified email address is an official security contact.

A useful report should include:

1. Affected EveryO version.
2. Python version.
3. Operating system.
4. Affected component.
5. Minimal reproduction.
6. Security impact.
7. Preconditions.
8. Suggested remediation, if available.

• Arbitrary code execution.
• Unauthorized data transmission.
• Memory corruption.
• Unsafe model loading.
• Configuration-based code execution.

The official SECURITY.md publishes the following targets:

These are best-effort targets, not a contractual service-level agreement.

EveryO is maintained as a volunteer open-source project.

Private Report
      |
      v
Acknowledgement
      |
      v
Initial Assessment
      |
      v
Reproduction
      |
      v
Impact Evaluation
      |
      v
Fix or Mitigation Plan
      |
      v
Patch Development
      |
      v
Security Verification
      |
      v
Coordinated Disclosure

The official policy commits to keeping researchers updated and avoiding an open-ended disclosure embargo.

Responsible disclosure gives maintainers an opportunity to investigate and correct a vulnerability before public release of exploit details.

Researchers should:

• Report privately.
• Minimize unnecessary data access.
• Avoid disrupting unrelated systems.
• Avoid exposing private information.
• Provide clear technical evidence.
• Allow a reasonable remediation period.

Maintainers should:

• Acknowledge reports.
• Assess impact.
• Communicate progress.
• Develop a proportionate response.
• Coordinate disclosure.
• Credit researchers unless anonymity is requested.

Public advisories should explain the vulnerability and mitigation without unnecessarily exposing sensitive information before affected users can respond.

A threat model identifies assets, possible adversaries, attack surfaces, and trust boundaries.

EveryO-related assets may include:

• Local datasets.
• Model parameters.
• Training outputs.
• Configuration files.
• Application files.
• Host memory.
• User environment integrity.

Potential attackers may control:

• A downloaded model archive.
• Untrusted input data.
• A configuration file.
• A compromised dependency.
• A malicious package artifact.

     External / Untrusted Sources
                |
      +---------+---------+
      |         |         |
      v         v         v
   Models     Data     Configurations
      |         |         |
      +---------+---------+
                |
                v
         Validation Layer
                |
                v
        EveryO Core Runtime
                |
         +------+------+
         |             |
         v             v
     NumPy CPU     Optional CUDA
         |             |
         +------+------+
                |
                v
          Host Resources

Untrusted input must not be allowed to cross into code execution or unsafe memory access through vulnerabilities in EveryO.

This is a threat-model summary, not a claim that every potential vulnerability has been eliminated.

EveryO uses a custom .evo model archive.

model.evo
│
├── manifest.json
│
└── parameters.npz

manifest.json contains structured model metadata and architecture information.

parameters.npz stores numerical arrays.

The loader uses:

np.load(..., allow_pickle=False)

This prevents NumPy from loading pickled Python objects through that mechanism.

EveryO reconstructs models using registered module classes.

Unknown classes are rejected rather than dynamically executed from arbitrary model-file contents.

The format is designed to avoid:

• Arbitrary Python pickle execution.
• Embedded executable model definitions.
• Unrestricted dynamic class imports.

Pickle-free loading reduces code-execution risk but does not automatically guarantee protection from every malformed archive, resource-exhaustion scenario, or implementation defect.

Treat downloaded model files as untrusted input.

• Obtain models from trusted sources.
• Verify hashes when available.
• Inspect metadata.
• Avoid unnecessary privileges.
• Use isolated environments for higher-risk analysis.
• Keep the framework updated.

EveryO exposes:

import everyo as eo

info = eo.inspect_archive("model.evo")

print(info)

Inspection provides metadata; it does not establish that a model is safe or trustworthy.

import everyo as eo

model = eo.load("model.evo")

If a specially crafted archive causes EveryO's loader to execute attacker-controlled code, report it as a security vulnerability.

For higher-risk environments, consider process isolation and operating-system resource limits.

The official policy excludes denial of service caused solely by deliberately enormous allocations.

External data can influence runtime behavior.

Validate:

• Array shapes.
• Dtypes.
• Expected dimensions.
• File formats.
• Numeric ranges where applicable.
• Configuration constraints.

Do not interpret untrusted configuration content using:

eval(...)

or:

exec(...)

Prefer structured parsers for JSON, YAML, and other supported configuration formats.

Use safe YAML loading rather than unsafe object construction.

Applications should validate file paths when operating in restricted directories or multi-user environments.

EveryO applications may introduce additional risks through file uploads, web APIs, authentication, or remote execution.

Those application-level risks require separate controls.

The official security policy states that EveryO's core:

• Requires no API credentials.
• Makes no network requests.
• Does not collect usage telemetry.
• Does not transmit user activity through its CLI.

Core tensor and model operations are designed for local execution.

Unexpected outbound connections from EveryO's core should be treated as a potential security issue.

Applications using external services or dependencies may have different privacy properties.

EveryO's core policy does not govern all software that integrates with it.

• Avoid logging sensitive datasets.
• Do not commit private training data.
• Limit access to model artifacts.
• Document any new network-dependent functionality.

EveryO's CUDA extension is optional.

Native code introduces memory-safety risks that are different from those of ordinary Python code.

• Out-of-bounds reads.
• Out-of-bounds writes.
• Invalid pointers.
• Use-after-free.
• Incorrect buffer sizes.
• Device synchronization defects.

The official security policy describes:

• Bounds checking.
• CUDA error checking.
• RAII-owned device memory.

The repository uses facilities such as:

EVERYO_CUDA_CHECK(...)

and:

EVERYO_CUDA_CHECK_KERNEL()

• Compare kernels against CPU references.
• Test boundary dimensions.
• Test unusual tensor shapes.
• Validate allocation sizes.
• Review ownership and cleanup.
• Use appropriate native memory-checking tools.

Report native memory corruption or out-of-bounds behavior through the private vulnerability channel.

EveryO's declared core dependencies are:

numpy>=1.22
matplotlib>=3.5

Optional integrations include TensorFlow, ONNX-related packages, PyYAML, and CUDA build dependencies.

The official policy distinguishes:

• Vulnerabilities originating in third-party packages.
• Vulnerabilities caused by EveryO's unsafe use of those packages.

Upstream vulnerabilities should generally be reported to the affected upstream project.

Unsafe integration by EveryO is within EveryO's security scope.

• Review dependency changes.
• Check published advisories.
• Avoid unnecessary packages.
• Assess transitive dependencies.
• Keep build tools updated.
• Validate compatibility after upgrades.

For a development environment:

python -m pip install pip-audit

python -m pip_audit

This is a recommended additional check, not a verified mandatory EveryO CI gate.

Automated audits do not detect every vulnerability.

A clean audit does not prove that an environment is secure.

EveryO's core does not require user accounts or API keys.

Never commit:

• API tokens.
• Passwords.
• Private keys.
• Cloud credentials.
• Signing keys.
• Personal access tokens.

Avoid committing sensitive .env files.

The repository's .gitignore excludes common sensitive file patterns.

Use appropriately scoped publishing credentials or trusted publishing for release automation.

If credentials are accidentally exposed:

1. Revoke or rotate them.
2. Assess exposure.
3. Notify the relevant maintainers.
4. Remove the secret from active use.
5. Follow the appropriate incident procedure.

Deleting a credential from the latest commit does not necessarily remove it from Git history.

Repository controls protect source integrity.

• Multi-factor authentication.
• Least-privilege access.
• Reviewed pull requests.
• Required status checks.
• Branch protection.
• Dependency alerts.
• Secret scanning where available.

These are recommended controls; this page does not claim they are all currently enabled.

EveryO's repository rules prohibit:

• Malicious code.
• Credential harvesting.
• Unauthorized telemetry.
• Undisclosed network activity.
• Fabricated technical results.
• Unreviewed generated bulk changes.

Security-sensitive changes should receive careful review of:

• Inputs.
• File operations.
• Dependencies.
• Serialization.
• Native code.
• Network behavior.
• Permissions.

Reject invalid shapes, dimensions, and configuration values before unsafe operations.

Functions should not unexpectedly:

• Access networks.
• Modify unrelated files.
• Collect telemetry.
• Execute external commands.

Errors should be useful without exposing credentials or sensitive information.

Use deterministic cleanup and context managers where appropriate.

Validate buffer sizes and memory ownership when crossing Python/native boundaries.

Security fixes should preserve the CPU-only core architecture unless the approved change specifically requires otherwise.

Security testing should complement functional and numerical tests.

python -m pytest -q

ruff check .

ruff format --check .

When fixing a security defect, add a regression test where feasible without publicly exposing dangerous details prematurely.

Do not state that a security test passed unless it was actually executed.

The release pipeline is a potential supply-chain attack surface.

• Restrict publishing permissions.
• Use protected environments.
• Require maintainer approval.
• Validate build artifacts.
• Minimize workflow permissions.
• Use trusted publishing.
• Verify release tags.

Before publication:

python -m build

python -m twine check dist/*

Inspect wheels and source distributions for:

• Unexpected executables.
• Credentials.
• Private data.
• Unnecessary files.
• Unexpected dependencies.

A published artifact should be traceable to an approved source revision.

Critical security fixes may require coordinated publication of a patched release and GitHub advisory.

The official security policy defines scope but does not publish a formal severity-scoring standard.

The following classification is a recommendation for triage.

Severity should consider:

• Exploitability.
• Required privileges.
• User interaction.
• Confidentiality impact.
• Integrity impact.
• Availability impact.

CVSS may be used when appropriate, but no specific scoring system is currently mandated by the verified policy.

Detect
  |
  v
Contain
  |
  v
Investigate
  |
  v
Assess Impact
  |
  v
Develop Fix
  |
  v
Verify Fix
  |
  v
Publish Advisory
  |
  v
Monitor

• Preserve relevant evidence.
• Limit unnecessary disclosure.
• Identify affected versions.
• Assess exploitability.
• Coordinate with the maintainer.

Possible responses include:

• Code patch.
• Configuration mitigation.
• Dependency update.
• Security advisory.
• Corrective release.

Review:

• Root cause.
• Detection gaps.
• Testing gaps.
• Communication.
• Preventive controls.

Security patches must address the underlying vulnerability.

• Reproduce the defect where safely possible.
• Confirm the fix blocks the issue.
• Add regression coverage.
• Run relevant functional tests.
• Assess compatibility.
• Review for similar vulnerabilities.

For CUDA-related vulnerabilities, test relevant memory boundaries and hardware-backed behavior.

For model-loading vulnerabilities, verify that malicious input cannot bypass the intended pickle-free and registered-module design.

Document user-facing mitigation steps without unnecessarily publishing exploit details before coordinated disclosure.

GitHub Security Advisories provide a structured mechanism for private collaboration and coordinated disclosure.

• Summary.
• Affected versions.
• Impact.
• Preconditions.
• Fixed versions.
• Workarounds.
• Credits.
• References.

Public advisories should be released in coordination with the maintainer and, where practical, the patched software release.

Update the supported-version table when release policy changes.

The current discrepancy between 0.1.x security support and 0.2.0 package metadata should be resolved by a maintainer-approved documentation change.

EveryO's official security policy states that reporters will receive credit in the advisory and changelog unless they request otherwise.

Researchers may request anonymity.

Credit should accurately identify contributions without exposing private information.

The policy does not establish a monetary bug-bounty program.

Do not assume that reporting a vulnerability creates entitlement to payment.

• Receive private reports.
• Assess impact.
• Coordinate remediation.
• Approve security releases.
• Publish appropriate advisories.

• Follow secure coding practices.
• Protect secrets.
• Validate dependencies.
• Add relevant tests.
• Avoid unauthorized network behavior.
• Report vulnerabilities privately.

• Keep software updated.
• Treat model files as untrusted input.
• Review application-level risks.
• Use appropriate environment isolation.
• Report suspected vulnerabilities responsibly.

• Provide clear evidence.
• Minimize unnecessary harm.
• Respect private disclosure.
• Coordinate publication reasonably.

• No secrets committed.
• Access permissions reviewed.
• Security-sensitive changes reviewed.
• Dependencies assessed.
• Public claims verified.

• Pickle-free loading preserved.
• Unknown modules rejected.
• Malformed archives handled.
• Relevant regression tests included.
• Resource-exhaustion risks assessed.

• Inputs validated.
• No unsafe evaluation.
• File operations reviewed.
• Sensitive data not logged.

• Bounds checks reviewed.
• Memory ownership reviewed.
• CUDA errors checked.
• CPU reference comparison performed.
• Hardware limitations documented.

• Source revision approved.
• Package artifacts inspected.
• No secrets in distributions.
• Dependency advisories reviewed.
• Publishing permissions controlled.
• Security-support table accurate.

• Report received privately.
• Initial assessment recorded.
• Affected versions identified.
• Fix verified.
• Disclosure coordinated.
• Reporter credit preferences respected.

Continue with EveryO's governance and long-term development documentation.

Wiki links become active after the corresponding pages are created.