Vale fixes and rules

.github/SECURITY.md

@@ -32,4 +32,4 @@ You can report vulnerabilities here: [https://www.ncsc.gov.uk/information/vulner
 
 ## General Security Enquiries
 
-If you have general enquiries regarding our cyber security, please reach out to us at [[email protected]]([email protected])
+If you have general enquiries regarding our cybersecurity, please reach out to us at [[email protected]]([email protected])

README.md

@@ -45,13 +45,13 @@ cd nhs-england-tools/repository-template
 
 The following software packages, or their equivalents, are expected to be installed:
 
-- [docker](https://www.docker.com/) container runtime or a compatible tool, e.g. [podman](https://podman.io/),
+- [Docker](https://www.docker.com/) container runtime or a compatible tool, e.g. [Podman](https://podman.io/),
 - [asdf](https://asdf-vm.com/) version manager,
 - [GNU make](https://www.gnu.org/software/make/) 3.82 or later,
 - [GNU coreutils](https://www.gnu.org/software/coreutils/) and [GNU binutils](https://www.gnu.org/software/binutils/) may be required to build dependencies like Python, which may need to be compiled during installation. For macOS users, this has been scripted and automated by the `dotfiles` project; please see this [script](https://github.com/nhs-england-tools/dotfiles/blob/main/assets/20-install-base-packages.macos.sh) for details.
 
 > [!NOTE]<br>
-> The version of GNU make available by default on macOS is earlier than 3.82. You will need to upgrade it or certain `make` tasks will fail. On macOS, you will need [homebrew](https://brew.sh/) installed, then to install `make`, like so:
+> The version of GNU make available by default on macOS is earlier than 3.82. You will need to upgrade it or certain `make` tasks will fail. On macOS, you will need [Homebrew](https://brew.sh/) installed, then to install `make`, like so:
 >
 > ```shell
 > brew install make

docs/adr/ADR-001_Use_git_hook_and_GitHub_action_to_check_the_editorconfig_compliance.md

@@ -106,7 +106,7 @@ This option is an extension built upon option 2a.
 - Pros
   - Usage of a GitHub native functionality
 - Cons
-  - Reliance on the GitHub DSL (coding in yaml) may lead to less portable solution
+  - Reliance on the GitHub DSL (coding in YAML) may lead to less portable solution
   - Implementation of the functionality has to be duplicated for the git hook
 
 ### Outcome

docs/adr/ADR-002_Scan_repository_for_hardcoded_secrets.md

@@ -1,4 +1,4 @@
-# ADR-002: Scan repository for hardcoded secrets
+# ADR-002: Scan repository for hard-coded secrets
 
 >|              |                                                               |
 >| ------------ | ------------------------------------------------------------- |
@@ -10,7 +10,7 @@
 
 ---
 
-- [ADR-002: Scan repository for hardcoded secrets](#adr-002-scan-repository-for-hardcoded-secrets)
+- [ADR-002: Scan repository for hard-coded secrets](#adr-002-scan-repository-for-hard-coded-secrets)
   - [Context](#context)
   - [Decision](#decision)
     - [Assumptions](#assumptions)
@@ -42,7 +42,7 @@ Within NHS England, we are observing an adoption of the `gitleaks` tool, which i
 
 There are three options presented in this decision record.
 
-1. [git-secrets](https://github.com/awslabs/git-secrets)
+1. [Git-secrets](https://github.com/awslabs/git-secrets)
 
    - Repository metadata
      - Contributions
@@ -66,9 +66,9 @@ There are three options presented in this decision record.
    - Cons
      - Rules and exclusion patterns are not easy to manage as no comments or metadata are allowed in the definition
      - No pre-backed Docker image
-     - Activity of the repo has dropped (last commit a while ago)
+     - Activity of the repository has dropped (last commit a while ago)
 
-2. [trufflehog](https://github.com/trufflesecurity/trufflehog)
+2. [Trufflehog](https://github.com/trufflesecurity/trufflehog)
 
    - Repository metadata
      - Contributions
@@ -93,7 +93,7 @@ There are three options presented in this decision record.
    - Cons
      - [AGPL-3.0](https://choosealicense.com/licenses/agpl-3.0/) licence comes with conditions
 
-3. [gitleaks](https://github.com/gitleaks/gitleaks)
+3. [Gitleaks](https://github.com/gitleaks/gitleaks)
 
    - Repository metadata
 

docs/adr/ADR-XXX_Agree_CICD_pipeline_structure.md

@@ -55,7 +55,7 @@ Requirements:
 
 ### Assumptions
 
-Summarise the underlying assumptions in the environment in which you make the decision. This could be related to technology changes, forecast of the monetary and non-monetary costs, further delivery commitments, impactful external drivers etc., and any known unknowns that translate to risks.
+Summarise the underlying assumptions in the environment in which you make the decision. This could be related to technology changes, forecast of the monetary and non-monetary costs, further delivery commitments, impact from external drivers etc., and any known unknowns that translate to risks.
 
 ### Drivers
 

docs/adr/ADR-nnn_Any_Decision_Record_Template.md

@@ -32,7 +32,7 @@ Describe the context and the problem statement. Is there a relationship to other
 
 ### Assumptions
 
-Summarise the underlying assumptions in the environment in which you make the decision. This could be related to technology changes, forecast of the monetary and non-monetary costs, further delivery commitments, impactful external drivers etc., and any known unknowns that translate to risks.
+Summarise the underlying assumptions in the environment in which you make the decision. This could be related to technology changes, forecast of the monetary and non-monetary costs, further delivery commitments, impact from external drivers etc., and any known unknowns that translate to risks.
 
 ### Drivers
 

docs/adr/assets/ADR-003/examples/nodejs/README.md

@@ -26,4 +26,4 @@ $ yarn start
       ...
 ```
 
-See the [example (main.ts)](./main.ts) implementation. This script has been written to illustrate the concept in a clear and simple way. It is not a production ready code.
+See the [example (`main.ts`)](./main.ts) implementation. This script has been written to illustrate the concept in a clear and simple way. It is not a production ready code.

docs/developer-guides/Scripting_Docker.md

@@ -40,29 +40,29 @@ Here are some key features built into this repository's Docker module:
 - Consolidates image versions in a unified `.tool-versions` file for easier dependency management
 - Optimises the build process specifically for the `amd64` architecture for consistency
 - Applies automatic image versioning according to a predefined pattern for artefact publishing and deployment
-- Incorporates metadata through Dockerfile labels for enhanced documentation and to conform to standards
-- Integrates a linting routine to ensure Dockerfile code quality
+- Incorporates metadata through `Dockerfile` labels for enhanced documentation and to conform to standards
+- Integrates a linting routine to ensure `Dockerfile` code quality
 - Includes an automated test suite to validate Docker scripts
 - Provides a ready-to-run example to demonstrate the module's functionality
 - Incorporates a best practice guide
 
 ## Key files
 
 - Scripts
-  - [docker.lib.sh](../../scripts/docker/docker.lib.sh): A library code loaded by custom make targets and CLI scripts
-  - [docker.mk](../../scripts/docker/docker.mk): Customised implementation of the Docker routines loaded by the `scripts/init.mk` file
-  - [dgoss.sh](../../scripts/docker/dgoss.sh): Docker image spec test framework
-  - [dockerfile-linter.sh](../../scripts/docker/dockerfile-linter.sh): Dockerfile linter
+  - [`docker.lib.sh`](../../scripts/docker/docker.lib.sh): A library code loaded by custom make targets and CLI scripts
+  - [`docker.mk`](../../scripts/docker/docker.mk): Customised implementation of the Docker routines loaded by the `scripts/init.mk` file
+  - [`dgoss.sh`](../../scripts/docker/dgoss.sh): Docker image spec test framework
+  - [`dockerfile-linter.sh`](../../scripts/docker/dockerfile-linter.sh): `Dockerfile` linter
 - Configuration
-  - [.tool-versions](../../.tool-versions): Stores Docker image versions
-  - [hadolint.yaml](../../scripts/config/hadolint.yaml): Dockerfile linter configuration file
-  - [Dockerfile.metadata](../../scripts/docker/Dockerfile.metadata): Labels added to image definition as specified by the spec
+  - [`.tool-versions`](../../.tool-versions): Stores Docker image versions
+  - [`hadolint.yaml`](../../scripts/config/hadolint.yaml): `Dockerfile` linter configuration file
+  - [`Dockerfile.metadata`](../../scripts/docker/Dockerfile.metadata): Labels added to image definition as specified by the spec
 - Test suite
-  - [docker.test.sh](../../scripts/docker/tests/docker.test.sh): Main file containing all the tests
-  - [Dockerfile](../../scripts/docker/tests/Dockerfile): Image definition for the test suite
-  - [VERSION](../../scripts/docker/tests/VERSION): Version patterns for the test suite
+  - [`docker.test.sh`](../../scripts/docker/tests/docker.test.sh): Main file containing all the tests
+  - [`Dockerfile`](../../scripts/docker/tests/Dockerfile): Image definition for the test suite
+  - [`VERSION`](../../scripts/docker/tests/VERSION): Version patterns for the test suite
 - Usage example
-  - Python-based example [hello_world](../../scripts/docker/examples/python) app showing a multi-staged build
+  - Python-based example [`hello_world`](../../scripts/docker/examples/python) app showing a multi-staged build
   - A set of [make targets](https://github.com/nhs-england-tools/repository-template/blob/main/scripts/docker/docker.mk#L18) to run the example
 
 ## Usage
@@ -113,7 +113,7 @@ Here is a step-by-step guide:
    FROM cypress/browsers:latest
    ```
 
-2. Add the following entry to the `.tool-versions` file. This will be used to replace the `latest` version placeholder in the Dockerfile.
+2. Add the following entry to the `.tool-versions` file. This will be used to replace the `latest` version placeholder in the `Dockerfile`.
 
    ```text
    # docker/cypress/browsers node-20.5.0-chrome-114.0.5735.133-1-ff-114.0.2-edge-114.0.1823.51-1@sha256:8b899d0292e700c80629d13a98ae309295e719f5b4f9aa50a98c6cdd2b6c5215

docs/developer-guides/Scripting_Terraform.md

@@ -20,9 +20,9 @@ Terraform is an open-source infrastructure as code (IaC) tool. It allows you to
 Some advantages of using Terraform are as outlined below:
 
 - **Declarative configuration**: Terraform enables the precise definition of the desired state of infrastructure, streamlining its creation through a readable and understandable codebase.
-- **Version control**: The infrastructure code may be subject to version control, thereby providing an auditable record of environmental changes.
+- **Version control**: The infrastructure code may be subject to version control, thereby providing an audit trail of environmental changes.
 - **Modularisation and reusability**: Terraform facilitates the packaging of infrastructure into modular components, enhancing both reusability and ease of sharing across organisational teams.
-- **State management**: Terraform's state management capabilities ensure an accurate representation of real-world resources, enabling features such as resource dependencies and idempotency.
+- **State management**: Terraform's state management capabilities ensure an accurate representation of real-world resources, enabling features such as resource dependencies and idempotence.
 - **Collaboration and workflow**: The platform supports collaboration through features like remote backends and state locking, thereby fostering collective work on infrastructure projects.
 - **Community and ecosystem**: A robust community actively contributes to the Terraform ecosystem, providing a wealth of modules and examples that expedite infrastructure development.
 
@@ -46,16 +46,16 @@ Here are some key features built into this repository's Terraform module:
 ## Key files
 
 - Scripts
-  - [terraform.lib.sh](../../scripts/terraform/terraform.lib.sh) A library code loaded by custom make targets and CLI scripts
-  - [terraform.mk](../../scripts/terraform/terraform.mk): Customised implementation of the Terraform routines loaded by the `scripts/init.mk` file
-  - [terraform.sh](../../scripts/terraform/terraform.sh): Terraform command wrapper
+  - [`terraform.lib.sh`](../../scripts/terraform/terraform.lib.sh) A library code loaded by custom make targets and CLI scripts
+  - [`terraform.mk`](../../scripts/terraform/terraform.mk): Customised implementation of the Terraform routines loaded by the `scripts/init.mk` file
+  - [`terraform.sh`](../../scripts/terraform/terraform.sh): Terraform command wrapper
 - Configuration
-  - [.tool-versions](../../.tool-versions): Stores Terraform version to be used
+  - [`.tool-versions`](../../.tool-versions): Stores Terraform version to be used
 - Code quality gates
-  - [lint-terraform/action.yaml](../../.github/actions/lint-terraform/action.yaml): GitHub action
-  - [check-terraform-format.sh](../../scripts/githooks/check-terraform-format.sh): Git hook
+  - [`lint-terraform/action.yaml`](../../.github/actions/lint-terraform/action.yaml): GitHub action
+  - [`check-terraform-format.sh`](../../scripts/githooks/check-terraform-format.sh): Git hook
 - Usage example
-  - Declarative infrastructure definition example [terraform-state-aws-s3](../../scripts/terraform/examples/terraform-state-aws-s3) to store Terraform state
+  - Declarative infrastructure definition example [`terraform-state-aws-s3`](../../scripts/terraform/examples/terraform-state-aws-s3) to store Terraform state
   - A set of [make targets](https://github.com/nhs-england-tools/repository-template/blob/main/scripts/terraform/terraform.mk#L44) to run the example
 
 ## Usage

docs/user-guides/Run_Git_hooks_on_commit.md

@@ -14,13 +14,13 @@ The [pre-commit](https://pre-commit.com/) framework is a powerful tool for manag
 ## Key files
 
 - Scripts
-  - [check-file-format.sh](../../scripts/githooks/check-file-format.sh)
-  - [check-markdown-format.sh](../../scripts/githooks/check-markdown-format.sh)
-  - [check-terraform-format.sh](../../scripts/githooks/check-terraform-format.sh)
-  - [scan-secrets.sh](../../scripts/githooks/scan-secrets.sh)
+  - [`check-file-format.sh`](../../scripts/githooks/check-file-format.sh)
+  - [`check-markdown-format.sh`](../../scripts/githooks/check-markdown-format.sh)
+  - [`check-terraform-format.sh`](../../scripts/githooks/check-terraform-format.sh)
+  - [`scan-secrets.sh`](../../scripts/githooks/scan-secrets.sh)
 - Configuration
-  - [pre-commit.yaml](../../scripts/config/pre-commit.yaml)
-  - [init.mk](../../scripts/init.mk): make targets
+  - [`pre-commit.yaml`](../../scripts/config/pre-commit.yaml)
+  - [`init.mk`](../../scripts/init.mk): make targets
 
 ## Testing
 

docs/user-guides/Scan_dependencies.md

@@ -11,16 +11,16 @@
 
 In modern software development, leveraging third-party dependencies is a common practice to reduce redundancy and improve efficiency. However, this introduces potential security risks and compliance issues into our codebase, making dependency scanning crucial. This process helps identify known vulnerabilities, or Common Vulnerabilities and Exposures (CVEs), in third-party libraries, allowing us to mitigate security threats proactively. Regular CVE scanning strengthens our codebase's security, ensuring adherence to top-tier security standards. In addition, generating a Software Bill of Materials (SBOM) - a comprehensive inventory of software components, libraries, and modules - is a valuable practice. SBOMs enhance transparency and traceability, giving an overview of all software elements, their versions, and associated licenses. This facilitates effective dependency management, compliance assurance, and timely response to version-specific vulnerabilities.
 
-[Syfy](https://github.com/anchore/syft) and [Grype](https://github.com/anchore/grype) are valuable tools that can bolster this process. Syft generates a detailed SBOM, ensuring full visibility and traceability of all incorporated software components. This facilitates precise tracking, management, and potential updating of dependencies. On the other hand, Grype, as a vulnerability scanner, meticulously examines dependencies for known CVEs, providing an extra layer of security and allowing us to rectify vulnerabilities promptly. By incorporating Syft and Grype into our CI/CD pipeline, we can ensure continuous scanning of dependencies and generate an up-to-date SBOM. This approach enables real-time detection and resolution of vulnerabilities, thereby fortifying our software development lifecycle against security risks and ensuring adherence to compliance requirements.
+[Syft](https://github.com/anchore/syft) and [Grype](https://github.com/anchore/grype) are valuable tools that can bolster this process. Syft generates a detailed SBOM, ensuring full visibility and traceability of all incorporated software components. This facilitates precise tracking, management, and potential updating of dependencies. On the other hand, Grype, as a vulnerability scanner, meticulously examines dependencies for known CVEs, providing an extra layer of security and allowing us to rectify vulnerabilities promptly. By incorporating Syft and Grype into our CI/CD pipeline, we can ensure continuous scanning of dependencies and generate an up-to-date SBOM. This approach enables real-time detection and resolution of vulnerabilities, thereby fortifying our software development lifecycle against security risks and ensuring adherence to compliance requirements.
 
 ## Key files
 
-- [generate-sbom.sh](../../scripts/reports/generate-sbom.sh): A shell script that generates SBOM (Software Bill of Materials)
-- [syft.yaml](../../scripts/config/syft.yaml): A configuration file for the SBOM generator
-- [scan-vulnerabilities.sh](../../scripts/reports/scan-vulnerabilities.sh): A shell script that performs CVE analysis
-- [grype.yaml](../../scripts/config/grype.yaml): A configuration file for the CVE scanner
-- [scan-dependencies/action.yaml](../../.github/actions/scan-dependencies/action.yaml): GitHub action to run the scripts as part of the CI/CD pipeline
-- [.gitignore](../../.gitignore): Excludes the `*sbom*report.json` and `*vulnerabilities*report.json` report files created during the process
+- [`generate-sbom.sh`](../../scripts/reports/generate-sbom.sh): A shell script that generates SBOM (Software Bill of Materials)
+- [`syft.yaml`](../../scripts/config/syft.yaml): A configuration file for the SBOM generator
+- [`scan-vulnerabilities.sh`](../../scripts/reports/scan-vulnerabilities.sh): A shell script that performs CVE analysis
+- [`grype.yaml`](../../scripts/config/grype.yaml): A configuration file for the CVE scanner
+- [`scan-dependencies/action.yaml`](../../.github/actions/scan-dependencies/action.yaml): GitHub action to run the scripts as part of the CI/CD pipeline
+- [`.gitignore`](../../.gitignore): Excludes the `*sbom*report.json` and `*vulnerabilities*report.json` report files created during the process
 
 ## Configuration checklist