From c54baf4f71267750bb233ca5b7cdda72c124b9d5 Mon Sep 17 00:00:00 2001 From: Soumaya Mauthoor Date: Thu, 10 Sep 2026 08:37:13 +0100 Subject: [PATCH 1/3] Update README.md --- README.md | 288 +++++++++++++++++++++++------------------------------- 1 file changed, 123 insertions(+), 165 deletions(-) diff --git a/README.md b/README.md index 4d888c0c..4846be3d 100644 --- a/README.md +++ b/README.md @@ -1,200 +1,158 @@ -# Table of contents +# github-standards -- [Table of contents](#table-of-contents) +Organisation-wide security tooling for `uktrade` repositories. It provides custom +pre-commit hooks and reusable, organisation-level GitHub Actions that keep secrets and +personal data out of our codebases, catching problems on the developer's machine before +they ever reach GitHub. + +## Table of contents +- [Overview](#overview) +- [How this fits into the Code Security Framework](#how-this-fits-into-the-code-security-framework) - [Features](#features) -- [Installation](#installation) -- [Testing](#testing) - - [Testing hooks locally](#testing-hooks-locally) - - [Running the hook command using python](#running-the-hook-command-using-python) - - [Running the hooks using docker](#running-the-hooks-using-docker) - - [Testing hooks from an external repository](#testing-hooks-from-an-external-repository) - - [Testing pre-commit hooks](#testing-pre-commit-hooks) - - [Testing commit-msg hooks](#testing-commit-msg-hooks) -- [Releasing](#releasing) -- [Usage](#usage) +- [Installing in your repository](#installing-in-your-repository) + - [Prerequisites](#prerequisites) - [My project is already using the pre-commit framework](#my-project-is-already-using-the-pre-commit-framework) - [My project is not using the pre-commit framework](#my-project-is-not-using-the-pre-commit-framework) - - [Post installation setup](#post-installation-setup) + - [Post-installation setup](#post-installation-setup) - [Optional hooks](#optional-hooks) -- [Trufflehog](#trufflehog) - - [Detectors](#detectors) - - [Excluding false positives](#excluding-false-positives) - - [Upgrading trufflehog](#upgrading-trufflehog) -- [Presidio](#presidio) - - [Excluding false positives](#excluding-false-positives-1) -- [Bandit](#bandit) - - [Upgrading bandit](#upgrading-bandit) -- [GitHub actions](#github-actions) - - [Testing changes](#testing-changes) +- [Security scans and excluding false positives](#security-scans-and-excluding-false-positives) + - [Trufflehog](#trufflehog) + - [Presidio](#presidio) +- [GitHub Actions](#github-actions) + - [Bandit (optional)](#bandit-optional) + - [Terraform workflow (optional)](#terraform-workflow-optional) - [FAQ](#faq) - - [My PR is failing due to a github action checking a Signed-off-by trailer](#my-pr-is-failing-due-to-a-github-action-checking-a-signed-off-by-trailer) - - [I'm receiving errors updating the rev version](#im-receiving-errors-updating-the-rev-version) - - [I'm seeing pre-commit hooks run multiple times in the logs](#im-seeing-pre-commit-hooks-run-multiple-times-in-the-logs) - -# Features - -- A set of custom pre-commit hooks, built using python that run security and personal data checks on git commits. Commits containing secrets, tokens or personal data are blocked at a local level. -- Uses the [pre-commit](https://pre-commit.com/index.html) framework to run scans in response to local git hook events -- Distributed as a docker image, hosted in GHCR for ease of installation in a git repository - -# Installation - -1. Install uv following these instructions https://docs.astral.sh/uv/getting-started/installation/ -1. Run `uv sync` to create a local virtual environment and install all dependencies -1. Make sure the venv created by uv is activated in the terminal before running any additional commands -1. Install trufflehog using `brew install trufflehog` - -# Testing - -## Testing hooks locally - -While developing hooks, there are multiple ways of verifying these on your local machine before raising a PR: - -### Running the hook command using python - -As the hooks are written using python, it is possible to call the python file containing the hook directly, passing the same arguments the pre-commit library would pass. There is a make command `validate-hook-python` that will run this in verbose mode and write debug messages to the terminal. - -For the run-security-scan hook, the command would look like this, where `--files` can be one or more filenames to scan: `python3 -m src.hooks.cli run_scan --verbose --files Dockerfile` - -### Running the hooks using docker - -As the hooks are run using a docker image within other repositories, it is a good idea to test your changes by building and running them using a local docker image. -There is a make command for each of the hooks, that will build and run that hook for you with the correct arguments. -For the run hook it is `make run-hook-docker`. -For the validate hook it is `make validate-hook-docker`. - -## Testing hooks from an external repository - -Using the pre-commit `try-repo` command, it is possible to test hooks locally in an external repo before releasing a new version. - -### Testing pre-commit hooks - -The pre-commit hooks receive a list of filenames that have changed in the commit as an argument. To test this hook locally, you need to pass a filename(s) to the hook using this command: -`pre-commit try-repo ../github-standards run-security-scan --hook-stage pre-commit --verbose --files Makefile` - -### Testing commit-msg hooks - -The commit-msg hook stage is passes a single parameter, which is the name of the file containing the current commit message. To test this locally, you need a file created with the contents being the commit message you want to test. For convenience, a test file has been added to tests/data that can be used with the below command -`pre-commit try-repo ../github-standards validate-security-scan --hook-stage commit-msg --commit-msg-filename tests/test_data/COMMIT_MSG.txt --verbose --all-files -v` - -# Releasing - -There is a github workflow that will automatically create a new docker tag, and a github release when a change to the `version` tag inside the `pyproject.toml` file is detected. When a new version needs to be released: - -1. Open the `pyproject.toml` file, and update the `version` tag to a new value. We use semantic versioning, see [this article](https://www.geeksforgeeks.org/software-engineering/introduction-semantic-versioning/) for help determining what the new version value should be -2. Run `uv sync` to ensure the package is set to the correct version -3. Open a PR into main. Once approved, merging will trigger a new release - -You will now have: - -- A github release using the new version, set to the be the latest version -- A docker image build and deployed to our [container registry](https://github.com/uktrade/github-standards/pkgs/container/github-standards) - -# Usage - -To use these hooks inside your project, some initial installation needs to be completed. Once installed, the hooks are self validating and will check for new releases each time they are run, with alerts when you need to upgrade. - -If you are already using the pre-commit framework in your project, then follow these instructions. If you are not using the pre-commit framework in your project, then follow these instructions instead +- [Contributing / developing these hooks](#contributing--developing-these-hooks) + +## Overview +This repository is the source of the organisation-level security checks, maintained in this +repository, that run against `uktrade` code. It bundles two things: + +- **Custom pre-commit hooks** that scan your commits locally, using + [Trufflehog](https://github.com/trufflesecurity/trufflehog) to detect secrets and tokens + and [Presidio](https://microsoft.github.io/presidio/) to detect personal data. Findings + cause the relevant local hook to fail, preventing the commit from completing. +- **Reusable, organisation-level GitHub Actions** that any `uktrade` repository can opt in + to via GitHub Custom Properties, including a backstop action for the local checks. See + [GitHub Actions](#github-actions) for detail. + +## How this fits into the Code Security Framework +This repository implements the pre-commit hooks and other repository-level controls +described in the +[Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/). +The framework explains the policy context — why these controls exist and who is responsible +for them — while this repository provides the mechanics. Where a section below links to the +framework, follow it to read the relevant control. + +## Features +- A set of custom pre-commit hooks, built using Python, that run security and personal data + checks on git commits. Commits containing secrets, tokens or personal data are blocked at + a local level. See the + [Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/) + for the pre-commit hooks control. +- Uses the [pre-commit](https://pre-commit.com/index.html) framework to run scans in + response to local git hook events. +- Reusable, organisation-level GitHub Actions, enabled through GitHub Custom Properties, + including a backstop action for the local checks. See + [GitHub Actions](#github-actions) for detail. +- Distributed as a Docker image, hosted in GHCR, so consuming repositories don't install + the scanners themselves. Once set up, the hooks are self-validating: they check for new + releases each time they run and alert you when you need to upgrade. + +## Installing in your repository +This section covers **adopting the hooks in your own repository**. If instead you want to +set up a local environment to develop the hooks themselves, see +[CONTRIBUTING.md](./CONTRIBUTING.md). + +To use these hooks inside your project, some initial installation needs to be completed. + +If you are already using the pre-commit framework in your project, then follow these +instructions. If you are not using the pre-commit framework in your project, then follow +these instructions instead. + +### Prerequisites +A consuming repository needs the following installed for the hooks to run: + +- **Python, with `pre-commit` installed** into a Python environment you control. Use + whichever tool you prefer — for example `uv`, `pip`, or `pipx`. `pre-commit` can be + installed as a dev dependency; it is not needed as a build or runtime requirement. +- **Docker**, required because the security-scan hooks run from the GHCR-hosted Docker + image. Trufflehog and Presidio are bundled inside that image, so you do **not** install + them separately. ### My project is already using the pre-commit framework - -1. Copy the yaml config for the `https://github.com/uktrade/github-standards` repo from the [example.pre-commit-config.yaml](./example.pre-commit-config.yaml) file into to the `.pre-commit-config` file in your repository -1. Run `pre-commit install --install-hooks --overwrite -t commit-msg -t pre-commit` to install both entry points for your repository +- Copy the repository entry from [`example.pre-commit-config.yaml`](./example.pre-commit-config.yaml) into `.pre-commit-config.yaml` in your repository +- Run `pre-commit install --install-hooks --overwrite -t commit-msg -t pre-commit` to install both entry points for your repository OR ### My project is not using the pre-commit framework +- Make sure `pre-commit` is installed (see [Prerequisites](#prerequisites)). +- Copy the [`example.pre-commit-config.yaml`](./example.pre-commit-config.yaml) file from this repository into the root of your repository, and rename it to `.pre-commit-config.yaml`. +- Run `pre-commit install --install-hooks --overwrite -t commit-msg -t pre-commit` to install both entry points for your repository -1. Install the `pre-commit` package using whatever package manager you're using. Alternatively, you can test without a package manager using `pip install pre-commit`. `pre-commit` can be installed as a dev dependency, it is not needed as a build requirement -1. Copy the [example.pre-commit-config.yaml](./example.pre-commit-config.yaml) file from this repository into the root of your repository, and rename to `.pre-commit-config`. -1. Run `pre-commit install --install-hooks --overwrite -t commit-msg -t pre-commit` to install both entry points for your repository - -## Post installation setup - -We use git tags for versioning, once you have copied the yaml to the `.pre-commit-config` file in your repository you need to make sure the `rev` property is set to the latest released version (in the example this is set to `main`). You can check the [releases page](https://github.com/uktrade/github-standards/releases) to get the latest tag to use in place of `main`. - -## Optional hooks - -There are a large number of pre-commit hooks that can be used to help with code quality and catching linting failures early. This page contains a list of some featured hooks https://pre-commit.com/hooks.html - -# Trufflehog +### Post-installation setup +We use git tags for versioning. Once you have copied the yaml into `.pre-commit-config.yaml` in your repository, make sure the `rev` property is set to the latest released version (in the example this is set to `main`). You can check the [releases page](https://github.com/uktrade/github-standards/releases) to get the latest tag to use in place of `main`. -We use a pinned version of trufflehog inside our security scanner. -When building the security scanner docker image locally, the version must be passed as a build arg using `--build-arg TRUFFLEHOG_VERSION=3.90.8` as an example. The Makefile file contains a hardcoded trufflehog version, this is only present for building locally it is not used for any released code +### Optional hooks +There are a large number of pre-commit hooks that can be used to help with code quality and catching linting failures early. This page contains a list of some featured hooks [https://pre-commit.com/hooks.html](https://pre-commit.com/hooks.html) -## Detectors +## Security scans and excluding false positives +This section explains what each scanner does and how to exclude a file when it reports a +false positive. These scans implement the secret and personal-data repository-level controls +described in the +[Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/). -We only use a pre-approved list of trufflehog detectors. Each allowed detector must extend the abstract class `AllowedTrufflehogVendor` and implement 2 methods: - -- `code`: This code has to match the value trufflehog has assigned to this vendor, you can find the list at https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto -- `endpoints`: This is a list of the endpoints this vendor is allowed to call to verify a token is valid. To find a list of endpoints used by this vendor, you need to inspect the trufflehog source code. Starting at https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors, find the name of the vendor you are adding. Inside the folder matching that name, you will find a `VENDOR_NAME.go` file that will contain an endpoint url at the top of the file that is used for verification. When adding this to the new vendor class, you need to remove any scheme or port and just paste the domain. E.g For Datadog the `datadogtoken.go` file has the endpoint `https://api.datadoghq.com`, but we add it as `api.datadoghq.com` - -## Excluding false positives - -If trufflehog has detected a potential secret in your code during a scan that you know is a false positive, you can exclude this from future trufflehog scans. Trufflehog only allows exclusions of an entire file, you cannot exclude individual secrets. To exclude a file from trufflehog: +### Trufflehog +We use [Trufflehog](https://github.com/trufflesecurity/trufflehog) to detect secrets and +tokens in your commits. +If Trufflehog has detected a potential secret in your code during a scan that you know is a false positive, you can exclude this from future Trufflehog scans. Trufflehog only allows exclusions of an entire file, you cannot exclude individual secrets. To exclude a file from Trufflehog: - If this file doesn't already exist, create a file at the root of the repository called `security-exclusions.txt` -- This file contains list of regexes to exclude from trufflehog, separated by a newline. Add the filename in your repository you want to exclude as a new entry in this file - -## Upgrading trufflehog - -When an upgrade to trufflehog is required - -1. Open the [repository variables](https://github.com/uktrade/github-standards/settings/variables/actions) page in github -1. Edit the TRUFFLEHOG_VERSION variable and set it to the new desired version. This version must have a corresponding image tag on the [trufflehog dockerhub page](https://hub.docker.com/r/trufflesecurity/trufflehog/tags) -1. Create a new github release following the [release instructions](#releasing) - -# Presidio +- This file contains a list of regexes to exclude from Trufflehog, separated by a newline. Add the filename in your repository you want to exclude as a new entry in this file +### Presidio To limit the risk of personal data leaks, we use Microsoft Presidio for scanning files to detect any personal information such as email address and name. -## Excluding false positives - If Presidio has detected potential personal data in your repo during a scan that you know is a false positive, you can exclude this from future Presidio scans. Presidio only allows exclusions of an entire file, you cannot exclude individual lines. To exclude a file from Presidio: - - If this file doesn't already exist, create a file at the root of the repository called `personal-data-exclusions.txt` -- This file contains list of regexes to exclude from Presidio, separated by a newline. Add the filename in your repository you want to exclude as a new entry in this file - -# Bandit - -Bandit is used for scanning python repositories to find common security issues. Bandit scans are performed using an org level github action, and focused on finding high severity issues that require immediate developer attention when a PR is raised - -## Upgrading bandit - -Although bandit provides a [github action](https://github.com/PyCQA/bandit-action) that can run scans during a PR being raised, this action always installs the latest version. As part of a cyber condition for using bandit, we are required to use a pinned version so a custom bandit job has been added to the `org.python-ci.yml` file in this repo. +- This file contains a list of regexes to exclude from Presidio, separated by a newline. Add the filename in your repository you want to exclude as a new entry in this file -There is a `bandit-version` `env` variable in this job, that is used to install a specific bandit version. This variable must match a github [release version](https://github.com/PyCQA/bandit/releases) +## GitHub Actions +This repository contains GitHub Actions that are triggered by a set of GitHub Rulesets +defined at the organisation level. Any repository in the `uktrade` organisation can opt in +to using these GitHub Actions by adding GitHub Custom Properties to the repository. The set +of available actions may change over time. -# GitHub Actions +One of these actions acts as a backstop for the pre-commit hooks: it re-runs the Trufflehog +and Presidio scans and validates a commit trailer or attestation indicating the pre-commit +hook ran (for example, catching commits made with `--no-verify`). If it finds a secret or +personal data, or the expected attestation is missing, the check fails and the PR is blocked. -This repository contains GitHub actions that are triggered by a set of GitHub Rulesets defined at the organisation level. Any repository in the uktrade organisation can opt in to using these GitHub actions by adding GitHub Custom properties to the repository. +> **⚠️ TO BE REMOVED — the Bandit scan and Terraform workflow below are optional and interim. +> Remove this section once they are replaced by the Datadog Code Security integration.** -## Terraform Workflow +### Bandit (optional) +Bandit is used for scanning Python repositories to find common security issues. Bandit scans are performed using an org-level GitHub Action, and focused on finding high severity issues that require immediate developer attention when a PR is raised. +### Terraform workflow (optional) The reusable Terraform workflow defined in this repository checks Terraform code in your repository against a number of standard tools: `terraform fmt`, `terraform validate` and `tflint`. If any of these checks do not exit successfully, the job will fail and you will need to make changes to your code to get it through the CI checks. Because a lot of the Terraform modules we use in our code are hosted in private GitHub repositories, we have had to create a GitHub App to allow them to be pulled into the GitHub Action at runtime. Therefore, there are some pre-requisites you must satisfy before this reusable workflow will work on your repository: +- You must grant your repository access to the organisation-level secrets `TERRAFORM_MODULE_ACCESS_APP_ID` and `TERRAFORM_MODULE_ACCESS_PRIVATE_KEY` [here](https://github.com/organizations/uktrade/settings/secrets/actions) - if you do not have access to do this, SRE can facilitate it for you. +- You must grant the GitHub App `uktrade-terraform-module-access` [here](https://github.com/organizations/uktrade/settings/installations/98143778) repository access to both your repository **and** the repository hosting the module your code is using. +- You must select the Terraform (HCL) option in the language custom property on your repository. -1. You must grant your repository access to the organisation-level secrets `TERRAFORM_MODULE_ACCESS_APP_ID` and `TERRAFORM_MODULE_ACCESS_PRIVATE_KEY` [here](https://github.com/organizations/uktrade/settings/secrets/actions) - if you do not have access to do this, SRE can facilitate it for you. -2. You must grant the GitHub App `uktrade-terraform-module-access` [here](https://github.com/organizations/uktrade/settings/installations/98143778) repository access to both your repository **and** the repository hosting the module your code is using. -3. You must select the `Terraform (HCL)` option in the `language` custom property on your repository. - -## Testing changes - -As this github-standards repository uses the GitHub Custom properties, during a PR for this repository the workflows that are run are the version in the main branch. This makes it difficult to test changes to the workflows, as although the files exist in this repo, any changes to them will not take effect until the PR is merged into main. At that point, any issues with the workflow will be present in all repositories using the GitHub Custom properties. - -As these workflow runs aren't visible on the PR screen, you need to use view the GitHub actions filter found [here](https://github.com/uktrade/github-standards/.github/actions?query=event%3Apush) -To solve this, an additional GitHub action on_push trigger has been added to each of the org wide workflows. This trigger will fire on any push event where an org wide workflow yaml file has changed. When raising a PR, the same GitHub workflow will now appear multiple times when a change to a workflow yaml file is made. Once which is the required status enforced by the GitHub Ruleset and is using the workflow version in the main branch, and a second run which is the workflow version in the branch raising the PR. - -# FAQ - -## My PR is failing due to a github action checking a Signed-off-by trailer - -- Have you run your commit with the `--no-verify` argument? If so this will skip the security scans and the validation hooks needed to pass the github action -- Have you installed the pre-commit commit-msg hook? To check this, open your repository and check the ./hooks folder. There should be an executable file named `commit-msg` that is ran by the pre-commit framework +## FAQ -## I'm receiving errors updating the rev version +### My PR is failing due to a GitHub Action checking a Signed-off-by trailer +- Have you run your commit with the `--no-verify` argument? If so this will skip the security scans and the validation hooks needed to pass the GitHub Action +- Have you installed the pre-commit commit-msg hook? To check this, open your repository and check the `./hooks` folder. There should be an executable file named `commit-msg` that is run by the pre-commit framework +### I'm receiving errors updating the rev version - Try running `pre-commit gc` and `pre-commit clean` to remove any previous cached versions pre-commit has locally -## I'm seeing pre-commit hooks run multiple times in the logs +### I'm seeing pre-commit hooks run multiple times in the logs +The scans run using the [https://github.com/uktrade/github-standards](https://github.com/uktrade/github-standards) repo are scoped to run across defined git hook stages, controlled via a config file inside this repo. However if you are using other pre-commit hooks, for example the ruff formatter, you may see these scans appear multiple times. Adding a `stages` array to your `.pre-commit-config.yaml` file can solve this, where the value is `[pre-commit]`. -The scans run using the https://github.com/uktrade/github-standards repo are scoped to run across defined git hook stages, controlled via a config file inside this repo. However if you are using other pre-commit hooks, for example the ruff formatter, you may see these scans appear multiple times. Adding a `stages` array to your `.pre-commit-config.yaml` file can solve this, where the value is [pre-commit] +## Contributing / developing these hooks +Building, testing, releasing, adding Trufflehog detectors, upgrading the bundled tools and +testing workflow changes are all covered in [CONTRIBUTING.md](./CONTRIBUTING.md). From 3dbf1bbcf19c272d4259369c8df9e825cdbb3277 Mon Sep 17 00:00:00 2001 From: Soumaya Mauthoor Date: Thu, 10 Sep 2026 08:38:24 +0100 Subject: [PATCH 2/3] Create CONTRIBUTING.md --- CONTRIBUTING.md | 112 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..b7d1ee4f --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,112 @@ +# Contributing to github-standards + +This guide is for developers and maintainers of the hooks and workflows themselves. If you +only want to adopt the hooks in your own repository, see the [README](./README.md) instead. + +## Table of contents +- [Local development setup](#local-development-setup) +- [Testing](#testing) + - [Testing hooks locally](#testing-hooks-locally) + - [Running the hook command using Python](#running-the-hook-command-using-python) + - [Running the hooks using Docker](#running-the-hooks-using-docker) + - [Testing hooks from an external repository](#testing-hooks-from-an-external-repository) + - [Testing pre-commit hooks](#testing-pre-commit-hooks) + - [Testing commit-msg hooks](#testing-commit-msg-hooks) + - [Testing workflow changes](#testing-workflow-changes) +- [Maintaining the bundled scanners](#maintaining-the-bundled-scanners) + - [Trufflehog](#trufflehog) + - [Detectors](#detectors) + - [Upgrading Trufflehog](#upgrading-trufflehog) + - [Bandit (optional)](#bandit-optional) +- [Releasing](#releasing) + +## Local development setup +This sets up a local environment to develop the hooks themselves. Consumers of the hooks do +not need any of this — the hooks run from the GHCR Docker image (see the [README](./README.md)). + +- Install `uv` following these instructions [https://docs.astral.sh/uv/getting-started/installation/](https://docs.astral.sh/uv/getting-started/installation/) +- Run `uv sync` to create a local virtual environment and install all dependencies +- Make sure the venv created by `uv` is activated in the terminal before running any additional commands +- Install Trufflehog by following the [official Trufflehog installation instructions](https://github.com/trufflesecurity/trufflehog#floppy_disk-installation) + +## Testing + +### Testing hooks locally +While developing hooks, there are multiple ways of verifying these on your local machine before raising a PR: + +#### Running the hook command using Python +As the hooks are written using Python, it is possible to call the Python file containing the hook directly, passing the same arguments the pre-commit library would pass. There is a make command `validate-hook-python` that will run this in verbose mode and write debug messages to the terminal. + +For the `run-security-scan` hook, the command would look like this, where `--files` can be one or more filenames to scan: + +``` +python3 -m src.hooks.cli run_scan --verbose --files Dockerfile +``` + +#### Running the hooks using Docker +As the hooks are run using a Docker image within other repositories, it is a good idea to test your changes by building and running them using a local Docker image. +There is a make command for each of the hooks, that will build and run that hook for you with the correct arguments. + +- For the run hook it is `make run-hook-docker`. +- For the validate hook it is `make validate-hook-docker`. + +### Testing hooks from an external repository +Using the `pre-commit try-repo` command, it is possible to test hooks locally in an external repo before releasing a new version. + +#### Testing pre-commit hooks +The pre-commit hooks receive a list of filenames that have changed in the commit as an argument. To test this hook locally, you need to pass a filename(s) to the hook using this command: + +``` +pre-commit try-repo ../github-standards run-security-scan --hook-stage pre-commit --verbose --files Makefile +``` + +#### Testing commit-msg hooks +The commit-msg hook stage receives a single argument, which is the name of the file containing the current commit message. To test this locally, you need a file created with the contents being the commit message you want to test. For convenience, a test file has been added to `tests/test_data/` that can be used with the below command: + +``` +pre-commit try-repo ../github-standards validate-security-scan --hook-stage commit-msg --commit-msg-filename tests/test_data/COMMIT_MSG.txt --verbose --all-files -v +``` + +### Testing workflow changes +Because this `github-standards` repository uses GitHub Custom Properties, the workflows that run during a PR for this repository are the versions on the `main` branch. This makes it difficult to test changes to the workflows: although the files exist in this repo, any changes to them do not take effect until the PR is merged into `main`. At that point, any issues with the workflow would already be present in all repositories using the GitHub Custom Properties. + +Because these ruleset-triggered workflow runs are not shown on the PR screen, you can view them through the GitHub Actions filter found [here](https://github.com/uktrade/github-standards/.github/actions?query=event%3Apush). + +To make changes testable before merge, an additional `on_push` trigger has been added to each of the organisation-wide workflows. This trigger fires on any push event where an organisation-wide workflow yaml file has changed. As a result, when you raise a PR that changes a workflow yaml file, the same GitHub workflow appears twice: + +- the **ruleset-required run**, which is the status enforced by the GitHub Ruleset and uses the workflow version on the `main` branch; and +- the **branch-triggered test run**, which uses the workflow version on the branch raising the PR. + +## Maintaining the bundled scanners + +### Trufflehog +We use a pinned version of Trufflehog inside our security scanner. +When building the security scanner Docker image locally, the version must be passed as a build arg using `--build-arg TRUFFLEHOG_VERSION=3.90.8` as an example. The Makefile file contains a hardcoded Trufflehog version; this is only present for building locally, it is not used for any released code. + +#### Detectors +We only use a pre-approved list of Trufflehog detectors. Each allowed detector must extend the abstract class `AllowedTrufflehogVendor` and implement 2 methods: +- `code`: This code has to match the value Trufflehog has assigned to this vendor, you can find the list at [https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto](https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto) +- `endpoints`: This is a list of the endpoints this vendor is allowed to call to verify a token is valid. To find a list of endpoints used by this vendor, you need to inspect the Trufflehog source code. Starting at [https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors](https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors), find the name of the vendor you are adding. Inside the folder matching that name, you will find a `VENDOR_NAME.go` file that will contain an endpoint url at the top of the file that is used for verification. When adding this to the new vendor class, you need to remove any scheme or port and just paste the domain. E.g. for Datadog the `datadogtoken.go` file has the endpoint `https://api.datadoghq.com`, but we add it as `api.datadoghq.com` + +#### Upgrading Trufflehog +When an upgrade to Trufflehog is required +- Open the [repository variables](https://github.com/uktrade/github-standards/settings/variables/actions) page in GitHub +- Edit the `TRUFFLEHOG_VERSION` variable and set it to the new desired version. This version must have a corresponding image tag on the [Trufflehog dockerhub page](https://hub.docker.com/r/trufflesecurity/trufflehog/tags) +- Create a new GitHub release following the [release instructions](#releasing) + +### Bandit (optional) +> **⚠️ TO BE REMOVED — the Bandit scan is optional and interim. Remove this section once +> it is replaced by the Datadog Code Security integration.** + +Although Bandit provides a [GitHub Action](https://github.com/PyCQA/bandit-action) that can run scans during a PR being raised, this action always installs the latest version. As part of a cyber condition for using Bandit, we are required to use a pinned version so a custom Bandit job has been added to the `org.python-ci.yml` file in this repo. +There is a `bandit-version` env variable in this job, that is used to install a specific Bandit version. This variable must match a GitHub [release version](https://github.com/PyCQA/bandit/releases) + +## Releasing +There is a GitHub workflow that will automatically create a new Docker tag, and a GitHub release when a change to the version tag inside the `pyproject.toml` file is detected. When a new version needs to be released: +- Open the `pyproject.toml` file, and update the version tag to a new value. We use semantic versioning, see [this article](https://www.geeksforgeeks.org/software-engineering/introduction-semantic-versioning/) for help determining what the new version value should be +- Run `uv sync` to ensure the package is set to the correct version +- Open a PR into main. Once approved, merging will trigger a new release + +You will now have: +- A GitHub release using the new version, set to be the latest version +- A Docker image built and deployed to our [container registry](https://github.com/uktrade/github-standards/pkgs/container/github-standards) From 9158a7efa97e7e2f687f13124375bbdc454314f2 Mon Sep 17 00:00:00 2001 From: Soumaya Mauthoor Date: Sat, 12 Sep 2026 12:57:59 +0100 Subject: [PATCH 3/3] Add files via upload --- CONTRIBUTING.md | 233 +++++++++++++++++++++++++++++++++++++----------- README.md | 52 +++-------- 2 files changed, 192 insertions(+), 93 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b7d1ee4f..fc30ae5f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,110 +3,239 @@ This guide is for developers and maintainers of the hooks and workflows themselves. If you only want to adopt the hooks in your own repository, see the [README](./README.md) instead. +The repository contains two things that are developed, tested and released in different +ways, so this guide is organised around them: + +- **[Part A: the pre-commit hooks](#part-a-the-pre-commit-hooks)** — Python hooks + distributed as a Docker image and consumed through the pre-commit framework. +- **[Part B: the organisation workflows](#part-b-the-organisation-workflows)** — + reusable, organisation-level GitHub Actions triggered by GitHub Rulesets and Custom + Properties. +- **[Part C: troubleshooting](#part-c-troubleshooting)** — common problems when developing + or releasing either of the above. + ## Table of contents -- [Local development setup](#local-development-setup) -- [Testing](#testing) + +- [Part A: the pre-commit hooks](#part-a-the-pre-commit-hooks) + - [Local development setup](#local-development-setup) - [Testing hooks locally](#testing-hooks-locally) - [Running the hook command using Python](#running-the-hook-command-using-python) - [Running the hooks using Docker](#running-the-hooks-using-docker) - [Testing hooks from an external repository](#testing-hooks-from-an-external-repository) - [Testing pre-commit hooks](#testing-pre-commit-hooks) - [Testing commit-msg hooks](#testing-commit-msg-hooks) - - [Testing workflow changes](#testing-workflow-changes) -- [Maintaining the bundled scanners](#maintaining-the-bundled-scanners) - - [Trufflehog](#trufflehog) + - [Maintaining the bundled scanners](#maintaining-the-bundled-scanners) + - [Trufflehog](#trufflehog) - [Detectors](#detectors) - [Upgrading Trufflehog](#upgrading-trufflehog) + - [Releasing](#releasing) +- [Part B: the organisation workflows](#part-b-the-organisation-workflows) + - [How the workflows are triggered](#how-the-workflows-are-triggered) + - [Testing workflow changes](#testing-workflow-changes) - [Bandit (optional)](#bandit-optional) -- [Releasing](#releasing) +- [Part C: troubleshooting](#part-c-troubleshooting) -## Local development setup -This sets up a local environment to develop the hooks themselves. Consumers of the hooks do -not need any of this — the hooks run from the GHCR Docker image (see the [README](./README.md)). +## Part A: the pre-commit hooks -- Install `uv` following these instructions [https://docs.astral.sh/uv/getting-started/installation/](https://docs.astral.sh/uv/getting-started/installation/) -- Run `uv sync` to create a local virtual environment and install all dependencies -- Make sure the venv created by `uv` is activated in the terminal before running any additional commands -- Install Trufflehog by following the [official Trufflehog installation instructions](https://github.com/trufflesecurity/trufflehog#floppy_disk-installation) +### Local development setup -## Testing +This sets up a local environment to develop the pre-commit hooks. Consumers of the hooks do +not need any of this — the hooks run from the GHCR Docker image (see the +[README](./README.md)). + +- Install uv following these instructions + [https://docs.astral.sh/uv/getting-started/installation/](https://docs.astral.sh/uv/getting-started/installation/) +- Run `uv sync` to create a local virtual environment and install all dependencies +- Make sure the venv created by uv is activated in the terminal before running any + additional commands +- Install Trufflehog by following the + [official Trufflehog installation instructions](https://github.com/trufflesecurity/trufflehog#floppy_disk-installation) ### Testing hooks locally -While developing hooks, there are multiple ways of verifying these on your local machine before raising a PR: + +While developing hooks, there are multiple ways of verifying these on your local machine +before raising a PR. #### Running the hook command using Python -As the hooks are written using Python, it is possible to call the Python file containing the hook directly, passing the same arguments the pre-commit library would pass. There is a make command `validate-hook-python` that will run this in verbose mode and write debug messages to the terminal. -For the `run-security-scan` hook, the command would look like this, where `--files` can be one or more filenames to scan: +As the hooks are written using Python, it is possible to call the Python file containing the +hook directly, passing the same arguments the pre-commit library would pass. There is a make +command `validate-hook-python` that will run this in verbose mode and write debug messages +to the terminal. -``` +For the `run-security-scan` hook, the command would look like this, where `--files` can be +one or more filenames to scan: + +```bash python3 -m src.hooks.cli run_scan --verbose --files Dockerfile ``` #### Running the hooks using Docker -As the hooks are run using a Docker image within other repositories, it is a good idea to test your changes by building and running them using a local Docker image. -There is a make command for each of the hooks, that will build and run that hook for you with the correct arguments. + +As the hooks are run using a Docker image within other repositories, it is a good idea to +test your changes by building and running them using a local Docker image. There is a make +command for each of the hooks, that will build and run that hook for you with the correct +arguments: - For the run hook it is `make run-hook-docker`. - For the validate hook it is `make validate-hook-docker`. ### Testing hooks from an external repository -Using the `pre-commit try-repo` command, it is possible to test hooks locally in an external repo before releasing a new version. + +Using the `pre-commit try-repo` command, it is possible to test hooks locally in an external +repo before releasing a new version. #### Testing pre-commit hooks -The pre-commit hooks receive a list of filenames that have changed in the commit as an argument. To test this hook locally, you need to pass a filename(s) to the hook using this command: -``` +The pre-commit hooks receive a list of filenames that have changed in the commit as an +argument. To test this hook locally, you need to pass a filename(s) to the hook: + +```bash pre-commit try-repo ../github-standards run-security-scan --hook-stage pre-commit --verbose --files Makefile ``` #### Testing commit-msg hooks -The commit-msg hook stage receives a single argument, which is the name of the file containing the current commit message. To test this locally, you need a file created with the contents being the commit message you want to test. For convenience, a test file has been added to `tests/test_data/` that can be used with the below command: -``` +The commit-msg hook stage receives a single argument, which is the name of the file +containing the current commit message. To test this locally, you need a file created with +the contents being the commit message you want to test. For convenience, a test file has +been added to `tests/test_data/` that can be used with the below command: + +```bash pre-commit try-repo ../github-standards validate-security-scan --hook-stage commit-msg --commit-msg-filename tests/test_data/COMMIT_MSG.txt --verbose --all-files -v ``` -### Testing workflow changes -Because this `github-standards` repository uses GitHub Custom Properties, the workflows that run during a PR for this repository are the versions on the `main` branch. This makes it difficult to test changes to the workflows: although the files exist in this repo, any changes to them do not take effect until the PR is merged into `main`. At that point, any issues with the workflow would already be present in all repositories using the GitHub Custom Properties. +### Maintaining the bundled scanners -Because these ruleset-triggered workflow runs are not shown on the PR screen, you can view them through the GitHub Actions filter found [here](https://github.com/uktrade/github-standards/.github/actions?query=event%3Apush). +#### Trufflehog -To make changes testable before merge, an additional `on_push` trigger has been added to each of the organisation-wide workflows. This trigger fires on any push event where an organisation-wide workflow yaml file has changed. As a result, when you raise a PR that changes a workflow yaml file, the same GitHub workflow appears twice: +We use a pinned version of Trufflehog inside our security scanner. When building the +security scanner Docker image locally, the version must be passed as a build arg using +`--build-arg TRUFFLEHOG_VERSION=3.90.8` as an example. The Makefile contains a hardcoded +Trufflehog version; this is only present for building locally, it is not used for any +released code. -- the **ruleset-required run**, which is the status enforced by the GitHub Ruleset and uses the workflow version on the `main` branch; and -- the **branch-triggered test run**, which uses the workflow version on the branch raising the PR. +#### Detectors -## Maintaining the bundled scanners +We only use a pre-approved list of Trufflehog detectors. Each allowed detector must extend +the abstract class `AllowedTrufflehogVendor` and implement 2 methods: + +- **code**: this code has to match the value Trufflehog has assigned to this vendor, you can + find the list at + [https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto](https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto) +- **endpoints**: this is a list of the endpoints this vendor is allowed to call to verify a + token is valid. To find a list of endpoints used by this vendor, you need to inspect the + Trufflehog source code. Starting at + [https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors](https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors), + find the name of the vendor you are adding. Inside the folder matching that name, you will + find a `VENDOR_NAME.go` file that will contain an endpoint url at the top of the file that + is used for verification. When adding this to the new vendor class, you need to remove any + scheme or port and just paste the domain. For example, for Datadog the `datadogtoken.go` + file has the endpoint `https://api.datadoghq.com`, but we add it as `api.datadoghq.com` -### Trufflehog -We use a pinned version of Trufflehog inside our security scanner. -When building the security scanner Docker image locally, the version must be passed as a build arg using `--build-arg TRUFFLEHOG_VERSION=3.90.8` as an example. The Makefile file contains a hardcoded Trufflehog version; this is only present for building locally, it is not used for any released code. +#### Upgrading Trufflehog -#### Detectors -We only use a pre-approved list of Trufflehog detectors. Each allowed detector must extend the abstract class `AllowedTrufflehogVendor` and implement 2 methods: -- `code`: This code has to match the value Trufflehog has assigned to this vendor, you can find the list at [https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto](https://github.com/trufflesecurity/trufflehog/blob/main/proto/detectors.proto) -- `endpoints`: This is a list of the endpoints this vendor is allowed to call to verify a token is valid. To find a list of endpoints used by this vendor, you need to inspect the Trufflehog source code. Starting at [https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors](https://github.com/trufflesecurity/trufflehog/tree/main/pkg/detectors), find the name of the vendor you are adding. Inside the folder matching that name, you will find a `VENDOR_NAME.go` file that will contain an endpoint url at the top of the file that is used for verification. When adding this to the new vendor class, you need to remove any scheme or port and just paste the domain. E.g. for Datadog the `datadogtoken.go` file has the endpoint `https://api.datadoghq.com`, but we add it as `api.datadoghq.com` +When an upgrade to Trufflehog is required: -#### Upgrading Trufflehog -When an upgrade to Trufflehog is required -- Open the [repository variables](https://github.com/uktrade/github-standards/settings/variables/actions) page in GitHub -- Edit the `TRUFFLEHOG_VERSION` variable and set it to the new desired version. This version must have a corresponding image tag on the [Trufflehog dockerhub page](https://hub.docker.com/r/trufflesecurity/trufflehog/tags) +- Open the [repository variables](https://github.com/uktrade/github-standards/settings/variables/actions) + page in GitHub +- Edit the `TRUFFLEHOG_VERSION` variable and set it to the new desired version. This version + must have a corresponding image tag on the + [Trufflehog dockerhub page](https://hub.docker.com/r/trufflesecurity/trufflehog/tags) - Create a new GitHub release following the [release instructions](#releasing) -### Bandit (optional) -> **⚠️ TO BE REMOVED — the Bandit scan is optional and interim. Remove this section once -> it is replaced by the Datadog Code Security integration.** +### Releasing -Although Bandit provides a [GitHub Action](https://github.com/PyCQA/bandit-action) that can run scans during a PR being raised, this action always installs the latest version. As part of a cyber condition for using Bandit, we are required to use a pinned version so a custom Bandit job has been added to the `org.python-ci.yml` file in this repo. -There is a `bandit-version` env variable in this job, that is used to install a specific Bandit version. This variable must match a GitHub [release version](https://github.com/PyCQA/bandit/releases) +There is a GitHub workflow that will automatically create a new Docker tag, and a GitHub +release, when a change to the version tag inside the `pyproject.toml` file is detected. When +a new version needs to be released: -## Releasing -There is a GitHub workflow that will automatically create a new Docker tag, and a GitHub release when a change to the version tag inside the `pyproject.toml` file is detected. When a new version needs to be released: -- Open the `pyproject.toml` file, and update the version tag to a new value. We use semantic versioning, see [this article](https://www.geeksforgeeks.org/software-engineering/introduction-semantic-versioning/) for help determining what the new version value should be +- Open the `pyproject.toml` file, and update the version tag to a new value. We use semantic + versioning, see [this article](https://www.geeksforgeeks.org/software-engineering/introduction-semantic-versioning/) + for help determining what the new version value should be - Run `uv sync` to ensure the package is set to the correct version - Open a PR into main. Once approved, merging will trigger a new release You will now have: + - A GitHub release using the new version, set to be the latest version -- A Docker image built and deployed to our [container registry](https://github.com/uktrade/github-standards/pkgs/container/github-standards) +- A Docker image built and deployed to our + [container registry](https://github.com/uktrade/github-standards/pkgs/container/github-standards) + +## Part B: the organisation workflows + +### How the workflows are triggered + +The organisation-level GitHub Actions in this repository are triggered by GitHub Rulesets +defined at the organisation level, and repositories opt in through GitHub Custom Properties. +This means workflow changes take effect organisation-wide as soon as they are merged into +main, so they must be tested on the branch before merge. + +There is no local development setup for the workflows: they can only be exercised by pushing +to a branch and inspecting the resulting runs, as described below. + +### Testing workflow changes + +Because this github-standards repository uses GitHub Custom Properties, the workflows that +run during a PR for this repository are the versions on the main branch. This makes it +difficult to test changes to the workflows: although the files exist in this repo, any +changes to them do not take effect until the PR is merged into main. At that point, any +issues with the workflow would already be present in all repositories using the GitHub +Custom Properties. + +To make changes testable before merge, an additional `on_push` trigger has been added to +each of the organisation-wide workflows. This trigger fires on any push event where an +organisation-wide workflow yaml file has changed. As a result, when you raise a PR that +changes a workflow yaml file, the same GitHub workflow appears twice: + +- the **ruleset-required run**, which is the status enforced by the GitHub Ruleset and uses + the workflow version on the main branch; and +- the **branch-triggered test run**, which uses the workflow version on the branch raising + the PR. + +Always check the branch-triggered run when reviewing workflow changes. + +### Bandit (optional) + +**⚠️ TO BE REMOVED — the Bandit scan is optional and interim. Remove this section once it is +replaced by the Datadog Code Security integration.** + +Although Bandit provides a [GitHub Action](https://github.com/PyCQA/bandit-action) that can +run scans during a PR being raised, this action always installs the latest version. As part +of a cyber condition for using Bandit, we are required to use a pinned version, so a custom +Bandit job has been added to the `org.python-ci.yml` file in this repo. There is a +`bandit-version` env variable in this job, that is used to install a specific Bandit +version. This variable must match a Bandit +[release version](https://github.com/PyCQA/bandit/releases). + +## Part C: troubleshooting + +### I can't see the ruleset-triggered workflow runs on the PR screen + +Ruleset-triggered runs are not shown on the PR screen. View them through the GitHub Actions +filter found [here](https://github.com/uktrade/github-standards/.github/actions?query=event%3Apush). + +### My workflow change doesn't seem to have taken effect + +You are almost certainly looking at the ruleset-required run, which uses the workflow version +on main. Check the branch-triggered test run instead — see +[Testing workflow changes](#testing-workflow-changes). + + + +### My local Docker run is using stale code + +The `make *-hook-docker` commands rebuild the image, but Docker layer caching can retain an +old Trufflehog binary if the `TRUFFLEHOG_VERSION` build arg has changed. Rebuild without +cache, and remember the Makefile version is for local builds only. + +### `pre-commit try-repo` is picking up an old version of the hooks + +Run `pre-commit gc` and `pre-commit clean` to clear pre-commit's local cache, then re-run the +`try-repo` command. + +### Merging my PR didn't trigger a release + +The release workflow only fires when the version tag in `pyproject.toml` changes. Check that +you bumped the version and ran `uv sync` so the lockfile matches — see +[Releasing](#releasing). diff --git a/README.md b/README.md index 4846be3d..8dd035c1 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,9 @@ # github-standards -Organisation-wide security tooling for `uktrade` repositories. It provides custom -pre-commit hooks and reusable, organisation-level GitHub Actions that keep secrets and -personal data out of our codebases, catching problems on the developer's machine before -they ever reach GitHub. +Organisation-wide security tooling to support the +[Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/). ## Table of contents -- [Overview](#overview) -- [How this fits into the Code Security Framework](#how-this-fits-into-the-code-security-framework) -- [Features](#features) - [Installing in your repository](#installing-in-your-repository) - [Prerequisites](#prerequisites) - [My project is already using the pre-commit framework](#my-project-is-already-using-the-pre-commit-framework) @@ -25,8 +20,7 @@ they ever reach GitHub. - [Contributing / developing these hooks](#contributing--developing-these-hooks) ## Overview -This repository is the source of the organisation-level security checks, maintained in this -repository, that run against `uktrade` code. It bundles two things: +This repository bundles two things: - **Custom pre-commit hooks** that scan your commits locally, using [Trufflehog](https://github.com/trufflesecurity/trufflehog) to detect secrets and tokens @@ -36,39 +30,17 @@ repository, that run against `uktrade` code. It bundles two things: to via GitHub Custom Properties, including a backstop action for the local checks. See [GitHub Actions](#github-actions) for detail. -## How this fits into the Code Security Framework -This repository implements the pre-commit hooks and other repository-level controls -described in the -[Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/). -The framework explains the policy context — why these controls exist and who is responsible -for them — while this repository provides the mechanics. Where a section below links to the -framework, follow it to read the relevant control. - -## Features -- A set of custom pre-commit hooks, built using Python, that run security and personal data - checks on git commits. Commits containing secrets, tokens or personal data are blocked at - a local level. See the - [Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/) - for the pre-commit hooks control. -- Uses the [pre-commit](https://pre-commit.com/index.html) framework to run scans in - response to local git hook events. -- Reusable, organisation-level GitHub Actions, enabled through GitHub Custom Properties, - including a backstop action for the local checks. See - [GitHub Actions](#github-actions) for detail. -- Distributed as a Docker image, hosted in GHCR, so consuming repositories don't install - the scanners themselves. Once set up, the hooks are self-validating: they check for new - releases each time they run and alert you when you need to upgrade. - -## Installing in your repository +## Installing pre-commit hooks This section covers **adopting the hooks in your own repository**. If instead you want to set up a local environment to develop the hooks themselves, see [CONTRIBUTING.md](./CONTRIBUTING.md). -To use these hooks inside your project, some initial installation needs to be completed. +The hooks use the [pre-commit](https://pre-commit.com/index.html) framework to run scans in +response to local git hook events. The hooks are distributed as a Docker image, hosted in GHCR. +Once set up, the hooks are self-validating: they check for new +releases each time they run and alert you when you need to upgrade. -If you are already using the pre-commit framework in your project, then follow these -instructions. If you are not using the pre-commit framework in your project, then follow -these instructions instead. +To use these hooks inside your project, some initial installation needs to be completed. ### Prerequisites A consuming repository needs the following installed for the hooks to run: @@ -97,11 +69,9 @@ We use git tags for versioning. Once you have copied the yaml into `.pre-commit- ### Optional hooks There are a large number of pre-commit hooks that can be used to help with code quality and catching linting failures early. This page contains a list of some featured hooks [https://pre-commit.com/hooks.html](https://pre-commit.com/hooks.html) -## Security scans and excluding false positives +## Security scans This section explains what each scanner does and how to exclude a file when it reports a -false positive. These scans implement the secret and personal-data repository-level controls -described in the -[Code Security Framework](https://platform.readme.trade.gov.uk/managed/features/code-security-framework/). +false positive. ### Trufflehog We use [Trufflehog](https://github.com/trufflesecurity/trufflehog) to detect secrets and