Skip to content

Commit 8b08a89

Browse files
committed
Remove git-secrets references and add GitLeaks guidance
1 parent 0916f36 commit 8b08a89

21 files changed

Lines changed: 84 additions & 881 deletions

blueprints.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,4 +11,4 @@ Where possible this will be a set of fully working components / solutions you ca
1111
| [Purging commits on GitHub](practices/guides/commit-purge.md) | Instructions | Mandatory | Published |
1212
| [Signing commits on GitHub](practices/guides/commit-signing.md) | Instructions | Recommended | Published |
1313
| [Automating performance-test decisions using APDEX](practices/performance-testing.md) | Instructions | Recommended | Published |
14-
| [Scanning source code for secrets](tools/nhsd-git-secrets/README.md) | Full solution | Recommended | Published |
14+
| [Scanning source code for secrets](tools/gitleaks.md) | Instructions | Recommended | Published |

practices/guides/commit-purge.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ Engineering teams must take all necessary precautions to ensure that sensitive d
88

99
Teams must also review their Near Miss reporting requirements and ensure that necessary steps are taken.
1010

11-
Teams must ensure that a [Secret scanner](https://github.com/NHSDigital/software-engineering-quality-framework/tree/main/tools/nhsd-git-secrets) is enabled on their repositories.
11+
Teams must ensure that a secret scanner such as [GitLeaks](../../tools/gitleaks.md) is enabled on their repositories.
1212

1313
Teams must also ensure that developers follow standard processes to ensure any pre-commit hooks are enabled and enforced to reduce the risk of sensitive information being accidentally published. Teams should also contribute to the rule set for these tools to ensure secrets are identified correctly.
1414

practices/security.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ The remainder of this page gives more detailed and specific recommendations to b
7979
- Prevent **[clickjacking](https://sudo.pagerduty.com/for_engineers/#clickjacking)** with `X-Frame-Options`
8080
- Be careful not to **leak information**, e.g. error messages, stack traces, headers
8181
- **Don't trust** yourself or others! <a name='secret-scanning'></a>
82-
- Code must be automatically scanned for secrets or other sensitive data. We have a [secret scanning guide](../tools/nhsd-git-secrets/README.md) that describes how to best achieve this using our preferred tooling, and also includes examples to get you started.
82+
- Code must be automatically scanned for secrets or other sensitive data. Use our [GitLeaks guidance](../tools/gitleaks.md) to implement local and pipeline scanning with the organisation's preferred tooling.
8383
- Be wary of any 3rd party JavaScript included on the page, e.g. for A/B testing, analytics
8484
- Pin dependencies at known versions to avoid unexpected updates
8585
- Scan dependencies for vulnerabilities, e.g. using [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) or [Snyk](https://snyk.io/)

quality-checks.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -54,7 +54,7 @@ We recommend tracking progress on an Engineering Quality dashboard, for example:
5454
| <a name="duplicate-code-scan"></a> Duplicate code scan | Maintainability | Universal | Check whether the same code is used in multiple places | Duplicate code increases the cost and risk of making software changes and will increase exponentially over time | Must use SonarQube's default [rules, profiles and gateways](tools/sonarqube.md#default-quality-gates) <br/><br/> Build pipeline must fail if gateway is not met | [SonarQube](tools/sonarqube.md) | |
5555
| <a name="integration-test"></a> Integration test | Functionality | Universal | Check interactions with other components and dependant systems. e.g. across microservices, authentication layers, database, third-party systems. Ideally includes full end-to-end testing across all components | When components are developed in isolation, it's vital that we regularly test them working together. Changes in one component can break the whole system | Builds fail if any tests fail | | |
5656
| <a name="performance-test"></a> Performance test | Resilience | Contextual | Check whether application performance is acceptable at different levels of load. This may include: <br/>*Baseline test (one-off) - to establish how the system interacts*<br/>*Smoke test - to establish that the key functionality is working before performing longer tests*<br/>*Regression test - run a suite of repeatable test cases to validate existing functionality*<br/> Load test - to understand the system behaviour under an expected load | Without these tests, we don't know how load will affect the performance of the application, or whether existing functionality has been broken. | The performance of the system must be scored at build time so that it can be tracked<br/><br/>Build pipeline must fail if performance does not meet the acceptable level | One option is to use [APDEX](https://en.wikipedia.org/wiki/Apdex) to quantify performance to a numeric value, and to use this value to pass/fail the build pipeline | [Performance test practices](./practices/performance-testing.md) |
57-
| <a name="secret-scan"></a> Secret scan | Security | Universal | Check for secrets (e.g. passwords, IP addresses, etc) accidentally included in software code | This protects us against accidentally leaking secrets (in source code) which could compromise the security of the application | Review the list of patterns and update it as necessary<br/><br/>... then:<br/><br/>Full repository (including history) scan, and all secrets removed<br/><br/>And:<br/><br/>Local (on developer laptop) scanning to block commits containing the patterns <br/><br/>And:<br/><br/>Server-side scanning within the code repository for new commits containing the patterns | [nhsd-git-secrets](tools/nhsd-git-secrets/) | |
57+
| <a name="secret-scan"></a> Secret scan | Security | Universal | Check for secrets (e.g. passwords, API keys, certificates or tokens) accidentally included in software code | This protects us against accidentally leaking secrets in source code, commit history, logs and configuration, which could compromise the security of the application | Review the detection rules and exclusions regularly<br/><br/>... then:<br/><br/>Full repository (including history) scan, and all secrets removed<br/><br/>And:<br/><br/>Local scanning to block commits containing the patterns<br/><br/>And:<br/><br/>Server-side scanning within the code repository for new commits containing the patterns | [GitLeaks guidance](tools/gitleaks.md) | |
5858
| <a name="security-scan"></a> Security scan | Security | Universal | Check for indications of possible security issues (for example injection weaknesses) | This gives fast feedback about security issues. <br/><br/> Code analysis is not as thorough as security testing in terms of finding complex weaknesses or issues that only manifest themselves at runtime, but it has much greater coverage. It's a better option for finding simple weaknesses and it's much quicker to execute. <br/><br/> Security code analysis and security testing are both important to achieve rapid and thorough security testing. | If using SonarQube, must use SonarQube's default [rules, profiles and gateways](tools/sonarqube.md#default-quality-gates) <br/><br/> Build pipeline must fail if gateway is not met | One option is [SonarQube](tools/sonarqube.md). For the purpose of security code analysis, Developer Edition or higher is required as it includes advanced OWASP scanning. | |
5959
| <a name="security-test"></a> Security test | Security | Contextual | Check for security issues (for example injection weaknesses) | More thorough than security code scanning, but much slower to execute, so both are important to achieve both rapid and thorough security testing | | | |
6060
| <a name="soak-test"></a> Soak test | Resilience | Contextual | Check whether sustained heavy load for a significantly extended period causes a problem such as memory leaks, loss of instances, database failovers etc. | Without this test, we don't know if application performance will suffer under prolonged heavy load, how stable the system is, how it performs without interventions. | | | |

0 commit comments

Comments
 (0)