Potential Security Enhancements for wxPython

[EricSun1982]

Hi wxPython Maintainers,

I'm reaching out because I appreciate your work on wxPython. As open-source security is a growing concern, I'd like to suggest some improvements based on the OpenSSF Scorecard best practices:

1、Token Permissions: Consider implementing explicit token permissions within the workflow to avoid over-permissioning vulnerabilities.
2、Pinned Dependencies: Using a commit hash instead of @v4 for the third-party library can mitigate breaking changes or vulnerabilities in future updates.
3、Static Application Security Testing (SAST): Implementing SAST tools can help detect vulnerabilities early in the development lifecycle.
4、Dependency Update Tool: Utilizing a dependency update tool ensures your project uses the latest secure library versions.
5、Security Policy: Defining a comprehensive security policy (SECURITY.md) with vulnerability reporting guidelines, coding standards, and response procedures is recommended.

For more information on specific checks, see the OpenSSF Scorecard documentation: https://github.com/ossf/scorecard/blob/main/docs/checks.md#check-documentation

[echoix]

These are great general ideas, and I'll be glad to review them in a PR!

[fredgan]

Hi, @echoix
You are right, these are good ideas.

As far as I know from the docs, most of the security points are security settings which only setted by the administrator of the repo. Such as the Branch Protect, Code Security Scan and Dependency Update Tool (dependabot in GitHub). We users can't do anything but just tell how to do it.

And Security Policy is a SECURITY.md which we can help to submit a PR. However, the content should contain a link or an email shows where vulnerability reporting to and vulnerability publishment at. The key information about the link or email should provided by you maintainers.

The docs is a bit long, Hoping you can read it carefully. That's it.

[fredgan]

Hi @echoix , I wrote some important but easy checkpoints:

Security Policy

It is highly recommended to define a comprehensive security policy (SECURITY.md) in the root directory. This policy should include guidelines for vulnerability reporting and vulnerability publishment.

You can do it in the Security page which will give you a template file, just put some key informations in the SECURITY.md and commit it.

SAST

Implementing SAST tools is crucial as it allows us to detect vulnerabilities at an early stage of the development cycle.

You can check it in the Settings - Code Security page. You can enable the Code scanning . Also, you can enable some other options as you like, such as Secret Protection.

Branch Protection

The Scorecard showed this repo didn't protect the important branch,such as the main or master branch. The main branch should be protected because it should not be deleted or forced pushed by mistaken. But I'm not sure if this repo has set this or not.

You can check it in the Settings - Branches page, You can click the Add branch ruleset or Add classic branch protection rule to protect one or more branches.

That's it. Maybe you can check these points.

[echoix]

Security policy seems a good idea, and even if it's quite simple, as the maintaining team is still small. But I think a greater usefulness is to set up the private vulnerability disclosure/reporting functionality. At least to have a channel in place. That security policy could also have a means to contact to ask for an alternate communication channel, if that user doesn't trust that standard reporting channel.

I don't feel like we can promise anything to users, timelines or actions, especially for really older releases, but we can at least promise to act in good faith and proportionally to the severity of the issue reported.

Sast: Yet still lots to do in CI for this and way other things (like running the tests), but is a good goal nonetheless.

Branch protection: Classic protection rules shouldn't really be set up, they'll be going away at one point. The rulesets are at least visible publicly to understand what's going on.

[fredgan]

I agree. @echoix Can you do something settings for this? Or do you have github access permissions for this? Or Need I @RobinD42 to look at this issue?

[echoix]

I don't have any access here. @swt2c has enough access here I think, Robin is not present anymore, or very distant now since giving access to Scott.

[swt2c]

I added a branch protection rule to block force-pushes and deleting refs on the default branch.

[fredgan]

@swt2c Thanks for your concerning about the security rules. How do you think about the Security Policy point? Would you mind adding a SECURITY.md to the root directory?

[swt2c]

I enabled Private Vulnerability Reporting on GitHub. I'm not sure what else I would say in a SECURITY.md file.

[fredgan]

@swt2c I created two PRs:

• Create SECURITY.md #2738 This is a PR creating SECURITY.md file telling users to report vulnerabilities in the Private Vulnerability Reporting on Github.
• Create LICENSE file in the root #2737 This is a PR creating LICENSE file telling users to know the license of this project easily.

These follow general open source software best practices.

[Metallicow]

I have been sent a account denial. I would like to know what it is about. Outsiders who are not logged in cannot see it...

[Metallicow]

It stipulates I should apologize to someone, although that may not be possible if you happened to be the one who threatened us. This is a confusing manner, and I am not afraid to defend myself for the upteenth time. Legal recourse may be needed if a human being cannot respond. I hope triage and those reading this understand.

[Metallicow]

@swt2c I hope you can do the job as a leader not a follower. I expect a response from you. I will not be attacked again. Thanks.

[Metallicow]

Rules 2,3,4,5,8,11

https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies

I hope I have made broken rules clear.
If you would like to respond personally, then respond to my email, not some service provider junkie or GitHub fanboy.

Thank you.