Add Security Policy

[niccokunzmann]

This adds a security policy as reguired by tidelift

See https://icalendar--755.org.readthedocs.build/en/755/security.html

• Contributes to Tidelift - Software Supply Chain Security & Sustainability #754

After the merge, I will activate the policy on GitHub here: https://github.com/collective/icalendar/security

---

📚 Documentation preview 📚: https://icalendar--755.org.readthedocs.build/

[coveralls]

Pull Request Test Coverage Report for Build 12467547779

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 96.372%

---

Totals
Change from base Build 12452278202:	0.0%
Covered Lines:	4580
Relevant Lines:	4747

---

💛 - Coveralls

[stevepiercy]

See comment.

[stevepiercy]

For a security policy, see examples at:

• https://github.com/Pylons/.github/blob/main/SECURITY.md # I've seen this in action, and the maintainers have a very professional response.
• https://github.com/plone/.github/blob/main/SECURITY.md # @mauritsvanrees can speak Plone ones.
• https://github.com/plone/Products.CMFPlone/blob/master/.github/SECURITY.md

It's really up to you what you want to include. If you have another revision after reviewing the above items, please @ me and I'll take another look. I'd suggest incorporating some bits and pieces from the above, especially how to work with CVEs.

[niccokunzmann]

Thank you for the links! I changed it to link to the Plone security page.

I will also write to the security team to ask if they have any feedback on this change.

[stevepiercy]

Do not refer to links that refer to links, especially if you cannot honor the policies to which they refer. You should instead grab the relevant bits that you want to follow and incorporate them into your custom security policy.

As this states, eventually people may report the security issue to security@plone.org. Are you a member of that email group? If not, you would need to discuss with them how to handle reports for icalendar sent to that address. It may be better to use another address.

[niccokunzmann]

We can activate GitHub's security reporting for this project.

I wonder: If a vulnerability gets reported on GitHub, then the other Plone packages do not know it exists.
If a vulnerability is reported to Plone, then I do not know it was reported.

Thus, I wonder what to do. We have two different groups here that are affected. I asked the security team to enlighten us here.

Also, nobody reported anything like this for years and it is unlikely to happen. So. I wonder if this is hypothetical. But a report should also not go into the void after a few years.

[stevepiercy]

We can activate GitHub's security reporting for this project.

To enable GitHub security, you create a SECURITY.md file at the root of your repo. GitHub should automatically detect it. It's nothing magical. It's mere documentation of how to report security issues, and how you will respond to them.

I wonder: If a vulnerability gets reported on GitHub, then the other Plone packages do not know it exists. If a vulnerability is reported to Plone, then I do not know it was reported.

Thus, I wonder what to do. We have two different groups here that are affected. I asked the security team to enlighten us here.

I would follow Pylons Project's workflow, modified to your preference.

https://github.com/Pylons/.github/blob/main/SECURITY.md

To summarize:

1. Users report security issues responsibly and in a manner that allows maintainers to respond in a timely and effective manner.
2. Maintainers verify and fix.
3. All the bullet points at that link.

I have no insight into the Plone Security Team's internal process. I'm not a member, and it's not transparent. I never received a report back of what they did for an issue that I recently reported to them.

Also, nobody reported anything like this for years and it is unlikely to happen. So. I wonder if this is hypothetical. But a report should also not go into the void after a few years.

It's only hypothetical until it's not, and then it's too late.

[niccokunzmann]

Thanks for all the replies.

GitHub also allows security reporting. This is how it looks from the outside from the Open Web Calendar, my project. There is a button to report.

I like the one you showed me (Pylons). This is also nice to follow for someone (me) who did not go through this process yet but is in a position of responsibility.

• I will copy that in.
• change the links
• use githubs security report feature - mainly because I do not want to maintain an independent list of who gets notified - it should be the GitHub project's maintainers.
• I would add that we also notify the Plone security team.

[stevepiercy]

I did not know that GitHub had that feature. Your plan sounds good to me.

[stevepiercy]

You should not ask people to open a security issue in a public arena, such as an issue tracker. This also conflicts with the link above, which links to https://plone.org/security/report.

If you want to create an email distribution group, and add members to it to review security, I'd suggest following Pylon Project's example as in https://groups.google.com/g/pylons-project-security/ or other free email group distribution list service that is less Google-y.

[niccokunzmann]

I would opt for the GitHub process. This way, we do not need to maintain another list.

[niccokunzmann]

@stevepiercy Thanks for all that help! Please review again ❤️

• As of now, once merged, we need to activate this green button on the project.
• Also, I will wait for at least two weeks to give Plone's security team a chance to review before merge. (until Monday 6th Jan 2025)
• Create direct link to report security, see here
• Create link to page with security announcements on GitHub.
• add link to tidelift in funding.yml

[stevepiercy]

Looks great! Only question is about the direct link, but I assume that can come after this is merged.

[stevepiercy]

@plone/security-team please review.