Document security-relevant CI checks used by Forgejo #1660

atluxity commented 2025年12月24日 17:46:18 +01:00

Hi,

While reviewing Forgejo against the OpenSSF Best Practices criteria [1], I noticed that Forgejo already runs several security-relevant static analysis checks (such as govulncheck, go vet, and golangci-lint) as part of its normal development workflow and CI.

I could not find a concise place in the documentation that explicitly describes which CI checks are considered part of Forgejo’s security or release quality expectations. During the review, this made it harder to distinguish between intentional project practice and incidental tooling.

Consider briefly documenting which security-relevant checks are expected to pass in CI, and that releases are cut from code that has passed these checks. This could be a short section in the developer or security documentation.

From the project’s perspective, documenting this would make existing security practices easier to understand for new contributors, downstream packagers, distributions, and organizations evaluating Forgejo for adoption. It can reduce repeated questions about what is enforced in CI, strengthen trust in the project’s security posture, and lower the effort needed to respond to external reviews — without changing any current behavior.

Thanks for the continued work on Forgejo.

1 - https://www.bestpractices.dev/en/projects/11645/passing#all

Hi, While reviewing Forgejo against the OpenSSF Best Practices criteria [1], I noticed that Forgejo already runs several security-relevant static analysis checks (such as govulncheck, go vet, and golangci-lint) as part of its normal development workflow and CI. I could not find a concise place in the documentation that explicitly describes which CI checks are considered part of Forgejo’s security or release quality expectations. During the review, this made it harder to distinguish between intentional project practice and incidental tooling. Consider briefly documenting which security-relevant checks are expected to pass in CI, and that releases are cut from code that has passed these checks. This could be a short section in the developer or security documentation. From the project’s perspective, documenting this would make existing security practices easier to understand for new contributors, downstream packagers, distributions, and organizations evaluating Forgejo for adoption. It can reduce repeated questions about what is enforced in CI, strengthen trust in the project’s security posture, and lower the effort needed to respond to external reviews — without changing any current behavior. Thanks for the continued work on Forgejo. 1 - https://www.bestpractices.dev/en/projects/11645/passing#all

atluxity commented 2025年12月26日 23:19:57 +01:00

If it was unclear, I do not know the facts that would be in the documentation, so I cannot write it myself. But if someone write them here then maybe I can make an attempt at creating a PR.

If it was unclear, I do not know the facts that would be in the documentation, so I cannot write it myself. But if someone write them here then maybe I can make an attempt at creating a PR.

mfenniak commented 2025年12月28日 23:31:36 +01:00

Hi @atluxity,

I have not, to date, seen any inquiries or questions in the Forgejo project that would be solved by the documentation that you're proposing to create. These are the types of inquiries that I've dealt with regularly as a software engineer at a SaaS organization, and which required a team of compliance professionals in order to resolve... especially since the sales team never wants to answer an RFP with a "no" for anything in the security column, regardless of reality. 🤣

I'm a member of Forgejo's Security team, and so I want to clarify that this message represents my personal opinion, not a team consensus communication. My personal opinion is that I don't think that creating this documentation and maintaining it would provide value for Forgejo today that is commensurate with the effort involved.

Hi @atluxity, I have not, to date, seen any inquiries or questions in the Forgejo project that would be solved by the documentation that you're proposing to create. These are the types of inquiries that I've dealt with regularly as a software engineer at a SaaS organization, and which required a team of compliance professionals in order to resolve... especially since the sales team never wants to answer an RFP with a "no" for anything in the security column, regardless of reality. 🤣 I'm a member of Forgejo's Security team, and so I want to clarify that this message represents my personal opinion, not a team consensus communication. My personal opinion is that I don't think that creating this documentation and maintaining it would provide value for Forgejo today that is commensurate with the effort involved.

atluxity commented 2025年12月29日 13:16:16 +01:00

Hi @mfenniak ,

Thanks for taking the time to reply, and for the context. I appreciate you sharing your perspective. I’ll be honest and say that I don’t fully grasp yet where the documentation burden would show up in practice, but I trust your experience and judgment on that.

My intent wasn’t to introduce compliance-style obligations or anything resembling RFP work, but simply to surface something that stood out during an external review context. If the assessment is that the cost of documenting and maintaining this outweighs the value for Forgejo, I’m completely comfortable deferring to that.

I was thinking this could be covered by just a few sentences that referred to relevant places in code for details. But I know I can be naive. 😄 Just please note that we who care about security documentation exists also outside of sales teams.

I appreciate you taking the time to explain your view, and thanks again for the work you all do on the project.

Hi @mfenniak , Thanks for taking the time to reply, and for the context. I appreciate you sharing your perspective. I’ll be honest and say that I don’t fully grasp yet where the documentation burden would show up in practice, but I trust your experience and judgment on that. My intent wasn’t to introduce compliance-style obligations or anything resembling RFP work, but simply to surface something that stood out during an external review context. If the assessment is that the cost of documenting and maintaining this outweighs the value for Forgejo, I’m completely comfortable deferring to that. I was thinking this could be covered by just a few sentences that referred to relevant places in code for details. But I know I can be naive. 😄 Just please note that we who care about security documentation exists also outside of sales teams. I appreciate you taking the time to explain your view, and thanks again for the work you all do on the project.