...
A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature.
-> yes
## Publicly known vulnerabilities fixed
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
-> yes
Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.
-> yes
The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.
-> yes
## Static code analysis
At least one static code analysis tool (beyond compiler warnings and "safe" language modes) MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language.
-> yes SonarCloud and Spotbugs
It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment.
-> yes Sonarcloud
All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed
-> yes
It is SUGGESTED that static source code analysis occur on every commit or at least daily.
-> no weekly report
## Dynamic code analysis
It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
-> no
It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A)
-> N/A Java is memory-safe
It is SUGGESTED that the project use a configuration for at least some dynamic analysis (such as testing or fuzzing) which enables many assertions. In many cases these assertions should not be enabled in production builds. [dynamic_analysis_enable_assertions]
-> no
All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed.
-> N/A