Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOC: Add security policy document #7199

Merged
merged 4 commits into from
Sep 11, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
44 changes: 44 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# Security

If you believe you have found a security vulnerability in Slicer, please report it to us as described below.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we indicate the scope as well ?

Suggested change
If you believe you have found a security vulnerability in Slicer, please report it to us as described below.
If you believe you have found a security vulnerability in the Slicer application or websites, please report it to us as described below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably a good idea. Are security vulnerabilities in Slicer extensions included in the scope? Or should users report security issues of extensions through different means?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I think the correct answer is that we have limited influence on the extension developers and claim no responsibility for their actions. We might, as a best effort, pass on any reports but we can't claim to be doing anything rigorous (in fact, it might be that we don't do anything, e.g. if nobody notices the report or someone thinks someone else will handle it).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could only attempt to make commitments for selected extensions - that we develop ourselves, or we know the developers of, or at least the developers are known to be responsive. For this, we would need to do what we have been planning for years: specify "support level" or "stability" for each extension (at least 2 but maybe 3 levels).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should be making any "commitments" in a sense that people would interpret as legally binding, but we can say we intend to make an effort.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A more direct example would be Slicer extensions under the "Slicer" GitHub organization.

These 2 Slicer extensions are under the "Slicer" GitHub organization and are built-in to Slicer currently. Security reports related to this code falls under the scope of this SECURITY.md document where reports should go to the discourse email?
https://github.com/Slicer/LandmarkRegistration
https://github.com/Slicer/SlicerSurfaceToolbox

These are additional Slicer extensions under the "Slicer" GitHub organization, but are not built-in to Slicer and are installed as extensions through the extensions manger. Do these also fall under the scope of this SECURITY.md?
https://github.com/Slicer/SlicerNeuro
https://github.com/Slicer/SlicerJupyter

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not expected SECURITY.md document in Slicer/Slicer would propagate to Slicer/other repositories, but it does not hurt to clarify this. Later we can add SECURITY.md documents to other repositories.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You wouldn't expect SECURITY.md to apply to https://github.com/Slicer/LandmarkRegistration and https://github.com/Slicer/SlicerSurfaceToolbox even though it is included in the binaries at https://download.slicer.org/?

Copy link
Member Author

@jcfr jcfr Aug 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not expected SECURITY.md document in Slicer/Slicer would propagate to Slicer/other repositories

This could be addressed by creating a repository called .github where we would include the file SECURITY.md

See https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file

Since the Slicer project is our main code base, the default SECURITY.md could simply include a link to the one of Slicer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, this could easily be done in follow-up step.


## Reporting Security Issues

**Please do not report security vulnerabilities through public GitHub issues.**

Instead, send email to [slicer+security@discoursemail.com](mailto:slicer+security@discoursemail.com).

You should receive a response within 24 hours.

## Preferred Languages

We prefer all communications to be in English.
jcfr marked this conversation as resolved.
Show resolved Hide resolved

## Supported Versions

You can access the most up-to-date Slicer packages through the official [Slicer download](https://download.slicer.org/) website.

This table summarizes our general policy for updates to our binary distributions.

| Version | Support Status | Update frequency |
| ------- | ------------------ | ----------------------------------------- |
| Preview | :white_check_mark: | Continual integration of features & fixes |
| Stable | :white_check_mark: | Essential security fixes |

In general older releases are not updated.

> [!NOTE]
> There is no restriction on use, but Slicer is NOT approved for clinical use and the distributed application is intended for research use. Permissions and compliance with applicable rules are the responsibility of the user. For details on the license see [here](https://slicer.readthedocs.io/en/latest/user_guide/about.html#license).

## Scope

Reports may pertain to various aspects of the Slicer ecosystem, including:

- Slicer applications, modules and extensions
- Websites associated with Slicer

> [!NOTE]
> It's important to acknowledge that our impact on extension developers may be limited, and consequently, we disclaim responsibility for their actions. However, we are committed to forwarding reports to the best of our abilities.

> [!IMPORTANT]
> While we may not be able to offer legally binding commitments, we will do our best in addressing any reported security concerns.