This policy explains:

• how members of the public can responsibly report vulnerabilities to the Department for Business and Trade (DBT)
• how DBT developers can follow secure development practices
• how DBT developers can apply DBT's required security controls in GitHub

This section is for members of the public and external security researchers. DBT staff should instead report vulnerabilities directly to the Cyber Security team.

If you believe you have found a security vulnerability, please submit a report via our HackerOne form.

Please include:

• Where the issue can be observed (URL, IP address or page)
• A brief description (e.g. “XSS vulnerability”)
• Safe, non-destructive reproduction steps

Scope

• In scope: digital services operated by DBT, including repositories in the uktrade GitHub organisation
• Out of scope: denial of service, social engineering, physical attacks, and reports from automated scanners without a working proof of concept

Disclosure guidelines

• Do not share vulnerability details beyond DBT and the asset owner
• HackerOne accounts are optional, but allow you to receive updates on your report
• You must agree to HackerOne’s Terms, Privacy Policy, and Disclosure Guidelines
• DBT’s Cyber Security team assists with coordination, but the asset owner is responsible for remediation

Safe harbour

DBT will not seek prosecution of researchers who act in good faith: stay within the scope above, avoid destructive testing, and do not access, modify or retain other users’ data.

These requirements apply to all DBT developers.

Leaked secrets (API keys, tokens, passwords) are among the most common causes of security breaches, and personal or otherwise sensitive data must be kept out of GitHub just as carefully. Sensitive data includes operational details — such as internal hostnames, IP ranges and security thresholds — that would make DBT systems easier to attack. Developers must:

• Never commit secrets or sensitive data to GitHub
• Use secure storage for managing secrets
• Ensure no secrets or sensitive data appear in pull requests (PRs), logs or config files

The GitHub Security Standards (DBT staff access only) explain what counts as a secret and how to manage secrets securely.

If a secret or sensitive data is pushed to GitHub follow the GitHub Repository Incident Playbook (DBT staff access only)

Vulnerabilities can enter through your own code or through the dependencies it relies on. Several GitHub scans guard against them:

• CodeQL analyses your own code, both on pull requests and on a scheduled basis
• Dependabot flags vulnerable dependencies already in your project, and Dependabot security updates raise PRs to fix them automatically
• Dependency review flags vulnerable dependencies a pull request would add before it is merged

We are also investigating IDE scanning and non-GitHub native code security scanning solutions.

Any alerts these scans raise must be triaged, not ignored. Fix the vulnerability, or dismiss the alert with a documented reason (e.g. false positive, not exploitable in this context)

Alerts must be resolved — fixed or dismissed with a reason — within the timescales provided in the Vulnerability Management Policy (DBT staff access only).

Do not discuss unfixed vulnerability details anywhere public — vulnerability alerts are visible only to users with write access, but comments on PRs and issues in public repositories are visible to everyone.

Some GitHub security controls can be bypassed by repository or organisation administrators. This should only happen in exceptional circumstances and not as a substitute for fixing security issues.

When a control is bypassed:

• The justification must be documented as a comment on the PR
• Any resulting security risk must be understood and accepted
• Follow-up remediation work should be tracked and completed

DBT uses several processes to strengthen the security posture of our GitHub repositories. The diagram below shows where some of these controls apply as code moves from your workspace to GitHub, following the secure development lifecycle principle of “shifting left” — catching issues at the earliest possible point.

The security checklist turns those controls into concrete steps to confirm for your own repository. Copy SECURITY_CHECKLIST.md into your repository root and work through it from top to bottom, ticking each item once you have confirmed it. Its items follow the same order as the detailed guidance below, and each says who can action it. The result is a visible record of your repository's security posture for your team, reviewers and auditors. The Security Checklist must be refreshed at least once a year, using up-to-date documentation and noting the date last checked.

Actions each contributor takes for themselves.

All internal contributors must have completed the following free courses in the last year. Download the certificates where applicable. Choose the language that you are most familiar with.

For those who want to go further, the PortSwigger Web Security Academy offers free, in-depth hands-on labs across the full range of web vulnerabilities.

Internal contributors should review the GitHub Safety Tips (DBT staff access only) to understand how to protect themselves when coding in the open.

Defences set up within the repository itself.

Repositories must include a .pre-commit-config.yaml that runs the organisation-approved pre-commit hooks, and each contributor must install them locally. The hooks use Trufflehog to detect secrets and Presidio to detect sensitive data. They run on your machine before a commit is even created — the earliest and cheapest point to stop a leak, since anything that reaches GitHub must be treated as compromised.

As a backstop, a GitHub Actions workflow (applied via the repository's custom properties) re-runs the same scans and blocks any PR where the pre-commit hooks were skipped locally.

For more information and setup guidance, see the uktrade/github-standards repository.

Review repository access and ensure all users have the appropriate level of permission. Access must be granted through GitHub teams and not directly to individual users.

Review people with Admin permissions to ensure access is justified, as this role can modify repository settings, manage access, and bypass certain repository controls.

If a user no longer requires access, they must be removed from the relevant team by contacting the SRE team or raising a PR against the uktrade/terraform-github repository.

Repositories must include a CODEOWNERS file. GitHub automatically requests a review from the listed owners when a PR touches their code, ensuring changes are seen by people who understand their security implications.

A pull request template pre-fills the PR description with a standard checklist. PR review is the last human check before code is published, so the DBT template prompts reviewers to look for secrets explicitly rather than relying on automated scanning alone.

If your repository does not already contain a pull_request_template.md file, you will inherit the DBT template as a community health file. If you are already using your own template, copy its Reviewer Checklist section across so reviewers are still reminded to check for exposed secrets:

## Reviewer Checklist

- [ ] I have reviewed the PR and ensured no secret values are present

DBT uses custom GitHub properties to enforce branch protection rules and run organisation-level GitHub Actions workflows. They describe what kind of repository this is, so the organisation's automation can apply the checks relevant to it — if they are missing or wrong, your repository may not get the right protections.

View or set custom properties under Settings → Custom properties: https://github.com/uktrade/REPO_NAME/settings/custom-properties

Mandatory

• reusable_workflow_opt_in — set to true
• scs_portfolio — the portfolio associated with your Senior Civil Servant (SCS). If your portfolio is missing, this can be added by raising a ticket with the SRE team

Optional

• is_docker — for repositories that build Docker images
• language — select all languages used by the repository, so the organisation-level workflows run language-specific checks

The DBT GitHub security configuration does not currently support scanning PRs raised from a fork of a repository. Fork PRs typically come from contributors outside the organisation, so leaving them unscanned would create a gap in coverage.

If PRs from forks must be supported, switch to Advanced CodeQL — follow the step-by-step instructions.

An organisation administrator applies these centrally, and they cannot be weakened at repository level. Verify they are active rather than configuring them yourself.

DBT has introduced an organisation-wide GitHub security configuration that applies the required security checks to every repository. New repositories get this configuration by default, but existing ones must have it enabled before they can be made public. Over time, it will fully replace the old configuration across the uktrade organisation.

An organisation administrator must apply it — follow the step-by-step instructions.

Branch protection stops unreviewed code reaching the default branch — the version of the code that gets deployed and that others build on. An organisation ruleset has been created to apply a minimum set of branch protection rules:

• A PR is required for merges into the default branch (usually main)
• At least 1 approver is required before a PR can be merged
• Any conversations on the PR must be marked as resolved

Confirm the default branch protection policy ruleset is applied under Settings → Rules → Rulesets.

Repository administrators may add additional rules to their own repositories, but cannot weaken the organisation ruleset: where rules overlap, the most restrictive rule applies. For example, a repository ruleset that drops the required number of approvers to 0 would have no effect, while one that raises it to 3 would apply.

The DBT GitHub security configuration enables two complementary features. Push protection blocks pushes containing high-confidence secret formats, stopping them before they reach the repository's history. Secret scanning covers a broader range, detecting secrets already committed and raising alerts in the Security tab. Both can apply custom patterns for DBT-specific secrets.

Confirm both features are enabled for your repository under Settings → Advanced Security → Secret Protection. If you need additional custom patterns, raise a ticket with the SRE team.

The DBT GitHub security configuration and rulesets also enables the features described under Handling Vulnerabilities — CodeQL, Dependabot, Dependabot security updates and dependency review. Confirm these are active on your repository.

The DBT GitHub Security Policy is defined as a community health file, so every uktrade repository without its own SECURITY.md inherits it automatically. Do not add a SECURITY.md to your own repository — to suggest changes, raise a PR against the .github repository instead.