We take security seriously. If you discover a security vulnerability in models (JVLLM), please report it responsibly.

Email: security@integrallis.com

Please include:

• A description of the vulnerability
• Steps to reproduce the issue
• The potential impact
• Any suggested fix (optional)

We follow a 90-day coordinated disclosure policy:

1. Reporter submits vulnerability via email
2. We acknowledge receipt within 48 hours
3. We assess severity and develop a fix
4. We release a patched version
5. We publish a security advisory (GitHub Security Advisories)
6. Reporter may publish their findings after 90 days or after the fix is released, whichever comes first

• Memory safety issues (buffer overflows, use-after-free in Arena-managed segments)
• Denial of service via crafted model files or inference inputs
• Information disclosure through side channels
• Any bug that compromises data integrity of model weights or inference outputs

• Performance issues or inefficiencies (report as regular issues)
• Bugs in test code or benchmarks
• Issues requiring physical access to the machine

Security-relevant boundaries:

• Published execution backends are explicit — backend-java is Java bytecode. backend-native optionally loads the small Models-owned Rust kernel library through Java FFM; it does not load llama.cpp, Ollama, or another inference engine.
• No downloader in the core runtime — The published core modules perform no network I/O. Users supply a local model path or use the separate ModelJars facade.
• Arena-based model mapping — The backend owns a shared Arena and closes it from PureJavaBackend.close(); using the backend after close is unsupported.
• Artifact signing is external — JReleaser signs staged Maven artifacts with the maintainer's GPG key. Runtime libraries do not perform release-signing operations.
• Publication is allowlisted — Only modules named in publishedModuleNames are staged for Maven Central. Adding a Gradle subproject does not publish it.

• SBOM generation — CycloneDX SBOMs for every published module are generated and validated by complianceCheck
• Dependency locking — Gradle lockfiles pin all transitive dependency versions
• Vulnerability scanning — OWASP Dependency-Check is available as an explicit release audit; findings with CVSS >= 7.0 fail that task
• Artifact signing — The release workflow signs Maven Central artifacts with GPG through JReleaser.
• Deterministic JAR settings — JAR tasks disable file timestamps and use reproducible file order. A byte-for-byte clean-room rebuild has not yet been independently verified.
• SAST — A GitHub CodeQL workflow is configured for pull requests, pushes to main, and a weekly schedule.
• Code quality — MFCQI scores the combined published production sources and each source-bearing module on pull requests and pushes to main.