Right, thanks. The access is the GitHub security team, i.e. the same people who can see the restricted security issues in JIRA, including extension contributors, not only committers.
I’ve re-checked the split between what’s public and what’s in the private repo:
- The generic secure-coding rules are public: they’re in the Security Developer Guide (see Adding more best practices to the Security Developer Guide) and in the xwiki-dev-llm knowledge base, which points to the guide.
- What remains private is detailed knowledge of how XWiki’s security-relevant layers behave, the audit procedure itself (how to plan a pass, sweep a vulnerability class across the code base, prove and dedup findings), and some examples of past issues. None of this is a secret on its own, but together they make finding vulnerabilities a lot easier.
I also need to correct something I wrote in my first post: “It never holds a vulnerability”. Descriptions of vulnerabilities, including ones not yet disclosed, are useful as examples: a fix often leaves similar issues elsewhere, and the examples help find them. Since the people who can read the repository are the same people who can read the restricted JIRA issues, I don’t see a reason to exclude them. What doesn’t change: any issue found with these skills is always reported first as a restricted JIRA issue, following our Security Policy, and JIRA stays the reference for whether an issue is fixed or disclosed. I’ve updated the repository accordingly.
In the future, we can review the private knowledge bit by bit to decide what should move to the public side, as I did with the Security Developer Guide proposal above. It’s probably best to do it carefully though: publishing a rule also tells anyone what code to look for that breaks it, so we should check the code base against a rule (and fix what doesn’t follow it) before making it public.
Thanks
EDIT: I’ve opened and merged https://github.com/xwiki/xwiki-dev-security-llm/pull/7