Using Oscilon Securely

Oscilon networks (.osm files) represent neural architectures that undergo targeted evolutionary mutations. Loading an untrusted .osm model or checkpoint is equivalent to executing untrusted code, as the framework performs forward passes, error scanning, GA-based mutations, and fitness evaluations that can interact with system resources.If you must handle untrusted models or checkpoints (e.g., shared by external collaborators), execute Oscilon within a sandboxed environment (e.g., containerization, virtual machines, or restricted user privileges).

Compilation with supported backends (AMD ROCm/HIP, Apple Metal, FPGA kernels for AMD Zynq™ UltraScale+™ MPSoCs) via standard CMake flags is considered safe for trusted models. Debugging and profiling tools that expose low-level mutation details are not intended for untrusted inputs and should be used cautiously.

Loading untrusted serialized models or checkpoints (.osm format) grants the loaded network full access to the capabilities of the Oscilon runtime. Maliciously crafted checkpoints could:

• Alter mutation behavior to target system-critical operations.
• Influence fitness evaluations that interact with filesystems or hardware accelerators.
• Exploit sparse node identification to trigger unintended resource access.

Always validate the source of any shared .osm file. In multi-user research settings, isolate loading and evolution processes.

Oscilon data pipelines support lightweight, zero-copy streaming from heterogeneous sources (e.g., sensor streams on edge devices). Core formats (CSV, raw binary tensors, and simple PROTO buffers) are processed with minimal third-party dependencies and are considered safe for untrusted data.More complex formats or custom transforms involving external libraries should be sandboxed when processing untrusted inputs, particularly in healthcare data pipelines where integrity is critical.

Oscilon operates in a single, deterministic execution mode emphasizing scalar-level operations and strict fitness thresholding. There is no equivalent to TensorFlow's Eager mode—shape inference and bounds checks are always active to enforce convergence guarantees.

Approved researchers may share models/checkpoints via the private Bitbucket repository. Treat all shared artifacts as potentially untrusted:

• Use sandboxing when loading models from other collaborators.
• Avoid direct filesystem or hardware interactions controlled by loaded network parameters.
• Resource exhaustion from overly aggressive mutation cycles is possible but not considered a vulnerability (mitigate with process limits and monitoring).

When using AMD GPUs, Apple GPUs, or AMD Zynq™ MPSoCs, be aware of potential side-channel risks in shared hardware environments (as documented in public research). Report hardware-specific issues to the respective vendor.

We recognize security issues as vulnerabilities only when they occur in recommended safe usage scenarios (e.g., processing trusted models/checkpoints with standard data pipelines). Issues that require discouraged practices (e.g., loading untrusted models without sandboxing) are not treated as vulnerabilities.

To report potential security issues, please email [email protected] with the following details:

• A clear title
• Your name and affiliation/research context (if any)
• Technical description of the issue
• Minimal reproducible example (including preview version, e.g., v0.1)
• Attack scenario demonstrating impact on safe usage
• Whether the issue is public or known to others

Reports will be reviewed promptly by our Oscilon core team. Validated vulnerabilities will be addressed in upcoming preview builds, with credit given to reporters (kept confidential if requested).Thank you for helping strengthen Oscilon's reliability in high-stakes industries and edge applications.