Skip to main content
Warning You are using Sysand Test index - a separate instance of Sysand Index that allows you to try publishing tools and processes without affecting the main index.
If you previously published to beta.sysand.org, follow the migration guide to move your packages to sysand.com.

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.

Please keep it private. Do not disclose suspected vulnerabilities in Sysand Index through any public channel, including:

  • Our community forum at forum.sensmetry.com
  • Any chat room, Discord, Slack, or similar venue
  • Mailing lists or social media posts

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.

Account and Publishing Security

Sysand Index also provides features that help you keep your own account and releases secure:

  • Trusted publishing lets a GitHub Actions workflow or GitLab CI pipeline exchange a provider OIDC token for a short-lived upload token, so releases can be published without long-lived secrets in CI. See Set up trusted publishing for the step-by-step path.
  • API tokens for uploads can be scoped to a single project and always carry an expiration date. Creating one requires recent reauthentication.
  • Two-factor authentication is available for every account. You can enable an authenticator app and generate recovery codes in your account security settings.