If you discover a security vulnerability in OntoKit, please do not open a public GitHub issue. We treat security reports privately so we can ship a fix before details become public.

Two ways to report, in order of preference:

1. GitHub Security Advisory (preferred) — open a private report at https://github.com/CatholicOS/ontokit-api/security/advisories/new (or the equivalent path on ontokit-web if the bug is frontend-side). This keeps the report in GitHub's secure channel and gives us a structured place to coordinate fixes, CVE assignment, and disclosure.

2. Email — priest@johnromanodorazio.com if GitHub Advisories aren't suitable (e.g., you can't sign in or the issue spans multiple non-CatholicOS repos).

We'll acknowledge receipt within 5 business days and aim to provide an initial assessment within 10 business days. Coordinated disclosure timelines are negotiated case-by-case based on severity.

OntoKit is pre-1.0. Security fixes are applied to:

There is no LTS line yet. Once OntoKit reaches 1.0 this section will be expanded.

Both ontokit-web and ontokit-api are scanned on PRs targeting dev and on every push to main / dev by Semgrep (Pro engine, server-side AppSec policy). The scan workflow lives at .github/workflows/semgrep.yml and covers ~98,000 rules per scan.

The mode semantics described below (Block / Comment / Monitor) are applied by the Semgrep AppSec Platform when the workflow runs with SEMGREP_APP_TOKEN set — i.e., the primary CI path. When the token isn't available (typical for forks or contributors outside the org), semgrep ci falls back to the explicit --config p/... rulesets in the workflow file. In that fallback path, ERROR-severity findings still fail CI (so Block-mode rules effectively still block), but Comment-mode rules don't post inline PR comments — there's no semgrep-app[bot] integration without the token — and Monitor-mode collapses into the same CI-log surface as Comment-mode.

The org-wide policy at https://semgrep.dev/orgs/priest-johnromanodorazio-com/policies applies the following modes to the rulesets we explicitly enable on top of Semgrep's Pro Rules baseline:

In addition, the Pro Rules baseline (~3,000 code rules) runs in Monitor mode — findings are visible in the dashboard but don't post PR comments or block merging. We promote individual rules to Comment or Block as we triage them.

• A CI check named Semgrep / Static analysis on every PR. It fails when a Block-mode finding lands in the diff.
• Inline PR comments from semgrep-app[bot] for Comment-mode findings (only when the GitHub App is installed on the org — see https://github.com/apps/semgrep). These are advisory and don't block merge. Forks and contributors without org access won't see these inline comments because the GitHub App can't post on their behalf — findings still appear in the CI job log and the Block-mode CI gate still applies, just without the inline-comment notification.
• A link from the check's "Details" page to the matching dashboard view at semgrep.dev for triage history.

If a Semgrep finding is a confirmed false positive, suppress it inline with a justification:

# nosemgrep: <rule-id>  Reason: <why it's safe in this context>
foo()

The Reason: is required — bare nosemgrep comments without justification will be rejected at code review. The current baseline of legitimate suppressions was triaged in #124 (PR #126); follow that style for any new suppressions you add. For repository-wide exclusions (build output, test fixtures, generated migrations), edit .semgrepignore.

See CLAUDE.md for the equivalent semgrep invocation contributors can run locally before pushing. Both the Pro and the OSS-engine fallback are documented there.

The following are not considered security vulnerabilities:

• Findings in code that lives under tests/, alembic/versions/, docs/, or other paths excluded via .semgrepignore. Those locations are intentionally permissive (test fixtures use insecure patterns deliberately; generated migrations are autogenerated by Alembic).
• Issues in unsupported third-party services we integrate with (Zitadel, GitHub, Cloudflare, MinIO, Postgres, Redis). Report those upstream.
• DoS via rate-limiting or unauthenticated endpoint flooding — we rely on reverse-proxy / WAF layers for those, not application code.
• Self-XSS or attacks that require an attacker to already control the victim's browser session.

Once a fix is available for release, we'll publish a GitHub Security Advisory (with the reporter credited unless they request anonymity) and request a CVE if the issue warrants one. Please don't disclose details publicly — including via social media, blog posts, or conference talks — until the advisory is published.