esapi-java-legacy

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 137 is in_progress 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

    ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications.

    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]

    https://github.com/ESAPI/esapi-java-legacy, specifically in the README.md which is displayed on that page.



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

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



    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]

    See "How can I contribute or help with bug fixes?" section of https://github.com/ESAPI/esapi-java-legacy/blob/develop/README.md


  • FLOSS license

    What license(s) is the project released under?



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

    The BSD-3-Clause license is approved by the Open Source Initiative (OSI).

    Note that documentation is released under Creative Commons BY-SA licenses (2.0, 3.0, and 4.0, depending on when authored). The BSD-3-Clause 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 BSD-3-Clause 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]

    Most of the documentation on ESAPI may be found under https://github.com/ESAPI/esapi-java-legacy/tree/develop/documentation. Since ESAPI is a widely used Java API, the latest Javadoc (which is the low-level documentation for its use) is available at https://www.javadoc.io/doc/org.owasp.esapi/esapi/. Additional ESAPI documentation (e..g,, the ESAPI-AppSensor integration) is referenced off the main ESAPI page on the OWASP wiki site.



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

    The low-level API documentation for ESAPI is available at https://www.javadoc.io/doc/org.owasp.esapi/esapi/


  • 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]

    GitHub supports discussions on issues and pull requests. As of 2022-05-10, we also added a GitHub Discussions board.



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

    The README.md file, displayed on the main GitHub page at https://github.com/ESAPI/esapi-java-legacy describes all of this.



    The project MUST be maintained. [maintained]


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



We have a lot of documentation, but 1) much of it is outdated, 2) much of it is disorganized and/or hard to find, and 3) a lot of it is not the "right" documentation to serve the intended audience (e.g., I'm thinking of developer user guides here in the "how to use sense").

  • Public version-controlled source repository


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

    Repository on GitHub, which provides public git repositories with URLs. See https://github.com/ESAPI/esapi-java-legacy for details.



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

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    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]

    On-going development and bug-fixes are made on the (default) 'develop' branch. The latest official release is available on the 'master' branch. We also have tagged releases based on release # and have branches corresponding to each release #.



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

    Repository on GitHub, which uses git. git is distributed.


  • Unique version numbering


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

    Release #s are updated according to semantic versioning format for each release. The latest (possibly unstable) release is available from the (default) 'develop' branch. The latest previous official release is available from the 'master' branch.



    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]

    Done with git tags. Also each tag corresponding to an official release has a corresponding Git branch.


  • 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]

    The changelog is usually incorporated into the release notes. For the latest release notes, see https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-core-2.1.0.1-release-notes.txt



    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]

    There was some dispute over whether or not https://github.com/ESAPI/esapi-java-legacy/issues/354 was considered a vulnerability or not. We did not seek getting a CVE for this because it was the same type of Java deserialization issue as was Apache Commons COLLECTIONS-580 bug, which Mitre supposed refused to issue a CVE for. (Not to mention that getting a CVE is a royal PITA!) We did announce this one the 2 ESAPI public mailing lists shortly after I created the GitHub issue for it. That code was closed on 2016-01-19 by removing the vulnerable method as I decided it was too dangerous to leave in only a deprecated state for 2 whole years (as per our normal deprecation policy). Other vulnerabilities, are discussed in detail in published security bulletins and summarized in https://github.com/ESAPI/esapi-java-legacy/blob/develop/Vulnerability-Summary.md, which is referenced from our project README file.


  • 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]

    GitHub issues: https://github.com/ESAPI/esapi-java-legacy/issues/new is the preferred way, but we have had users announce bugs on the mailing lists. In those cases, one of the ESAPI contributors will turn those into a GitHub issue. There are plans to integrate with an instance of Atlassian's JIRA, but the synchronization of that with GitHub failed and so we are back to using GitHub Issues alone at the moment.



    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]

    ESAPI contributors get email and can respond directly via there or via GitHub. Note that we may have some bugs from the very early days that contributors created that were not formally acknowledged. Generally those were ones that one contributor asked another contributor via email to file a bug report using Google Code (which we were using back then). However, since moving things to GitHub and getting a few additional contributors, we have been doing better.



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

    Same way as previous question.



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

    GitHub issues (https://github.com/ESAPI/esapi-java-legacy/issues) are searchable. In addition, the two ESAPI mailing lists are archived and searchable as well. And as of 2022-05-10, we now support a GitHub Discussions board at https://github.com/ESAPI/esapi-java-legacy/discussions


  • Vulnerability report process


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

    The process for reporting vulnerabilities is now described in the README.md file which is displayed on the main GitHub page at https://github.com/ESAPI/esapi-java-legacy. The ESAPI security vulnerability reporting process is also described at https://github.com/ESAPI/esapi-java-legacy/security/policy



    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]

    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]

    Met. Some details may be found at https://github.com/ESAPI/esapi-java-legacy/security/advisories?state=published. Technically, I guess we didn't "respond" to the one at https://github.com/ESAPI/esapi-java-legacy/security/advisories/GHSA-q77q-vx4q-xx6q, but that's because Kevin Wall (one of the ESAPI project co-leads) reported it himself.


  • 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]

    Non-trivial build file in repository: https://github.com/ESAPI/esapi-java-legacy/blob/develop/pom.xml. Starting with ESAPI 2.3.0.0, we now also distribute ESAPI with a CycloneDX SBOM file that is uploaded to Maven Central.



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

    Non-trivial build file in repository: https://github.com/ESAPI/esapi-java-legacy/blob/develop/pom.xml. All tools required to build the software are available under FLOSS licenses. Only Maven 3.3.9 or later and Java 8 or later (we use OpenJDK, but any version should work) is be needed to build ESAPI and run the JUnit tests. (Maven will pull in the rest of the dependencies.)



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

    OpenJDK, Maven, JUnit, and various FLOSS 3rd party Java libraries such as various Apache Commons libraries, etc.


  • 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]

    As of release 2.5.0.0, there are now 4274 JUnit tests in 131 Java source files (with 0 tests skipped)'mvn test' and all tests passing. There is also a GitHub CI/CD workflow that executes 'mvn -B package --file pom.xml' every time a git PR is created.



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

    mvn test



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

    70% code coverage as measured by coveralls.io (under https://coveralls.io/github/bkimminich/esapi-java-legacy?branch=develop)



    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 (unfortunately) has a small enough # of contributors on the team that this is well understood. That said, no new major functionality is intended for esapi-java-legacy (i.e., ESAPI 2.x releases). Any new functionality will be done under ESAPI 3.0 (https://github.com/ESAPI/esapi-java) that is a project that will not [or, at least very unlikely] be backward compatible with ESAPI 2.x releases. However, we believe this is also applicable to bug fixes as well and as such, have updated Step 4 in the CONTRIBUTING-TO-ESAPI.txt file to mention adding JUnit tests to confirm fixes.



    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]

    Really, not applicable as no new functionality is planned / intended. See above question for details. (Seriously, I'm having enough trouble just getting enough people to address bug fixes.)



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

    Again, N/A. See the two previous questions.


  • 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]

    The next official ESAPI major release will include '-Xlint:all' in the pom.xml. Since the latest release (2.2.0.0), we have been using '-Xlint:all,-deprecation,-rawtypes,-unchecked'.



    The project MUST address warnings. [warnings_fixed]

    Addressed with the exceptions of the warnings that are currently (deliberately) ignored; see previous question. This is being addressed now, but we currently do not have it ALL.



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

    Toying with the idea of also adding '-Werror' to terminate compilation if there are any ideas, but need to bounce that idea off the other contributors first before deciding on anything definitive.


  • 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]

    Both project co-leaders (Kevin W. Wall and Matt Seilt) are experienced professional appsec engineers who have been 10+ years of application security experience.



    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]

    ESAPI in fact is designed to address common appsec errors such as OT10. E.g., see slide 3 in https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/esapi4java-2.0-javadoc-pictures.pptx


  • 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]

    By DEFAULT, only AES is enabled. Users however, could in principle, add whatever stupid symmetric encryption algorithm is supported by some JVE implementation, like SuperRoysSecretSnakeOilCryptoSauce that requires a 1M bit key and implements a pseudo-one time pad. Let's face it, there is no patch for stupidity. It's open source, so if we tried to white-list algorithms, people could just rewrite that part of the source code and recompile.



    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]

    We rely on JCE implementations, such as SunJCE or BouncyCastle, etc. We provide more user friendly wrappers around the JCE crypto so that people don't have to understand what cipher modes and IVs and padding schemes are all about. We also provide an encrypt-then-MAC approach to CBC mode for earlier versions of JDK that don't support out-of-the-box authenticated encryption modes and for projects that are not permitted to use alternative FLOSS JCE implementations such as BouncyCastle.



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

    SunJCE (available as part of OpenJDK) or BouncyCastle are both FLOSS JCE implementations.



    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]

    The default min key size is 128 bits for AES, or either 112 bit, 2-key TDES for DESede (or 3-key if the JCE Unlimited Strength Jurisdiction Polciy files are installed as part of the JRE.



    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]

    Use SHA-256 by default for most hashing, but users can decide by tweaking properties in ESAPI.properties to use whatever MessageDigest or Mac that is available. (Again, we do not try to prevent stupidity this being open source, but we do try to make it intentional if you want to shoot off your own foot.)



    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]

    We do use HMacSHA1, but according to Bellare, Canetti & Krawczyk (1996), this should still be secure as they showed that HMAC security doesn’t require that the underlying hash function be collision resistant, but only that it acts as a pseudo-random function. (Or at least that was my take away when I read it 10+ years ago. But if I'm wrong, please advise. We wanted an HMAC value that was short as possible, but HMAC-MD5 just didn't feel right.) We also use SecureRandom to generate random #s for things like IVs, etc. which ought to be okay even though it uses SHA1PRNG as its CSRNG.



    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]

    We currently do not do any sort of key-agreement. All symmetric encryption is assumed to use pre-shared keys, presumably shared out-of-band. This is something that is being considered for ESAPI 3.0 though.



    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]

    We don't store passwords per se, except temporally for unit testing (created by FileBasedAuthenticator) where they are hashed with per-user random salt.



    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 an implementation of NIST SP 800-108 Key Derivation Function (which uses SHA-256 for it's CSPRNG under the hood.) Design and implementation details are available at: https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/Analysis-of-ESAPI-2.0-KDF.pdf


  • 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]

    We enforce either https: for all our ESAPI-related web sites or https or ssh from the git command line. Also, in several ESAPI classes, we ensure that the client is using https.



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

    ESAPI is downloaded from https://search.maven.org/#search%7Cga%7C1%7Cesapi. The jar is signed by my (Kevin Wall's) private key. My public key is available from the MIT key server should anyone actually wish to confirm it. (Yeah; right. Sigh.)


  • 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]

    As of ESAPI 2.5.0.0, there are no now true positives identified as vulnerabilities in ESAPI. (As of the 2.5.0.0 release, we completely removed the Log4J 1.2.17 dependency.) It only took us 2 years to remove it because that is our formal deprecation policy and it would have broken many client applications. (We also confirmed there were no exploitable CVEs related to Log4J in our standard configuration.)

    However, there are still occasional false positives flagged by various Software Compositional Analysis (SCA) tools / services (e.g., OWASP Dependency Check, BlackDuck, Verisign SourceClear, Snyk, Sonatype NexusIQ, etc.) that flag ESAPI as being vulnerable to some CVE or another. These are almost always in a transitive dependency. We thoroughly investigate these and either proceed to remediate them, or if they are false positives, explain the rationale as to why they are not exploitable in a security bulletin and then reference that in the Vulnerability-Summary.md file.

    CVE-2013-5960 is still unfixed even though NIST says that it was fixed 2.1.0.1 (which is true for the default ESAPI configuration), but CVE-2013-5960 is actually a design flaw, not a coding bug, and I (the author) do not really believe that the core issue has been remediated even though I believe that NIST / MITRE got the CVSSv2 score wrong. (But what point is there disputing that since they think it is already closed.) But the reason it is not exploitable in the default configuration is that only Authenticated Encryption cipher modes (GCM, CCM, IAPM, EAX, OCB, and CWC) are offered in the default configuration and the only non-AE mode offered by default is CBC. The PoC exploit code exploit for CVE-2013-5960 required OFB mode to be added to the ESAPI.properties file as a non-AE cipher mode. One may be able to do that via social engineering, but that should reflect a lower CVSSv2 score.

    in that the CVSSv2 base score is 5.8 but I would contend that they did not take into account that one needs to convince the intended victim to first accept additional non-authenticated cipher modes and, place them in the ESAPI.properties file. Could happen, but that social engineering side was not taken into the equation.

    Note that correctly fixing CVE-2013-5960 requires a major redesign in the encrypt-then-MAC calculation. When I started looking at it more deeply, I realized there were additional things that should be MAC'd as well such as the version #, etc. (I since have become aware of Schneier & Ferguson's Horton Principle and am making design changes as a result.) Doing it securely in a manner that can be backward compatible is tough and it would be nice to have someone else with some applied cryptography knowledge since Jeffrey Walton is no longer contributing toward OWASP.

    However, I am marking this as 'met' because I think even if NIST had left this as open, had the adjusted it for the DEFAULT ESAPI configuration, the CVSSv2 score would have been LOW rather than MEDIUM.



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

    You'll get no argument from me. But given that ESAPI all but died (see https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=Should_I_use_ESAPI_3F and http://off-the-wall-security.blogspot.com/2014/03/esapi-no-longer-owasp-flagship-project.html), I'm happen that it's at least still crawling along. Any help is always appreciated!


  • 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]

    We store no passwords or private keys on any public repositories. My private signing key is encrypted on my GPG keyring and that passphrase is stored in PasswordSafe on my personal laptop (and backed up!) and secured by a secure passphrase known only to me.


  • 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]

    I use FindSecurityBugs and PMD when I use Eclipse. Several of us also have a Coverity instance (e.g.,, https://scan.coverity.com/projects/bkimminich-esapi-java-legacy and https://scan.coverity.com/projects/owasp-esapi-java, which our Coverity badge will eventually be referring to).



    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]

    Coverity is being used. I have also ran it through HP Fortify a few times. It has been fully analyzed by the secure code review team where I work, and while I cannot provide details, no vulnerabilities were discovered. I did find 1 or 2 bugs [since reported] as a result of the Fortify scan though.



    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]

    No medium or high severity vulnerabilities were discovered.



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

    We regularly run PMD, spotbugs, and findsecbugs and review new findings. I believe that Bjorn Kimminich has integrated the Coverity scan with his Travis-CI builds, but it has been run since April 2016. I have run CodeQL recently, but it is not yet fully integrated into our GitHub workflow.


  • 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]

    Not sure exactly how this applies, but N/A isn't something that I can choose. There were early versions of web-based software (e.g., ESAPI Swingset) that demonstrated how to use ESAPI, but it is not directly attackable via DAST as it is simply an SDK (i.e., a library).



    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 Java.



    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]

    There are runtime assertions, but ironically most people disable those (they, in fact are disabled by default in Java), so instead I am changing most of them to explicit runtime checks (except for things like certain invariants or sanity checks in private methods where we still have some assertions). Violations of runtime checks will throw some sort of RuntimeException, notably IllegalArgumentException for most of the precondition failures.



    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]

    None discovered because using DAST on ESAPI directly really makes no sense; there is nothing for DAST to test against.



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 Kevin W. Wall and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Kevin W. Wall.
Entry created on 2016-05-10 23:31:58 UTC, last updated on 2022-08-16 02:34:46 UTC.

Back