Release 5.1.0 (includes #187) #190
Conversation
This allows setting fail-threshold to -1 which will result in a failure in case only vulnerabilities with a score of 0 were detected. This is a pertty common occurrence these days as the NVD struggles to keep up with assigning scores to newly reported CVEs in a timely manner.
While at it, make wording of fail-threshold doc less ambiguous. Co-authored-by: Toby Crawley <toby@tcrawley.org>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @tobias, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request prepares the project for its 5.1.0 release by implementing a significant enhancement to its vulnerability scanning capabilities. It introduces a mechanism to fail builds when vulnerabilities with a CVSS score of 0 are detected, which is crucial for proactive security. Additionally, the PR includes an update to a core dependency and comprehensive documentation and versioning updates to align with the new release.
Highlights
- Enhanced Vulnerability Reporting: Introduced a new
fail-thresholdvalue of-1. This allows the build to fail if any vulnerabilities are detected, including those with a CVSS score of 0. This is particularly useful for catching newly reported CVEs that haven't yet been assigned a score by the NVD, addressing a common challenge with timely vulnerability scoring. - Core Dependency Update: Updated the underlying
dependency-check-corelibrary from version 12.1.0 to 12.1.3, bringing in the latest improvements and fixes from the upstream project. - Documentation and Versioning Updates: Updated the README, issue templates, changelog, and project configuration files to reflect the new 5.1.0 version. This includes clarifying the behavior of the
fail-thresholdoption and updating all relevant version references across the repository.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
|
I approved for unblocking, but don't have time to review unfortunately Either way, thanks for taking care of this! |
There was a problem hiding this comment.
Code Review
This pull request prepares for the 5.1.0 release. It includes updates to version numbers across the project and introduces a new feature to allow failing the build for vulnerabilities with a CVSS score of 0 by setting fail-threshold: -1. The logic for this feature is sound and also fixes a potential bug where a build could fail with no vulnerabilities if the threshold was negative. The documentation has been updated accordingly. I've suggested a minor clarification to the README to more accurately describe the use case for the new setting.
Pull Request Test Coverage Report for Build 15885432677Details
💛 - Coveralls |
1 similar comment
Pull Request Test Coverage Report for Build 15885432677Details
💛 - Coveralls |
Don't fail when no vulnerabilities were detected
This allows setting fail-threshold to -1 which will result in a failure in case only vulnerabilities
with a score of 0 were detected. This is a pertty common occurrence these days as the NVD struggles
to keep up with assigning scores to newly reported CVEs in a timely manner.
Update README to mention fail-threshold -1
While at it, make wording of fail-threshold doc less ambiguous.
Co-authored-by: Toby Crawley toby@tcrawley.org
Prep for 5.1.0 release
This includes the changes from #187.