OWASP Threat Dragon

Repository on GitHub, which provides public git repositories with URLs: https://github.com/OWASP/threat-dragon

Repository on GitHub, which uses git, is here: https://github.com/OWASP/threat-dragon git can track the changes, who made them, and when they were made. Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The git tags are used to provide interim releases, for example: https://github.com/OWASP/threat-dragon/tags?after=v2.0.5 Sometimes the releases are just released, but sometimes they go through iterations before release after review

Repository on GitHub, which uses git, is here: https://github.com/OWASP/threat-dragon git is common distributed version control software Repository on GitHub, which uses git. git is distributed.

The project uses semantic versioning and the released versions are here: https://github.com/OWASP/threat-dragon/releases with the latest version 2.2.0 given here: https://github.com/OWASP/threat-dragon/releases/tag/v2.2.0

Here are the tags for each release: https://github.com/OWASP/threat-dragon/tags Note that releases before version 1.3 were from a different (private) repo before it transferred over to the official OWASP repo

They are not released as separate files, but are added to the release area itself in the description for each release as text tailored for the individual release, for example: https://github.com/OWASP/threat-dragon/releases/tag/v2.2.0

So far no publicly known vulnerabilities or even publicly unknown ones ;) The one advisory published did not need a CVE: https://github.com/OWASP/threat-dragon/security/advisories/GHSA-6r5p-cg7w-2rrv

Both GitHub issue tracker: https://github.com/OWASP/threat-dragon/issues and also via direct contact with the project leaders: https://github.com/OWASP/threat-dragon?tab=readme-ov-file#contributing

Yes, GitHub issue tracker provides this : https://github.com/OWASP/threat-dragon/issues

Bug reports all have a comment acknowledging the report, except for some of the ones raised by the project leader (Jon Gadsden): https://github.com/OWASP/threat-dragon/issues?q=is%3Aissue+is%3Aopen+label%3Abug and the closed bugs mostly have comments: https://github.com/OWASP/threat-dragon/issues?q=is%3Aissue+label%3Abug+is%3Aclosed

The enhancement requests have all been responded to, except for some of the ones raised by the project leader (Jon Gadsden) : https://github.com/OWASP/threat-dragon/issues?q=is%3Aissue+is%3Aopen+label%3Aenhancement

Yes, via GitHub isue tracker : https://github.com/OWASP/threat-dragon/issues

Vulnerability reporting process is detailed here and uses the GitHub security vulnerability reporting process: https://github.com/OWASP/threat-dragon/blob/main/security.md

This is supported using GitHub security vulnerability reporting process: https://github.com/OWASP/threat-dragon/security/advisories/new

The one vulnerability report received was on Nov 16, 2023 and was fixed by Nov 29, 2023 : https://github.com/OWASP/threat-dragon/security/advisories/GHSA-6r5p-cg7w-2rrv

The software is written using Javascript, and the implementation runs directly from the source code using Node.js . The docker images are built and published automatically using a github workflow on merge to the main branch: https://github.com/OWASP/threat-dragon/blob/main/.github/workflows/push.yaml there are various github workflows that build Threat Dragon on push, release, pull-request and nightly

Threat Dragon is a Vue/Node.js application and is built using npm (Node.js Package Manager) and Electron (desktop system for Node.js applications). Both of these are common tools used by the FLOSS community

The Threat Dragon is a Node.js application and uses 100% FLOSS packages sourced from the npm package registry

The Threat Dragon back end is based on the Express web server and has a set of unit tests using the mocha test framework, with the CLI provided by nyc The application is written using the Vue framework and has unit tests using jest with the CLI provided by vue-cli-service Functional testing of the application is provided by Cypress test framework

Both the funtional testsand the unit tests for both the application and the back end are invoked using scripts contained in the Node.js package.json file, which is the standard way to run tests for a Node.js application, just type 'npm test' There is a documentation page on the unit tests: https://owasp.org/www-project-threat-dragon/docs-2/unit/ and on the functional end-to-end tests: https://owasp.org/www-project-threat-dragon/docs-2/e2e/

The code coverage for both applications and back-end are displayed at the end of the unit tests, run using standard Node.js command npm test

there are various github workflows that build Threat Dragon on push, release, pull-request and nightly : https://github.com/OWASP/threat-dragon/tree/main/.github/workflows

this policy is in the contributing instructions at : https://github.com/OWASP/threat-dragon/blob/main/contributing.md#ground-rules

latest features are required to have unit tests and functional tests, for example a recent pull request : https://github.com/OWASP/threat-dragon/pull/1239/files

the pull request template has documented instructions on contributing which are inorporated in every pull request using the template: https://github.com/OWASP/threat-dragon/blob/main/.github/pull_request_template.md

The Vue Javascript linter, vue-cli-service lint, is run as a pretest before running the unit tests. If this fails then the unit tests will not run. the unit tests are part of the pipelines run on pull-request and commit to main branch, and the pipelines will fail if the unit tests / linter throws errors

warning are reported when running unit tests and functional tests. These are reported to the console so that they can be addressed during code development

the .eslintrc.js are configured to be maximally strict with errors thrown when any rules are broken : * https://github.com/OWASP/threat-dragon/blob/main/td.vue/.eslintrc.js * https://github.com/OWASP/threat-dragon/blob/main/td.server/.eslintrc.js * https://github.com/OWASP/threat-dragon/blob/main/td.vue/tests/e2e/.eslintrc.js

The project leader for Threat Dragon, Jon Gadsden, is the main contributor to the OWASP Developer Guide. The demonstrates a good depth of knowledge on secure coding and secure software development lifecycles: https://owasp.org/www-project-developer-guide/release/

Jon Gadsden, the project leader for Threat Dragon, is a software security engineer in a product security team and is familiar with erros that lead to software vulnerabilities. In addition he has an ISC2 CSSLP qualification that demonstrates this

The software uses https and standard crypto protocols to communicate with both users and with code repositories

No crypto functions are re-implemented by Threat Dragon

Threat Dragon only uses FLOSS, for crypto and other functionality

while smaller key lengths are not disabled, it is suggested i the documentation that the symmetric keys are have a key length of 128 bits using: openssl rand -hex 16

Threat Dragon uses OAuth for its identity and access management to the repository

No cryptographic algorithms or modes with known serious weaknesses are used

this is provided by the crypto in the standard libraries used by Threat Dragon in addition nothing in the code inhibits or prevents the use of PFS; that is a property of the website's web server.

The software does not store passwords for authentication of external users

cryptographic keys and nonces are generated using npm modules such as the one providing the Content Security Policy

Threat Dragon uses https

http is not used by Threat Dragon unless it is in a non-production environment

Any vulnerabilities of medium or higher severity are reported by dependabot and are fixed easily within 60 days : https://github.com/OWASP/threat-dragon/pulls?q=is%3Apr+is%3Aclosed+label%3Aautomation

Any critical vulnerabilities are reported by dependabot and are fixed rapidly : https://github.com/OWASP/threat-dragon/pulls?q=is%3Apr+is%3Aclosed+label%3Aautomation

No valid private credentials are leaked. There is a .env file, but it only includes stub data for testing, not the live credentials

CodeQL static code analysis is applied on pull-request, on commit to main branch and also in the nightly pipelines

CodeQL static code analysis include rules to look for common vulnerabilities in Javascript

If CodeQL detects medium and higher severity exploitable vulnerabilities then this stage of the pipeline will fail, requiring that hey be fixed before the pipeline can pass

CodeQL static code analysis is applied in the nightly pipelines, as well as on pull-request and on commit to main branch

Threat Dragon is analysed by OWASP ZAP on pull-request and also on commits to the main branch, using github workflow pipelines : https://github.com/OWASP/threat-dragon/actions

Application written using Javascript, with no C/C++ source or any other memory-unsafe language used within the project

No assertions are embedded in the Treat Dragon code, as this is not a generally used feature of Javascript

Any issues found via OWASP ZAP have been fixed, with some rules put on an ignore list because they are not relevant: https://github.com/OWASP/threat-dragon/blob/main/.github/workflows/.zap-rules-web.tsv