The SciCat project takes security seriously. This file documents the general security procedures for SciCatProject repositories. Individual repositories may have additional information in their own SECURITY.md files.

SciCat is a community-driven, volunteer-maintained open source project. There is no commercial entity operating SciCat, no dedicated security team, and no service-level agreement (SLA) attached to this policy. Response times described below are best-effort targets, not guarantees.

This document describes how the SciCat developers and steering committee handle the discovery, triage, and disclosure of security issues in the upstream project — it does not cover the operational security of any individual deployment.

If you believe you have found a security vulnerability in SciCat, please report it privately via one of the following:

• ✅ Create a private security advisory using the 'Report a vulnerability' button in the 'Security and quality' tab or by going to https://github.com/SciCatProject/<repo>/security/advisories/new.
• ✅ Email the project leaders: scicat-leaders@lists.psi.ch
• ✅ Notify a project leader by Direct Message in the scicat slack chat. Check the website for current project leaders.
• ❌ DO NOT report security vulnerabilities through public GitHub issues, discussions, or pull requests, public slack channels, etc.

Please include as much information as you can to help us better understand and resolve the issue. We will work on fixing the issues privately.

We classify reported issues into three severity levels. Classification is judgment-based and considers exploitability, impact (data exposure, integrity, availability), and whether exploitation requires privileged access.

Issues with minimal practical impact — for example, issues requiring unusual local access, exposing non-sensitive information, or requiring significant, unlikely preconditions to exploit.

Issues that could lead to limited unauthorized access, data exposure, or disruption under realistic conditions, but that are constrained in scope (e.g., affecting a single component, requiring authentication, or needing specific configurations to be exploitable).

Issues that could lead to significant unauthorized access, data loss/exposure, remote code execution, authentication/authorization bypass, or broad service disruption, and that are exploitable under common or default configurations.

Severity is assessed by the maintainers/steering committee and may be revised as more information becomes available.

Medium and High vulnerabilities are announced confidentially to cybersecurity personal and select SciCat operators ahead of the public disclosure to allow organizations time to patch public systems. Please contact the project leaders if you would like to be notified about security advisories prior to the public disclosure.

We use GitHub security advisories to disclose vulnerabilities publicly after a fix is available.

This section is intended for SciCat developers responding to a new security advisory.

1. Project Leaders (PL) will triage the severity of the vulnerability and assign developers to start working on a fix.
   1. Create a private security advisory, if the reporter did not already.
   2. Grant the team @SciCatProject/security access to the advisory
   3. Declare a code freeze to reduce conflicts until the vulnerability is patched
2. PL notify the security team privately about the vulnerability. Include information about the expected time to a fix. Facilities should be prepared to update promptly when the patch is released. Private communication channels include:
   • scicat-security@lists.psi.ch (including Steering Committee members)
   • #security slack channel
   • Security Github Team
3. From the advisory, create a private fork to collaborate.
   1. Develop on the master and release branches directly. Pull requests from the private fork must match branch names from the upstream repository.
   2. Keep the fix minimal and don't incorporate additional features. Squash commits regularly to make it easy to cherry-pick.
   3. Cherry-pick the fix to master, release (and long-term releases, if applicable)
   4. Create PRs to back to the upstream repo for review.
4. Operators have 1-2 days to review the fix & prepare (privately) for the upgrade. If they run a fork, they should cherry-pick the fix onto their deployed branch.
5. Draft an email announcement and release notes in preparation for the patch release
6. When the fix is ready:
   1. Merge all PRs. This is an atomic step.
   2. Immediately make a patch release from the release branch
   3. Send the email announcement with information
7. Facilities update to the new release or master branch.
8. The next scicat operator meeting should include a retrospective analyzing the incident response.

The private fork after development should look something like this:

gitGraph
   commit id: "5.2.0-feature"
   branch release
   commit id: "5.2.0" tag: "v5.2.0"
   checkout main
   commit id: "5.3.0-feature"
   commit id: "advisory-fix-1"

   checkout release
   cherry-pick id: "advisory-fix-1" tag:"v5.2.1"

Alternately, it may be easier to develop the fix on release and then merge it back into main. Both should produce the same result.

These timeframes reflect a volunteer effort and depend on maintainer availability. There is no contractual or business-criticality obligation behind them.

This policy covers the SciCat core codebase and components maintained under the SciCat GitHub organization. It does not cover:

• Vulnerabilities in third-party dependencies (please report these upstream, though letting us know is appreciated so we can track and update)
• The security configuration or operation of any specific institutional deployment of SciCat

For anything not covered here, reach out via the SciCat Slack Channel.