Hello, interact.js developer,
When OpenSSF Scorecard is used to evaluate the health of third-party software, the scorecard of the interact.js file is 3.20/10. Therefore, this issue is raised to enhance the security of the interact.js file.
Some recommended improvements:
Branch protection (Branch-Protection, 3: branch protection not enabled on development/release branches):https://docs.github.com/zh/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
Security-Policy:https://docs.github.com/zh/code-security/getting-started/adding-a-security-policy-to-your-repository
https://github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy
Dependent upgrade tool (Dependency-Update-Tool):https://docs.github.com/zh/code-security/dependabot/working-with-dependabot/dependabot-options-reference
https://blog.csdn.net/fengbingchun/article/details/125962588
Signed-Releases:https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases
[https://wiki.debian.org/Creating%20signed%20GitHub%20releases](https://wiki.debian.org/Creatingsigned GitHub releases)
CI-test and SAST are also worthy of attention. The check of project code is also very positive, but more efforts are required.
CI-test:https://github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests
https://docs.github.com/zh/actions
SAST:https://github.com/ossf/scorecard/blob/main/docs/checks.md#sast
https://codeql.github.com/docs/codeql-language-guides/codeql-for-javascript/
Details of the assessment are as follows:
| Name |
Description |
Risk Level |
Token Required |
GitLab Support |
interact.js Score (3.20/10) |
| Binary-Artifacts |
Is the project free of checked-in binaries? |
High |
PAT, GITHUB_TOKEN |
Supported |
10/10 |
| Branch-Protection |
Does the project use Branch Protection ? |
High |
PAT (repo or repo> public_repo), GITHUB_TOKEN |
Supported (see notes) |
3/10 |
| CI-Tests |
Does the project run tests in CI, e.g. GitHub Actions, Prow? |
Low |
PAT, GITHUB_TOKEN |
Supported |
0/10 |
| CII-Best-Practices |
Has the project earned an OpenSSF (formerly CII) Best Practices Badge at the passing, silver, or gold level? |
Low |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
| Code-Review |
Does the project practice code review before code is merged? |
High |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
| Contributors |
Does the project have contributors from at least two different organizations? |
Low |
PAT, GITHUB_TOKEN |
Validating |
10/10 |
| Dangerous-Workflow |
Does the project avoid dangerous coding patterns in GitHub Action workflows? |
Critical |
PAT, GITHUB_TOKEN |
Unsupported |
10/10 |
| Dependency-Update-Tool |
Does the project use tools to help update its dependencies? |
High |
PAT, GITHUB_TOKEN |
Unsupported |
0/10 |
| Fuzzing |
Does the project use fuzzing tools, e.g. OSS-Fuzz, QuickCheck or fast-check? |
Medium |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
| License |
Does the project declare a license? |
Low |
PAT, GITHUB_TOKEN |
Validating |
10/10 |
| Maintained |
Is the project at least 90 days old, and maintained? |
High |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
| Packaging |
Does the project build and publish official packages from CI/CD, e.g. GitHub Publishing ? |
Medium |
PAT, GITHUB_TOKEN |
Validating |
-1/10 |
| Pinned-Dependencies |
Does the project declare and pin dependencies? |
Medium |
PAT, GITHUB_TOKEN |
Validating |
9/10 |
| SAST |
Does the project use static code analysis tools, e.g. CodeQL, LGTM (deprecated), SonarCloud? |
Medium |
PAT, GITHUB_TOKEN |
Unsupported |
0/10 |
| Security-Policy |
Does the project contain a security policy? |
Medium |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
| Signed-Releases |
Does the project cryptographically [sign releases](https://wiki.debian.org/Creating signed GitHub releases)? |
High |
PAT, GITHUB_TOKEN |
Validating |
-1/10 |
| Token-Permissions |
Does the project declare GitHub workflow tokens as read only? |
High |
PAT, GITHUB_TOKEN |
Unsupported |
0/10 |
| Vulnerabilities |
Does the project have unfixed vulnerabilities? Uses the OSV service. |
High |
PAT, GITHUB_TOKEN |
Validating |
0/10 |
Hi interact.js Maintainers,
I'm reaching out because I appreciate your work on ViewUIPlus. As open-source security is a growing concern, I'd like to suggest some improvements based on the OpenSSF Scorecard best practices:
· Token Permissions: Consider implementing explicit token permissions within the workflow to avoid over-permissioning vulnerabilities.
· Pinned Dependencies: Using a commit hash instead of @v4 for the third-party library can mitigate breaking changes or vulnerabilities in future updates.
· Branch Protection & Code Review: Enabling branch protection rules and code reviews can minimize the risk of introducing vulnerabilities. Refer to your repository settings for configuration options.
· Static Application Security Testing (SAST): Implementing SAST tools can help detect vulnerabilities early in the development lifecycle.
· Dependency Update Tool: Utilizing a dependency update tool ensures your project uses the latest secure library versions.
· 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: Link to Documentation
Thank you again for your contributions to the open source community. We look forward to working with you to improve project security.
Hello, interact.js developer,
When OpenSSF Scorecard is used to evaluate the health of third-party software, the scorecard of the interact.js file is 3.20/10. Therefore, this issue is raised to enhance the security of the interact.js file.
Some recommended improvements:
Branch protection (Branch-Protection, 3: branch protection not enabled on development/release branches):https://docs.github.com/zh/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
Security-Policy:https://docs.github.com/zh/code-security/getting-started/adding-a-security-policy-to-your-repository
https://github.com/ossf/scorecard/blob/main/docs/checks.md#security-policy
Dependent upgrade tool (Dependency-Update-Tool):https://docs.github.com/zh/code-security/dependabot/working-with-dependabot/dependabot-options-reference
https://blog.csdn.net/fengbingchun/article/details/125962588
Signed-Releases:https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases
[https://wiki.debian.org/Creating%20signed%20GitHub%20releases](https://wiki.debian.org/Creatingsigned GitHub releases)
CI-test and SAST are also worthy of attention. The check of project code is also very positive, but more efforts are required.
CI-test:https://github.com/ossf/scorecard/blob/main/docs/checks.md#ci-tests
https://docs.github.com/zh/actions
SAST:https://github.com/ossf/scorecard/blob/main/docs/checks.md#sast
https://codeql.github.com/docs/codeql-language-guides/codeql-for-javascript/
Details of the assessment are as follows:
Hi interact.js Maintainers,
I'm reaching out because I appreciate your work on ViewUIPlus. As open-source security is a growing concern, I'd like to suggest some improvements based on the OpenSSF Scorecard best practices:
· Token Permissions: Consider implementing explicit token permissions within the workflow to avoid over-permissioning vulnerabilities.
· Pinned Dependencies: Using a commit hash instead of @v4 for the third-party library can mitigate breaking changes or vulnerabilities in future updates.
· Branch Protection & Code Review: Enabling branch protection rules and code reviews can minimize the risk of introducing vulnerabilities. Refer to your repository settings for configuration options.
· Static Application Security Testing (SAST): Implementing SAST tools can help detect vulnerabilities early in the development lifecycle.
· Dependency Update Tool: Utilizing a dependency update tool ensures your project uses the latest secure library versions.
· 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: Link to Documentation
Thank you again for your contributions to the open source community. We look forward to working with you to improve project security.