These are my notes and recollection from the discussion. For those that attended please feel free to correct or add to the discussion as I didn’t capture everything in my notes.
The LLVM security group has transitioned from the Chromium bug tracker to using Github. This workflow is not ideal and it makes the transparency report harder to write. However there are not many alternative workflows available to us.
A majority of issues that have been raised are related to the LLVM infrastructure and not the code-generation and libraries. This appears to be common to many open-source projects.
The majority of the discussion was spent on the impact of new security features such as -fbounds-safety and memory safe languages that use llvm.
The LLVM security group is more like a security response group. Our primary role is to discuss security incidents in private to decide if coordinated action needs taking in private prior to any public disclosure. In many cases the issue can be discussed in the public, which speeds up the resolution process.
There is scope for another committee that discusses security mitigations such as -fbounds-safery in the public. This will be discussed in the roundtable for Memory Safety.
The security group has been handling the small number of incoming issues on a case by case basis. There could be an upswing in the number of reports as more projects consider these features as a critical part of their security policies, and any gap in the mitigation could be seen as the project being open to being exploited. This position is expected to be most common in regulated industries.
A possible impact will be on the workload of the security group. It is likely that projects requiring more from the security group are also contributors to the llvm-project, more resource, documentation and different processes may be needed to make this work. We may also need more vendors to join the security group to gain awareness of incoming issues, and to request that these issues be patched prior to disclosure.
Some suggestions from the discussion:
- Document more of the decision process.
- Invite vendor Product Security Incident Response Teams (PSIRT) teams for a discussion about what they care about.
- Build links with other organisations that do disclosure of security issues.
We expect this to be a topic of discussion at the LLVM security group meetings.
As a reminder the LLVM Security group meets once a Month, with details on the LLVM community calendar. The first part of the meeting is open to everyone and any topics can be raised. The second part is reserved for discussion of open issues, which can only be attended by security group members. More information on the LLVM security group is available at LLVM Security Group — LLVM 20.0.0git documentation