JHipster

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

If this is your project, please show your badge status on your project page! The badge status looks like this: Badge level for project 2159 is passing Here is how to embed it:

These are the Passing level criteria. You can also view the Silver or Gold level criteria.

        

 Basics 13/13

  • Identification

    Open Source application generator for creating Spring Boot + Angular/React projects in seconds!

    What programming language(s) are used to implement the project?
  • Basic project website content


    The project website MUST succinctly describe what the software does (what problem does it solve?). [description_good]

    The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. [interact]

    The information on how to contribute MUST explain the contribution process (e.g., are pull requests used?) (URL required) [contribution]

    The information on how to contribute SHOULD include the requirements for acceptable contributions (e.g., a reference to any required coding standard). (URL required) [contribution_requirements]
  • FLOSS license

    What license(s) is the project released under?



    The software produced by the project MUST be released as FLOSS. [floss_license]

    https://github.com/jhipster/generator-jhipster/blob/master/LICENSE.txt The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    It is SUGGESTED that any required license(s) for the software produced by the project be approved by the Open Source Initiative (OSI). [floss_license_osi]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    The project MUST post the license(s) of its results in a standard location in their source repository. (URL required) [license_location]
  • Documentation


    The project MUST provide basic documentation for the software produced by the project. [documentation_basics]

    The project MUST provide reference documentation that describes the external interface (both input and output) of the software produced by the project. [documentation_interface]
  • Other


    The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. [sites_https]

    Given only https: URLs.



    The project MUST have one or more mechanisms for discussion (including proposed changes and issues) that are searchable, allow messages and topics to be addressed by URL, enable new people to participate in some of the discussions, and do not require client-side installation of proprietary software. [discussion]

    The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. [english]

    Everything we do is in English. See https://www.jhipster.tech/help/ for example.



    The project MUST be maintained. [maintained]


(Advanced) What other users have additional rights to edit this badge entry? Currently: []



  • Public version-controlled source repository


    The project MUST have a version-controlled source repository that is publicly readable and has a URL. [repo_public]

    The project's source repository MUST track what changes were made, who made the changes, and when the changes were made. [repo_track]

    To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. [repo_interim]

    It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. [repo_distributed]

    Yes we use Git


  • Unique version numbering


    The project results MUST have a unique version identifier for each release intended to be used by users. [version_unique]

    It is SUGGESTED that the Semantic Versioning (SemVer) or Calendar Versioning (CalVer) version numbering format be used for releases. It is SUGGESTED that those who use CalVer include a micro level value. [version_semver]


    It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. [version_tags]

    Each release on https://www.jhipster.tech/releases/ is linked to a Git tag, with the same version, that's part of the release process


  • Release notes


    The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL required) [release_notes]

    Here are all our release notes: https://www.jhipster.tech/releases/



    The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. [release_notes_vulns]
  • Bug-reporting process


    The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL required) [report_process]

    The project SHOULD use an issue tracker for tracking individual issues. [report_tracker]

    The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. [report_responses]

    See https://github.com/jhipster/generator-jhipster/issues - at the moment of this writing we have 36 open bugs out of 4,331 closed bugs. As you can see, we usually fix bugs in a matter of hours/days. If it's a major issue, we usually have a release in the following day.



    The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). [enhancement_responses]

    Same thing as above, see https://github.com/jhipster/generator-jhipster/labels/enhancement -> we have 5 enhancements requests open and 443 closed. They are usually done within a week.



    The project MUST have a publicly available archive for reports and responses for later searching. (URL required) [report_archive]

    We use the issue tracker for that https://github.com/jhipster/generator-jhipster/issues - everything is available and searchable there


  • Vulnerability report process


    The project MUST publish the process for reporting vulnerabilities on the project site. (URL required) [vulnerability_report_process]

    See https://www.jhipster.tech/help/ -> usually people just submit a bug report, but sometimes if that's really urgent they contact us on Twitter



    If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL required) [vulnerability_report_private]

    We don't have private vulnerability reports, everything is public on the project.



    The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. [vulnerability_report_response]

    Usually we do this in the next day, never more than 3 days for sure.


  • Working build system


    If the software produced by the project requires building for use, the project MUST provide a working build system that can automatically rebuild the software from source code. [build]

    It's built with NPM/Yarn, and what we generate is built with Maven/Gradle (for the Java part) and NPM/Yarn (for the front-end part)



    It is SUGGESTED that common tools be used for building the software. [build_common_tools]

    NPM/Yarn/Maven/Gradle are all very common tools



    The project SHOULD be buildable using only FLOSS tools. [build_floss_tools]

    NPM/Yarn/Maven/Gradle are all FLOSS


  • Automated test suite


    The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). The project MUST clearly show or document how to run the test suite(s) (e.g., via a continuous integration (CI) script or via documentation in files such as BUILD.md, README.md, or CONTRIBUTING.md). [test]

    The full test suite is at https://github.com/jhipster/generator-jhipster/tree/master/test But we do far better, with complete integration testing on Travis, and the code is at https://github.com/jhipster/generator-jhipster/tree/master/travis - the script at https://github.com/jhipster/generator-jhipster/blob/master/travis/build-samples.sh allow people to test the Travis build locally



    A test suite SHOULD be invocable in a standard way for that language. [test_invocation]

    Just run "yarn test" or "npm test"



    It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. [test_most]

    For the final tests (this includes the integration tests), Sonar says we have 84,5% of coverage at the date of this writing. The live report is at https://sonarcloud.io/dashboard?id=io.github.jhipster.sample%3Ajhipster-sample-application (it's re-generated with each commit)



    It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). [test_continuous_integration]
  • New functionality testing


    The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. [test_policy]

    The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. [tests_are_added]

    We don't allow major features without tests. Anyway it wouldn't pass the Sonar quality gate at https://sonarcloud.io/dashboard?id=io.github.jhipster.sample%3Ajhipster-sample-application



    It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. [tests_documented_added]
  • Warning flags


    The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. [warnings]

    We have a lint in our test suite at https://github.com/jhipster/generator-jhipster/tree/master/test - it's just not possible to pass the tests (that's the first test in our Travis test) if there is a lint error



    The project MUST address warnings. [warnings_fixed]

    We don't allow warnings, see the above section about the "lint", it can't go pass the tests, so the PR will not be processed



    It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. [warnings_strict]

    We are very strict and don't allow them at all


  • Secure development knowledge


    The project MUST have at least one primary developer who knows how to design secure software. (See ‘details’ for the exact requirements.) [know_secure_design]

    I'm the lead developer so I'm the primary developer. I've got 20 years of experience, worked for several very high security systems (including several software for the French central bank), and I am a Java Champion (see https://community.oracle.com/community/technology_network_community/java/java-champions ). In the core team we also have Matt Raible, who is also a Java Champion, and who works for https://www.okta.com/



    At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. [know_common_errors]

    As written above, me & Matt Raible are worldwide recognized experts in that field.


  • Use basic good cryptographic practices

    Note that some software does not need to use cryptographic mechanisms. If your project produces software that (1) includes, activates, or enables encryption functionality, and (2) might be released from the United States (US) to outside the US or to a non-US-citizen, you may be legally required to take a few extra steps. Typically this just involves sending an email. For more information, see the encryption section of Understanding Open Source Technology & US Export Controls.

    The software produced by the project MUST use, by default, only cryptographic protocols and algorithms that are publicly published and reviewed by experts (if cryptographic protocols and algorithms are used). [crypto_published]

    As you can see in https://github.com/jhipster/generator-jhipster/blob/master/generators/server/templates/src/main/java/package/security/jwt/TokenProvider.java.ejs we use java.security.Key as well as strong encryption provided by https://github.com/jwtk/jjwt for securing our tokens. FYI the algorithm is HMAC-SHA-512. This is done with the help of Okta, where Matt Raible and the lead JJWT developer both work.



    If the software produced by the project is an application or library, and its primary purpose is not to implement cryptography, then it SHOULD only call on software specifically designed to implement cryptographic functions; it SHOULD NOT re-implement its own. [crypto_call]

    All functionality in the software produced by the project that depends on cryptography MUST be implementable using FLOSS. [crypto_floss]

    The security mechanisms within the software produced by the project MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012). It MUST be possible to configure the software so that smaller keylengths are completely disabled. [crypto_keylength]

    That's provided by https://github.com/jwtk/jjwt - the library will fail if you provide a key which is too short. So for HMAC-SHA-512 (our algorithm) this is 512 bytes. And if the library fails our software does not start, of course.



    The default security mechanisms within the software produced by the project MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are inappropriate to the context, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol. [crypto_working]

    This is HMAC-SHA-512 and that's not broken yet



    The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode in SSH). [crypto_weaknesses]

    This is HMAC-SHA-512 and it's good as of now



    The security mechanisms within the software produced by the project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. [crypto_pfs]

    This doesn't make sense for us, this is for securing a webapp and the default validity for a key is 30 minutes...



    If the software produced by the project causes the storing of passwords for authentication of external users, the passwords MUST be stored as iterated hashes with a per-user salt by using a key stretching (iterated) algorithm (e.g., Argon2id, Bcrypt, Scrypt, or PBKDF2). See also OWASP Password Storage Cheat Sheet. [crypto_password_storage]

    The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure. [crypto_random]

    We use the crypto function from NodeJS to generate the key, see https://github.com/jhipster/generator-jhipster/blob/4a3184ae352cec0a26f696d75a4c34992552a654/generators/server/prompts.js#L288 But we recommend our users to generate their own key and not use this one, which is just there for development purpose


  • Secured delivery against man-in-the-middle (MITM) attacks


    The project MUST use a delivery mechanism that counters MITM attacks. Using https or ssh+scp is acceptable. [delivery_mitm]

    A cryptographic hash (e.g., a sha1sum) MUST NOT be retrieved over http and used without checking for a cryptographic signature. [delivery_unsigned]

    If you follow our documentation above, this is not possible as you use TLS


  • 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. [vulnerabilities_fixed_60_days]

    You can check at https://github.com/jhipster/generator-jhipster/issues there's nothing at the moment



    Projects SHOULD fix all critical vulnerabilities rapidly after they are reported. [vulnerabilities_critical_fixed]

    Usually we do this 1 to 3 days after a vulnerability


  • Other security issues


    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. [no_leaked_credentials]

    There's no such thing in our GitHub repo. Yes there are sample credentials, but they are only there to show how things work, and they are documented as such.


  • 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. [static_analysis]

    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. [static_analysis_common_vulnerabilities]

    All medium and higher severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. [static_analysis_fixed]

    Yes that's what we do, and in the https://sonarcloud.io/project/issues?id=io.github.jhipster.sample%3Ajhipster-sample-application&resolved=false&types=VULNERABILITY report it's currently empty, with an empty history (and they keep track for the last 30 days)



    It is SUGGESTED that static source code analysis occur on every commit or at least daily. [static_analysis_often]

    That's on every commit, this is automatically run by Travis with this script: https://github.com/jhipster/generator-jhipster/blob/v5.2.1/travis/scripts/06-sonar.sh


  • 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. [dynamic_analysis]

    We use OWASP with each major release, even if the tool is pretty bad



    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). [dynamic_analysis_unsafe]

    We use JavaScript so that should be good



    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]

    I'm pretty sure OWASP does this



    All medium and higher severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. [dynamic_analysis_fixed]

    Yes but OWASP never found anything



This data is available under the Creative Commons Attribution version 3.0 or later license (CC-BY-3.0+). All are free to share and adapt the data, but must give appropriate credit. Please credit Julien Dubois and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Julien Dubois.
Entry created on 2018-08-31 13:05:36 UTC, last updated on 2018-08-31 14:15:35 UTC. Last achieved passing badge on 2018-08-31 14:15:35 UTC.

Back