Skip to content

Commit b7f05bb

Browse files
andyblundellandyblundell
authored
Secret regex mgmt (#155)
Updating the regex list is part of green for secret scanning
1 parent df3478b commit b7f05bb

File tree

2 files changed

+2
-1
lines changed

2 files changed

+2
-1
lines changed

‎practices/security.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -69,6 +69,7 @@ The remainder of this page gives more detailed and specific recommendations to b
6969
- **Don't trust** yourself or others! <a name='secret-scanning'></a>
7070
- Code must be automatically scanned for secrets or other sensitive data:
7171
- To catch any issues early and to minimise potential exposure, scan code on developer machines *before* code is committed to the code repository. We recommend using [awslabs git-secrets](https://github.com/awslabs/git-secrets). To set this up on a Mac workstation or as part of your Jenkins pipeline, follow the examples and READMEs in [nhsd-git-secrets](../tools/nhsd-git-secrets). Windows testing is in progress and instructions/code will be added in due course
72+
- The above solution uses regular expressions to find potential secrets: before using the solution, consider the types of secrets that might exist (based on your technology stack) and update the list of regular expressions as necessary
7273
- As a backstop, *also* enable server-side scanning within the code repository. Recommended solution options:
7374
- TO DO: more details... for example in [GitHub](https://docs.github.com/en/code-security/secret-security/about-secret-scanning)
7475
- Be wary of any 3rd party JavaScript included on the page, e.g. for A/B testing, analytics

‎quality-checks.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -44,7 +44,7 @@ We recommend tracking progress on an Engineering Quality dashboard, for example:
4444
| Integration tests | 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 | | |
4545
| API / contract tests | Functionality | Contextual | Check whether the API interface adheres to the agreed contract | Any API interface is an integration point with another component or a software systems. An extra care has to be taken to ensure compatibility and stability of that integration are maintained so that we don't break applications that depend on our APIs | Builds fail if any tests fail | Postman | [Automate Your API Tests with Postman](https://www.postman.com/use-cases/api-testing-automation/) |
4646
| UI tests | Functionality | Contextual | Check that the user interface components behave as expected, particularly checking the visual elements to verify that they are functioning according to requirements | As the only aspects of software that end users come into contact with, it is essential that these elements behave as expected and allow users to get only what they need from our software applications | Builds fail if any tests fail | | |
47-
| <a name="secret-scanning"></a> Secret scanning | 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 | 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| <!-- markdown-link-check-disable -->[Security practices](/practices/security.md#secret-scanning)<!-- markdown-link-check-enable --> | |
47+
| <a name="secret-scanning"></a> Secret scanning | 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| <!-- markdown-link-check-disable -->[Security practices](/practices/security.md#secret-scanning)<!-- markdown-link-check-enable --> | |
4848
| Security code analysis | Security | Universal | Check for indications of possible security issues (for example injection weaknesses) | This gives fast feedback about security issues: it's not as thorough as security testing, but it's much quicker to execute, so both are important to achieve both 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) (Developer Edition or higher - includes advanced OWASP scanning) | |
4949
| Security testing | 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 | | | |
5050
| Dependency scanning | Security | Universal | Check for security issues and vulnerabilities in dependent areas of code that are outside of our direct control | Without this we have no way of knowing of any issues or security vulnerabilities of third party components that we are not responsible for | | | |

0 commit comments

Comments
 (0)