Security Disclosure Policy

Last revised: May 29, 2026

Security is a priority for us. If you've spotted something that looks wrong, please reach out privately rather than publicly so we can address it before it affects others.

Reporting a Malicious or Unsafe Package

If a package published on Sysand Index appears to behave maliciously or violate our policies, send a private report to security@sensmetry.com. Helpful reports usually include:

• The full URL of the project on Sysand Index.
• The release version(s) you believe are affected.
• A description of the behaviour you consider unsafe.
• Pointers to the relevant code, manifest, or metadata inside the archive when possible.

Common scenarios include typosquatting, dependency confusion, data exfiltration, code obfuscation, embedded command-and-control logic, or other unwanted runtime behaviour.

Reporting a Vulnerability in the Index Itself

For issues affecting the Sysand Index service itself — the web application, upload API, authentication flows, or anything else we operate — please email security@sensmetry.com with as much detail as you can, including clear steps to reproduce.

Avoid filing public issues, merge requests, or forum posts about the problem until we have had a chance to investigate and ship a fix. Coordinated disclosure keeps other users protected in the meantime.

What We Check on Every Upload

Every release archive uploaded to Sysand Index passes through a set of automated checks before it is made available to other users. These checks are not a substitute for reviewing the code you depend on, but they are designed to catch the most common ways a package archive can be abused. Among other things, we:

• Reject malformed archives and any entry that tries to escape the package boundary.
• Reject zip-bomb style archives that expand far beyond their stored size.
• Reject native executables and other file types that have no place in a model package.
• Reject nested archives that could be used to smuggle other payloads past these checks.
• Validate the project manifests and verify that every KerML or SysML v2 model file matches its declared checksum, so corrupted or tampered archives are caught before they reach other users.
• Confirm that files declared as KerML or SysML v2 actually parse as those languages, rather than arbitrary bytes renamed with a model file extension.

We deliberately keep the exact detection rules out of this page. If you believe an archive has slipped past these checks, please report it privately using the contact above.

A note on "executable" models: KerML and SysML v2 are modelling languages, and a model can describe behaviour that a downstream tool is able to simulate, generate code from, or otherwise execute. That execution always happens inside a separate SysML v2 tool, not on Sysand Index — we only host and serve the model files. We therefore also rely on tool vendors to do their own due diligence: sandboxing model execution, restricting filesystem and network access, and asking the user to confirm before running anything that could have side effects. If you build or integrate a SysML v2 tool, please treat packages fetched from any index as untrusted input.

How We Respond

We aim to acknowledge new reports within 5 business days. If the issue is straightforward, our reply will already include an assessment and the next steps.

For more involved investigations, expect occasional follow-up messages while we reproduce the issue, prepare a remediation, and plan disclosure. We appreciate reporters keeping the discussion private until we coordinate on a public announcement.