From e6d27c0c155a89e9053637bd94080f102393e521 Mon Sep 17 00:00:00 2001 From: 9alexx3 <58992048+9alexx3@users.noreply.github.com> Date: Thu, 20 Aug 2026 10:33:04 +0200 Subject: [PATCH] docs: Fix typos --- docs/README.md | 2 +- .../engagements_tests/OS__assets.md | 2 +- .../engagements_tests/OS__calendar.md | 2 +- .../engagements_tests/OS__findings.md | 2 +- .../engagements_tests/OS__tests.md | 2 +- .../asset_modelling/tags/OS__tagging_objects.md | 2 +- docs/content/automation/api/api-v2-docs.md | 14 +++++++------- .../downstream/troubleshooting_jira.md | 4 ++-- docs/content/get_started/about/faq.md | 2 +- .../contributing/how-to-write-a-parser.md | 17 ++++++++--------- .../OS__deduplication_tuning.md | 4 ++-- 11 files changed, 26 insertions(+), 27 deletions(-) diff --git a/docs/README.md b/docs/README.md index 9f3087d8f13..5acd12699e9 100644 --- a/docs/README.md +++ b/docs/README.md @@ -38,7 +38,7 @@ This method performs the following from the `django-DefectDojo/docs` directory: 2. Install all packages in CI mode to only install from `package-lock.json`: `npm ci` 3. Run Hugo to build the site in the way the CI job does, but in development environment to point at `localhost` for integrity checks : `npm run build -- --environment development` 4. Change directory to the new `public` directory to run the site locally: `cd public` -5. Run a light weight webserver to server the files, and [access the site at http://localhost:8080](http://localhost:8080): `python3 -m http.server 8080` +5. Run a light weight webserver to serve the files, and [access the site at http://localhost:8080](http://localhost:8080): `python3 -m http.server 8080` 6. After killing the webserver process, navigate back to the `django-DefectDojo/docs` directory: `cd ../` ### Execution List diff --git a/docs/content/asset_modelling/engagements_tests/OS__assets.md b/docs/content/asset_modelling/engagements_tests/OS__assets.md index 04b6e8a8b04..a579f259da0 100644 --- a/docs/content/asset_modelling/engagements_tests/OS__assets.md +++ b/docs/content/asset_modelling/engagements_tests/OS__assets.md @@ -177,4 +177,4 @@ Assets can be mapped directly to Jira Projects, which push the Asset’s Finding Because Findings inherit risk, priority, and ownership from their parent Asset, the Asset effectively determines the remediation context that flows into Jira tickets and Downstream Connector workflows. -Importantly, Assets are also the primary determining factor in a Finding’s SLA characteristics. Therefore, the SLA of a Findings depends on the SLA configuration of its parent Asset. More information about SLA configurations can be found [here](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). +Importantly, Assets are also the primary determining factor in a Finding’s SLA characteristics. Therefore, the SLA of a Finding depends on the SLA configuration of its parent Asset. More information about SLA configurations can be found [here](/asset_modelling/os_hierarchy/os__sla_configuration/#main-content). diff --git a/docs/content/asset_modelling/engagements_tests/OS__calendar.md b/docs/content/asset_modelling/engagements_tests/OS__calendar.md index 64286709dbb..2fda1195a3f 100644 --- a/docs/content/asset_modelling/engagements_tests/OS__calendar.md +++ b/docs/content/asset_modelling/engagements_tests/OS__calendar.md @@ -15,7 +15,7 @@ The Calendar page is accessible via the Calendar button in the sidebar. ![image](images/OSC_ss3.png) -## Visiblity and Permissions +## Visibility and Permissions ### Visibility diff --git a/docs/content/asset_modelling/engagements_tests/OS__findings.md b/docs/content/asset_modelling/engagements_tests/OS__findings.md index 72ea7e1df7f..c9b19a104ef 100644 --- a/docs/content/asset_modelling/engagements_tests/OS__findings.md +++ b/docs/content/asset_modelling/engagements_tests/OS__findings.md @@ -73,7 +73,7 @@ In addition to metadata corresponding to the tables in a Finding’s view, optio - **CVSS3/CVSS4 vector and score**: The CVSS3 and CVSS4 vector and score of the selected Finding. - **Request and response pairs**: A copy of the message sent by the client and the server's reply to the request. - **Endpoints to add**: Vulnerable endpoints that may be affected by the selected Finding that are not reflected in the preceding list of systems/endpoints. -- **EPSS score and percentile**: ESS score and percentile for the CVE. +- **EPSS score and percentile**: EPSS score and percentile for the CVE. - **KEV date added**: The date the Finding was added to the KEV catalog. - **Fix availability and version**: Defines if there is a fix available for the vulnerability, and the version of the affected component in which the fix was implemented. - **User who requested a defect review**: Records who requested a defect review for the flaw in question. diff --git a/docs/content/asset_modelling/engagements_tests/OS__tests.md b/docs/content/asset_modelling/engagements_tests/OS__tests.md index aee04a4a161..2506addc14f 100644 --- a/docs/content/asset_modelling/engagements_tests/OS__tests.md +++ b/docs/content/asset_modelling/engagements_tests/OS__tests.md @@ -91,7 +91,7 @@ The following settings are available within each Test view: - **Edit Test** - Permits the editing of Test data, such as title, schedule, environment, and other various details. - **Copy Test** - - Duplicates a Test, along with all associated metadata and Findings, and allow it to be attributed to a different Engagement. + - Duplicates a Test, along with all associated metadata and Findings, and allows it to be attributed to a different Engagement. - **Re-Upload Scan** - Initiates the reimport process. More information on Reimporting is contained later in this article. - **Add Notes** diff --git a/docs/content/asset_modelling/tags/OS__tagging_objects.md b/docs/content/asset_modelling/tags/OS__tagging_objects.md index 56e108f0570..e6e975fdd72 100644 --- a/docs/content/asset_modelling/tags/OS__tagging_objects.md +++ b/docs/content/asset_modelling/tags/OS__tagging_objects.md @@ -91,7 +91,7 @@ See the following example of adding a tag "test_only_tag" to the Test object and ![Example of inherited tags](images/tags-inherit-exmaple.png) -When updates are made to the tag list on an Asset, the same changes are made to all objects within the Asset asynchronously. The duration of this task directly correlates to the number the objects contained within a finding. +When updates are made to the tag list on an Asset, the same changes are made to all objects within the Asset asynchronously. The duration of this task directly correlates to the number of objects contained within a finding. **Open-Source:** If Tag changes are not observed within a reasonable time period, consult the celery worker logs to identify where any problems might have arisen. diff --git a/docs/content/automation/api/api-v2-docs.md b/docs/content/automation/api/api-v2-docs.md index da457c7b6f4..900e45d6326 100644 --- a/docs/content/automation/api/api-v2-docs.md +++ b/docs/content/automation/api/api-v2-docs.md @@ -33,11 +33,11 @@ If you're logged in to the Defect Dojo web UI, you do not need to provide the au ## Authentication The API uses header authentication with API key. The format of the -header should be: : +header should be: Authorization: Token -For example: : +For example: Authorization: Token c8572a5adf107a693aa6c72584da31f4d1f1dcff @@ -106,7 +106,7 @@ Plan the change before making it: pick a window, ask token owners to rotate firs ## Sample Code Here are some simple python examples and their results produced against -the `/users` endpoint: : +the `/users` endpoint: {{< highlight python >}} import requests @@ -122,7 +122,7 @@ for key, value in r.__dict__.items(): {{< /highlight >}} This code will return the list of all the users defined in DefectDojo. -The json object result looks like : : +The json object result looks like: {{< highlight json >}} [ @@ -160,7 +160,7 @@ for key, value in r.__dict__.items(): print('------------------') {{< /highlight >}} -The json object result is: : +The json object result is: {{< highlight json >}} [ @@ -228,7 +228,7 @@ Example for importing a scan result: | Wrapper | Status | Notes | | -----------------------------| ------------------------| ------------------------| | [Specific python wrapper](https://github.com/DefectDojo/defectdojo_api) | working (2021-01-21) | API Wrapper including scripts for continous CI/CD uploading. Is lagging behind a bit on latest API features as we plan to revamp the API wrapper | -| [Openapi python wrapper](https://github.com/alles-klar/defectdojo-api-v2-client) | | proof of concept only where we found out the the OpenAPI spec is not perfect yet | +| [Openapi python wrapper](https://github.com/alles-klar/defectdojo-api-v2-client) | | Proof of concept only where we found out the the OpenAPI spec is not perfect yet | | [Java library](https://github.com/secureCodeBox/defectdojo-client-java) | working (2021-08-30) | Created by the kind people of [SecureCodeBox](https://github.com/secureCodeBox/secureCodeBox) | | [Image using the Java library](https://github.com/SDA-SE/defectdojo-client) | working (2021-08-30) | | | [.Net/C# library](https://www.nuget.org/packages/DefectDojo.Api/) | working (2021-06-08) | | @@ -304,7 +304,7 @@ When `auto_create_context` is `True`, the Product Type, Product and Engagement w When `do_not_reactivate` is `True`, the importing/reimporting will ignore uploaded active findings and not reactivate previously closed findings, while still creating new findings if there are new ones. You will get a note on the finding to explain that it was not reactivated for that reason. -A reimport will automatically select the latest test inside the provided engagement that satisifes the provided `scan_type` and (optionally) provided `test_title`. +A reimport will automatically select the latest test inside the provided engagement that satisfies the provided `scan_type` and (optionally) provided `test_title`. If no existing Test is found, the reimport endpoint will use the import function to import the provided report into a new Test. This means a (CI/CD) script using the API doesn't need to know if a Test already exists, or if it is a first time upload for this Product / Engagement. diff --git a/docs/content/connectors/downstream/troubleshooting_jira.md b/docs/content/connectors/downstream/troubleshooting_jira.md index edfb0954d9c..28f2ab218ef 100644 --- a/docs/content/connectors/downstream/troubleshooting_jira.md +++ b/docs/content/connectors/downstream/troubleshooting_jira.md @@ -178,7 +178,7 @@ As this command requires access to the backend, it is not available to Cloud use {{< highlight bash >}} usage: manage.py jira_status_reconciliation [-h] [--mode MODE] [--product PRODUCT] [--engagement ENGAGEMENT] [--dryrun] [--version] [-v {0,1,2,3}] -Reconcile finding status with JIRA issue status, stdout will contain semicolon seperated CSV results. +Reconcile finding status with JIRA issue status, stdout will contain semicolon separated CSV results. Risk Accepted findings are skipped. Findings created before 1.14.0 are skipped. optional arguments: @@ -209,7 +209,7 @@ DEBUG output can be obtains via `-v 3`, but only after increasing the logging to $ docker compose exec uwsgi /bin/bash -c 'python manage.py jira_status_reconciliation -v 3' {{< /highlight >}} -At the end of the command a semicolon seperated CSV summary will be printed. This can be captured by redirecting stdout to a file: +At the end of the command a semicolon separated CSV summary will be printed. This can be captured by redirecting stdout to a file: {{< highlight bash >}} $ docker compose exec uwsgi /bin/bash -c 'python manage.py jira_status_reconciliation > jira_reconciliation.csv' diff --git a/docs/content/get_started/about/faq.md b/docs/content/get_started/about/faq.md index bad2423e803..79029487cce 100644 --- a/docs/content/get_started/about/faq.md +++ b/docs/content/get_started/about/faq.md @@ -131,4 +131,4 @@ DefectDojo Pro users also have access to [executive-level Metrics dashboards](/g In both Pro and Open-Source editions of DefectDojo, Findings in DefectDojo can be pushed to Jira as Issues, which allows you to integrate issue remediation with your development team. -DefectDojo Pro adds support for [Additional Project Tracking Integrations](/connectors/issue_tracking/)**: ServiceNow, Azure DevOps, GitHub and GitLab. \ No newline at end of file +DefectDojo Pro adds support for **[Additional Project Tracking Integrations](/connectors/issue_tracking/)**: ServiceNow, Azure DevOps, GitHub and GitLab. \ No newline at end of file diff --git a/docs/content/get_started/contributing/how-to-write-a-parser.md b/docs/content/get_started/contributing/how-to-write-a-parser.md index 2ace0a41d65..ec403021a06 100644 --- a/docs/content/get_started/contributing/how-to-write-a-parser.md +++ b/docs/content/get_started/contributing/how-to-write-a-parser.md @@ -15,7 +15,7 @@ All commands assume that you're located at the root of the django-DefectDojo clo - Checkout `dev` and make sure you're up to date with the latest changes. - It's advised that you create a dedicated branch for your development, such as `git checkout -b parser-name`. -It is easiest to use the docker compose deployment as it has hot-reload capbility for uWSGI. +It is easiest to use the docker compose deployment as it has hot-reload capability for uWSGI. Set up your environment to use the dev environment: `$ docker/setEnv.sh dev` @@ -44,7 +44,7 @@ $ docker compose build --build-arg uid=1000 ## Factory contract -Parsers are loaded dynamicaly with a factory pattern. To have your parser loaded and works correctly, you need to implement the contract. +Parsers are loaded dynamically with a factory pattern. To have your parser loaded and works correctly, you need to implement the contract. 1. your parser **MUST** be in a sub-module of module `dojo.tools` - ex: `dojo.tools.my_tool.parser` module @@ -58,7 +58,7 @@ Parsers are loaded dynamicaly with a factory pattern. To have your parser loaded 2. `def get_label_for_scan_types(self, scan_type):` This function return a string used to provide some text in the UI (short label) 3. `def get_description_for_scan_types(self, scan_type):` This function return a string used to provide some text in the UI (long description) 4. `def get_findings(self, file, test)` This function return a list of findings -6. If your parser have more than 1 scan_type (for detailled mode) you **MUST** implement `def set_mode(self, mode)` method +6. If your parser has more than 1 scan_type (for detailed mode) you **MUST** implement `def set_mode(self, mode)` method 7. The parser instance is re-used over all imports performed for this scan_type, so do not store any data at class level Example: @@ -176,7 +176,7 @@ Good example: some_list = data.get("key_of_the_list") or [] ``` -The finale example guards against cases where `key_of_the_list` is present, but `null`. +The final example guards against cases where `key_of_the_list` is present, but `null`. ### Parsing of CVSS vectors @@ -256,7 +256,7 @@ Do not do something like this: By default a new parser uses the 'legacy' deduplication algorithm documented in [About Deduplication](/triage_findings/finding_deduplication/about_deduplication/) -Please use a pre-defined deduplication algorithm where applicable. When using the `unique_id_from_tool` or `vuln_id_from_tool` fields in the hash code configuration, it's important that these are uqniue for the finding and constant over time across subsequent scans. If this is not the case, the values can still be useful to set on the finding model without using them for deduplication. +Please use a pre-defined deduplication algorithm where applicable. When using the `unique_id_from_tool` or `vuln_id_from_tool` fields in the hash code configuration, it's important that these are unique for the finding and constant over time across subsequent scans. If this is not the case, the values can still be useful to set on the finding model without using them for deduplication. The values must be coming from the report directly and must not be something that is calculated by the parser internally. ## Unit tests @@ -347,14 +347,13 @@ for finding in findings: ### Tests API Parsers Not only parser but also importer should be tested. -`patch` method from `unittest.mock` is usualy usefull for simulating API responses. -It is highly recommeded to use it. - +`patch` method from `unittest.mock` is usually useful for simulating API responses. +It is highly recommended to use it. ## Other files that could be involved ### Change to the model -In the event where you'd have to change the model, e.g. to increase a database column size to accomodate a longer string of data to be saved +In the event where you'd have to change the model, e.g. to increase a database column size to accommodate a longer string of data to be saved * Change what you need in `dojo/models.py` * Create a new migration file in dojo/db_migrations by running and including as part of your PR diff --git a/docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.md b/docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.md index 9df2046872e..6641208769f 100644 --- a/docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.md +++ b/docs/content/triage_findings/finding_deduplication/OS__deduplication_tuning.md @@ -7,7 +7,7 @@ aliases: - /en/working_with_findings/finding_deduplication/deduplication_tuning_os - /en/working_with_findings/finding_deduplication/deduplication_algorithms --- -The Open Source edition of DefectDojo uses settings files and environment variables tune deduplication. +The Open Source edition of DefectDojo uses settings files and environment variables to tune deduplication. See also: [Open Source Configuration](/get_started/open_source/configuration/) for details on environment variables and `local_settings.py` overrides. @@ -155,7 +155,7 @@ If you submit dedupe to Celery (without `--dedupe_sync`), allow time for tasks t To help troubleshooting deduplication use the following tools: -- Observe log out in the `dojo.specific-loggers.deduplication` category. This is a class independant logger that outputs details about the deduplication process and settings when processing findings. +- Observe log out in the `dojo.specific-loggers.deduplication` category. This is a class independent logger that outputs details about the deduplication process and settings when processing findings. - Observe the `unique_id_from_tool` and `hash_code` values by hovering over the `ID` field or `Status` column: ![Unique ID from Tool and Hash Code on the View Finding page](images/hash_code_id_field.png)