Code scanning results should be visible to everyone, not only those with write permission on the repository

[ryao]

Anyone who wants to view the CodeQL scan results can just fork the repository, which makes hiding the results of code scanning the equivalent of this:

https://www.syslog.com/~jwilson/pics-i-like/kurios119.jpg

Requiring write access to view them just makes it less likely that projects will see fixes from people without write access, which is counterproductive for open source projects. Bad actors looking for security vulnerabilities will not be deterred by the write access requirement either, since they could always fork, much like legitimate contributors already do.

Maybe, if a security token were needed for a paid service, the security by obscurity from hiding the results might discourage casual bad actors, but since CodeQL is not a paid service for OSS projects, could we at the very least get an option to stop hiding the scan results on branches from everyone?

[sj]

Thanks for the suggestion, @ryao! I lead the PM team in this area, and you've highlighted one of the conundrums we've been grappling with.

When we originally designed code scanning, we spoke to a large number of open source developers to understand better how people in the community would like to use code analysis features. The vast majority was very clear in indicating that they would prefer it if their security problems wouldn't be published publicly — even if these results would be visible to people who forked their repository. We did indeed discuss the power of the security community: if more people a aware of alerts, then more people are around to fix them. However, maintainers still overwhelmingly preferred to deal with security issues in private.

Since then, we've heard from a lot of people (like yourself!) who would prefer results for their repository to be public, in order for others to lend a helping hand fixing such potential security problems. We're therefore thinking about making this configurable for maintainers.

Thank you very much for your input — we'll definitely take that into account!

[ryao]

@sj The write access requirement is particularly problematic for the OpenZFS project, where a number of well trusted individuals do not have write access. Our code review process requires that multiple contributors approve commits before they are merged, so we take advantage of that to minimize the potential damage from a compromised contributor by restricting write permission to a very small group of our contributors. The result is that hiding code scanning results behind write access is inconvenient for us since it will hinder the majority of regular contributors from proactively looking at them.

That said, my interactions with a number of other projects that I shall not name have shown me that the desire to hide code scanning results is fairly common, which is unfortunate. I had requested access to coverity results from 3 projects related to OpenZFS and had 2 denials. Upon asking again, one granted access (since I demonstrated that I was a minor contributor) while another just left the request in limbo, despite my point that I could get the results by forking on GitHub and uploading my own builds to coverity. There was a 4th project that I did not even bother asking because their website made it clear that they were openly hostile to granting outsiders access to their scan results.

Hiding scan results is contrary to the spirit of open source and counterproductive to the goal of publishing high quality software. Everyone involved with the OpenZFS project with whom I have discussed this matter agrees that hiding code scanning results is pointless. I am not sure why our thinking on this matter is so different from the majority of other projects. Those conversations took place before any of us knew GitHub code scanning existed, so our position was not motivated by the inconvenient interaction between GitHub code scanning and our internal security policies.

[SwuduSusuwu]

The lack of option to mark results public, hinders discussions with those who produce the scan tools;

@SwuduSusuwu Your provided links are all private.

Oops, did not know. Thought that if the repository was public, that the results of open source scan tools were public (since anyone can use those on the public repository's source code).
https://duckduckgo.com/?q=How+to+set+GitHub+%22code+scanning+alerts%22+to+public has;

• https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts (which does not have a section on how to set those to public)
• duck.ai_2025-04-10_08-52-52.txt (which says that those are supposed to default to public)
• Numerous irrelevent results.

How to have those public?

Originally posted by @SwuduSusuwu in #329

[SwuduSusuwu]

As one of the first web hosts in the early 2000's to follow XHTML Strict on all documents, was proud to include references to results of W3's document scan tools (which users can click on to view how good your documents conform to standards),
and thought that GitHub's code scan tools were similar, so have put lots of references to those into README.md (and into the messages of numerous commits); sucks to know that all of those will show "404 page not found" errors to users.

• Found this issue from a search for how to fix this; it sounds as if there is no solution.
• It is difficult to trust that most of the interviewed developers asked "[Make it so that no owners of any repositories are allowed to share the results of code scans / reviews]"; Perhaps GitHub misintepreted the interviews.

Will this ever have solutions, or is the conclusion to "just give up now" and remove all references to GitHub code reviews (most of which are not even about security but are general code reviews)?