Update of security.md

[matthiaskunkel]

Updated document about ILIAS security policy, incl. process changes due to CRA requirements

Added sections for responsibilities within the process, extended description on reporting issues and resposibilities of Security Group, esp in relation to ENISA, and more details.

Next step would be to move file to top level for better perception.

[marvimarv]

Thank you for updating the security policy to reflect the CRA requirements! In my opinion the new "Responsibilities" and "Addressing a Security Issue" sections map the Art. 14 CRA obligations correctly (24h early warning, 72h initial assessment, final report 14 days after the fix release resp. one month after the incident notification), and the framing of the association as an open source software steward with BSI as CSIRT is well put.

A few things should be fixed before merging, though. Most importantly the table of contents, which is now largely broken: GitHub derives anchors from the heading text, so the shortened anchors (#about, #reporting, #fixing, …) point nowhere. I've left inline suggestions for everything.

Two general notes:

1. The diff introduces typographic quotes (‘…’) and apostrophes (’) in several places, probably from a word processor. Especially in the patch-filename examples these are risky because people copy them. Please use straight ASCII quotes throughout (inline suggestions below cover the critical spots; "association's", "CRA's" and "ENISA's" also carry curly apostrophes).
2. Regarding the announced next step of moving the file to the top level: full support. Note that GitHub only recognizes a security policy under the exact filename SECURITY.md in the repository root, docs/, or .github/. The current docs/development/security.md is not picked up. Once recognized, GitHub links the policy under the repository's Security tab and shows a hint to it when users open a new issue, which is exactly what "Never file a security issue in the bugtracker" needs. (Independently of that, enabling private vulnerability reporting in the repository settings might be worth considering; that adds a "Report a vulnerability" button on the Advisories page for confidential reports directly on GitHub.)

[atoedt]

There are some requirements in CRA Art. 24 what is to be included in the policy.

• Consider using the same language to allow easy recognition.
• Please also consider amending the text to meet the required content stated in 24(1).
• Please outline what is the approach to make this "verifiable". Consult Open Source Software Steward and CRA whitepaper, January 2026, p.5

[atoedt]

This document describes the cybersecurity policy for the core of the open source
learning management system ILIAS.

• This policy is to foster the development of a secure product.
• It outlines how vulnerabilities should be handled by developers.
• This policy outlines how security issues and incidents should be reported effectively and how they are handled by the responsible team, the ILIAS Security Group.
• It includes aspects of documenting, adressing and remediating vulnerabilities and promotes the sharing of information concerning vulnerabilities
• It outlines regular verification activities and how evidence of compliance is being gathered.

This document is NOT a guideline on how to set up and operate an ILIAS installation
securely. Such instructions can be found in the document /docs/configuration/secure.md

[atoedt]

super lean verification step: Security group can write a mail with their refelction to technical board, TB writes a mail back. Bith mails get filed to constitute a verification paper trail. No burocratic requirements are imposed on what "relection upon own process and results", the group can arrive at what reflection they want.

[atoedt]

Verfication

• One a year the Security Group will briefly reflect on their process and results. They will provide feedback to the Technical Board, who may choose to suggest changes.