DOC: Add security policy document #7199
Conversation
There was a problem hiding this comment.
This adapted language makes sense. I was viewing what GitHub included in their template for a SECURITY.md at https://github.com/Slicer/Slicer/security/policy and it included a section that states what versions get security updates. This would probably be good to mention about the Slicer 5.2.x series no longer getting security updates now that Slicer 5.4.x is out.
Supported Versions
Use this section to tell people about which versions of your project are
currently being supported with security updates.
Version Supported 5.1.x ✅ 5.0.x ❌ 4.0.x ✅ < 4.0 ❌
Co-authored-by: James Butler <james.butler@revvity.com> Co-authored-by: Steve Pieper <pieper@isomics.com>
jcfr
force-pushed
the
add-security-policy
branch
from
46cde8b
to
201a1e5
Compare
|
And using the latest support for admonition1 allows to nicely highlight the note.
Footnotes |
|
@pieper @jamesobutler @sjh26 @pieper Could you review and approve ? |
|
Is there any documentation any where that mentions that latest Slicer stable (Slicer 5.4.0) means that no more security releases will be created for the Slicer 5.2.x? For example if a security patch was added and a Slicer 5.4.1 was created, would a Slicer 5.2.3 also be created? The table mentions which versions get security fixes, but makes no mention about which versions do not get security fixes. |
No, I wouldn't expect that to happen. I'll add some text to clarify. |
Per suggestion by @jamesobutler
🙏
In the meantime, I also created the "Security" category: 
along with a private group called Before integrating, I will also circle back with Kitware security team. |
| @@ -0,0 +1,31 @@ | |||
| # Security | |||
|
|
|||
| If you believe you have found a security vulnerability in Slicer, please report it to us as described below. | |||
There was a problem hiding this comment.
Should we indicate the scope as well ?
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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/?
There was a problem hiding this comment.
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
Since the Slicer project is our main code base, the default SECURITY.md could simply include a link to the one of Slicer.
There was a problem hiding this comment.
That said, this could easily be done in follow-up step.
|
Yes, I would expect the policy to apply to those. I don't think we need to restrict what can be reported under this policy. Anything people reasonably think might be related to Slicer's security can be reported and if it's feasible to address we'll try. Again, we don't want to make any implication that we are taking responsibility for anything. |
|
By adding a "Scope" section, I believe I addressed all concern. Could you have another look and approve ? |
Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: James Butler <james.butler@revvity.com> Co-authored-by: Steve Pieper <pieper@isomics.com>
jcfr
force-pushed
the
add-security-policy
branch
from
e00d2e3
to
951d3cb
Compare
|
Additionally here is a link to OSSF’s document about setting up a security reporting process that was linked in the remediation area of https://github.com/Slicer/Slicer/security/code-scanning/12. https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md |
@jcfr does this previous statement still apply or is this ready to integrate? |
|
We have been discussing this and just sent a reminder so that we conclude. Out traveling this week, I will be follow up when back next week. |
Qt lupdate threw warnings about unconsumed metadata for lines that had translator's comments (that is exported to the language translation file to provide additonal context for translators) in the same line as the translatable text. For example:
this->SupportedReadFileTypes->InsertNextValue(vtkMRMLTr("vtkMRMLColorTableStorageNode", "MRML Color Table") + " (.ctbl)"); //: file format name
The issue with this is that Qt expects translator comment to be in the previous line like this:
//: File format name
this->SupportedReadFileTypes->InsertNextValue(vtkMRMLTr("vtkMRMLColorTableStorageNode", "MRML Color Table") + " (.ctbl)");
This pull request follows up #7197 and is expected to address the
Security Policywarning1 reported on our scorecard (as of 9ceb5d2).Language was adapted from https://github.com/microsoft/vscode/blob/main/SECURITY.md
Warning
Reporting Procedure
In this pull request, it assumes we create a private discourse category called
Securityassociated with the emailslicer+security@discoursemail.comAlternatively, as illustrated below, we could also enable the built-in
private vulnerability reporting2 feature available in GitHub.References
Footnotes
https://github.com/ossf/scorecard/blob/v4.12.0/docs/checks.md#security-policy ↩
https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability ↩