Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion blueprints.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,4 +11,4 @@ Where possible this will be a set of fully working components / solutions you ca
| [Purging commits on GitHub](practices/guides/commit-purge.md) | Instructions | Mandatory | Published |
| [Signing commits on GitHub](practices/guides/commit-signing.md) | Instructions | Recommended | Published |
| [Automating performance-test decisions using APDEX](practices/performance-testing.md) | Instructions | Recommended | Published |
| [Scanning source code for secrets](tools/nhsd-git-secrets/README.md) | Full solution | Recommended | Published |
| [Scanning source code for secrets](tools/gitleaks.md) | Instructions | Recommended | Published |
2 changes: 1 addition & 1 deletion practices/guides/commit-purge.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Engineering teams must take all necessary precautions to ensure that sensitive d

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

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.
Teams must ensure that a secret scanner such as [GitLeaks](../../tools/gitleaks.md) is enabled on their repositories.

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.

Expand Down
2 changes: 1 addition & 1 deletion practices/security.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ The remainder of this page gives more detailed and specific recommendations to b
- Prevent **[clickjacking](https://sudo.pagerduty.com/for_engineers/#clickjacking)** with `X-Frame-Options`
- Be careful not to **leak information**, e.g. error messages, stack traces, headers
- **Don't trust** yourself or others! <a name='secret-scanning'></a>
- 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.
- 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.
- Be wary of any 3rd party JavaScript included on the page, e.g. for A/B testing, analytics
- Pin dependencies at known versions to avoid unexpected updates
- Scan dependencies for vulnerabilities, e.g. using [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/) or [Snyk](https://snyk.io/)
Expand Down
2 changes: 1 addition & 1 deletion quality-checks.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ We recommend tracking progress on an Engineering Quality dashboard, for example:
| <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) | |
| <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 | | |
| <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) |
| <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/) | |
| <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) | |
| <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. | |
| <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 | | | |
| <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. | | | |
Expand Down
Loading
Loading