diff --git a/software-engineering-policies/CloudDevelopment/Deployment.md b/software-engineering-policies/CloudDevelopment/Deployment.md index 222b403b..17233b75 100644 --- a/software-engineering-policies/CloudDevelopment/Deployment.md +++ b/software-engineering-policies/CloudDevelopment/Deployment.md @@ -2,16 +2,26 @@ [Back to main Readme](README.md) +## Preferred Security Tooling + +Before releasing applications and infrastructure into our cloud environments, it is important that we scan our assets for any potential vulnerabilities and remediate issues that exceed our risk appetite. Our current preffered security tooling for the various scanning outlets is [Snyk.io](https://app.eu.snyk.io/login) which is connected to our Github repos for Static Analysis testing and Software Composistion testing as a PR is raised. However it is greatly encouraged that the below scanning is added to your pipelines using the [provided task](https://github.com/UKHO/ukho-azure-pipeline-scan-task) so that any vulnerabilities exceeding your risk appetite do not reach your cloud environment. + +Its important to understand that the tooling doesnt have the necessary context around your implementation so can sometimes provide false positives, this may mean you will have a need to be excused from a issue. In these cases you can reach out to our [Cyber Security team](mailto:ukho-itso@ukho.gov.uk), your lead developer or one of the security champions for advice on mitigation/suppression of the issue. + ## Code Scanning -Before any code is pushed into an environment it should undergo our SAST checks from [Snyk](https://app.snyk.io/login) to try and ensure that the code we are creating is not going to leave us vulnerable. Any issues found that are high or above should be dealt with before doing any deployments to an environment. Where you feel there may be an exception to this, you can reach out to our [ITSO team](mailto:ukho-itso@ukho.gov.uk) or your Lead Developers for advice on mitigation/suppression of these issues. +As mentioned above, Static Application Security Testing (SAST) takes place when a PR is raised within your repository and on a regular basis to analyse your code to prevent potential vulnerabilities being released. It is strongly encouraged that your pipeline includes a SAST check to protect from potential vulnerable code being released into your environment that exceeds your risk appetite. ## Container Scanning -Container images being produced for deployment into an environment should be scanned by a preferred scanning solution to ensure that we are not deploying vulnerable software. Details on our container policies can be found in the [Containers area.](/software-engineering-policies/Containers/) +Once a container has been built within your pipeline, but prior to being pushed into a container registry it is advised to perform a Container Scan to check for vulnerabilities. Further information around our container policies can be found within the [Containers area.](/software-engineering-policies/Containers/) ## Dependency Checking for Cloud Applications -It is important that we do not allow our dependencies to be the weak link in our security chain. Pipelines should use the preferred Software Composition Analysis (SCA) scanning tool that prevents any dependencies with high or above vulnerabilities to be released. Where you feel there may be an exception to this, you can reach out to our [ITSO team](mailto:ukho-itso@ukho.gov.uk) or your Lead Developers for advice on mitigation/suppression of these issues. +3rd party dependecies are a threat vector in which we have little control and is why it is important we do not allow this to be the weak link in our security chain. Performing Software Composition Analysis testing allows us to identify any packages which may have vulnerabilities that exceed our risk appetite. From here a concious decision can be made about the right steps forward. + +## Infrastructure as Code + +Just as the code we are deploying, we need to scan the Infrastructure code to ensure that we are not deploying vulnerable cloud assets to our enviroment. Where possible use already produced Terraform Modules that have been security scanned to provide you with the safest implementation. [Back to main Readme](README.md) diff --git a/software-engineering-policies/CloudDevelopment/General.md b/software-engineering-policies/CloudDevelopment/General.md index c6756c46..9331e17e 100644 --- a/software-engineering-policies/CloudDevelopment/General.md +++ b/software-engineering-policies/CloudDevelopment/General.md @@ -29,10 +29,9 @@ The DDC team are responsible for the creating and maintaining the networking spo The DDC team manages a collection of centralised Terraform modules found here: https://github.com/orgs/UKHO/teams/tfmodules/repositories These should be used whenever possible. -### IaC Scanning (Trivy) +### IaC Scanning -Trivy is UKHO's Chosen IaC Scanning tool. All Infrastructure pipelines should include a Trivy Scan stage before deployment that fails the build if misconfigurations or vulnerabilities are detected. -A Trivy Stage is included in the previously mentioned Terraform deployment template: https://github.com/UKHO/Terraform-Deployment-Template/blob/5ca2e1c18618dad0df84ef8c08aea87a64c3b94e/azure-pipelines.yml#L37 +[Snyk.io](https://app.eu.snyk.io/login) is the UKHO's chosen security tool which provides IaC scanning. Any repository with Infrastructure should include a IaC scan task which can be added using the [provided task](https://github.com/UKHO/ukho-azure-pipeline-scan-task). Pipelines should fail at a level that matches the projects risk appetite. ## Secrets Management