Software Security Code of Practice - Implementation Guidance
Page 5 of 7
Theme 3: Secure deployment and maintenance
A secure deployment and maintenance strategy will reduce the likelihood of vulnerabilities being introduced into software, both during initial distribution and then through the supply of subsequent patches and updates through its supported lifetime.
You may choose to roll out the software to a select group initially to minimise any remedial action should a post-release issue be found. For instance you might first trial an internal rollout with a small group. Other approaches include A/B testing, where data-driven decisions can be made based on user feedback. This can work equally well for security aspects and features of the software.
No software will remain bug-free throughout its lifetime. Having internal and external processes in place to identify, triage and manage vulnerabilities is a central part of ensuring software remains resilient throughout its lifetime.
Principle 3.1 Distribute software securely to customers
Software deployment involves various stages such as installation, configuration, testing and updating. It typically involves transferring the software from a central location (such as a network share or an online repository) to the target infrastructure, and configuring it to run properly on that system. Deployment can be a complex process. It can be manual or automatic, continuous or discrete depending on the context.
Tampering with or spoofing software (and its updates) can occur at various stages of the distribution process. Not protecting against this can lead to data breaches, ingestion of malware and potential system outages.
As well as technical protective measures, effective communication with the customer is a crucial aspect of this claim. Transparency and clarity will ensure customers are well informed about how to install your software into their infrastructure, and when an update or a patch is issued.
You should ensure that:
- A trusted location or tool is available (such as a support website with appropriate protective measures) for customers to download the software from. Code integrity/provenance must be verified to provide confidence in its integrity before installation.
- Automatic deployments of code are transmitted across a connection protected by standards such as TLS.
- For both regular and emergency deployments, clear documentation is provided to customers about version control and security fixes.
- Access control is in place for deployment and production environments.
- Software is tested thoroughly before deployment, with change claims in place to be able to roll back to the specific version if required.
- Code is digitally signed throughout the deployment pipeline. Code can only be pulled from an approved list of third parties.
Deploying software progressively, to a subset of users first, can also help to manage the risk and reduce the impact of potential compromises. To do this effectively, configuration management techniques should be used to manage change and version control, which allow a rollback to a specific state if necessary.
Further reading
Principle 3.2 Implement and publish an effective vulnerability disclosure process
All systems contain vulnerabilities. Continuous processes that enable vulnerabilities to be identified as early as possible so that they can be triaged and acted upon in a timely way are critical for providing strong cyber resilience of software.
Internal practices should be in place to identify vulnerabilities, but this can be enhanced dramatically by putting in place a vulnerability disclosure policy which is communicated effectively to others. The vulnerability disclosure policy should include an openness to accept information from security researchers who may test software as part of a vulnerability disclosure process.
Security vulnerabilities are discovered all the time and researchers want to be able to report them directly to the organisation responsible. These reports often contain a large amount of information, so it’s important to capture the security vulnerabilities that could cause the greatest harm. Effectively responding to reports promotes a culture of transparency in your organisation, and will assist with improving the cyber resilience of your software.
The NCSC’s Vulnerability Disclosure Toolkit contains the essential components you need to set up your own vulnerability disclosure process and includes additional information on implementing the process, including validation and triage.
Further reading
Principle 3.3 Have processes and documentation in place for proactively detecting, prioritising and managing vulnerabilities in software components
All software will contain vulnerabilities at some point through its lifetime. How effectively vulnerabilities are identified and remediated will determine how likely an attacker is to exploit them. In addition to a vulnerability disclosure policy, internal processes should be in place to detect and respond to vulnerabilities in a way that will support customers to implement their own vulnerability management process.
Discovering new vulnerabilities in software, understanding how they can be exploited, and effective remediation can be achieved through a variety of approaches, including:
- regular vulnerability scanning and testing of your software, including third-party components
- monitoring vulnerability databases, security mailing lists and other sources of vulnerability reports through manual or automated means
- using threat intelligence sources to better understand how vulnerabilities in general are being exploited
You should ensure that:
- you maintain a knowledge of public and third-party vulnerabilities
- a vulnerability management plan exists, which describes how vulnerabilities can be proactively detected
- you follow a documented process for the timely assessment of the severity of vulnerabilities and prioritise responses to vulnerabilities based on risk assessment
- you have a ‘security response playbook’ in place with roles assigned to handle the response, and test this periodically
- discovered vulnerabilities are reported to the CVE Website (which identifies, defines and catalogues publicly disclosed vulnerabilities so that they can be consistently described, aiding collaboration and communication)
- root cause analysis is carried out to prevent recurring vulnerabilities
Further reading
Principle 3.4 Report vulnerabilities to relevant parties where appropriate
Software companies must manage the flow of information around a reported vulnerability by ensuring it gets sent to the appropriate team or organisation, such that a coordinated and effective response can be delivered. By reporting vulnerabilities to these entities in a timely way, software companies can help mitigate risks and enhance the overall security of their software.
Several groups should be considered to notify, once a vulnerability has been reported or when a fix is available:
- internal security teams: usually will be the first people to contact, so that they can assess the implications of the vulnerability and work out how best to address the concerns raised
- customers and users: noting the communication with customers guidance below, the customers of the software should be informed promptly to take necessary precautions
- vulnerabilities systems: reporting to databases such as the National Vulnerability Database (NVD) or Common Vulnerabilities and Exposures (CVE) helps in tracking and managing vulnerabilities globally
- regulatory bodies: might need to be informed to comply with legal requirements
- third-party vendors: if the vulnerability affects third-party software or services, it should be reported to the respective vendors to ensure they can address the issue
- open source software: follow any vulnerability management process for the software
Principle 3.5 Provide timely security updates, patches and notifications to customers
Inevitably, vulnerabilities in software will be discovered in its lifetime. When new vulnerabilities are discovered, particularly high impact ones, a timely and well tested patch should be issued by the vendor and installed by the customer to reduce the risk that it could be exploited to cause harm in a system.
It can also be the case that a discovered vulnerability draws attention to the vicinity in which it was found, leading to related vulnerabilities being discovered. Therefore, be prepared to respond to those secondary vulnerabilities in a robust, effective and timely way.
Enabling customers to manage vulnerabilities effectively to ensure their systems remain resilient to cyber attacks is hugely dependent on security updates and patches being available in a timely manner. Updates and patches should not be a premium feature of software. Security fixes should be provided as standard for a reasonable support period, which has been clearly communicated to customers.
You should ensure that:
- Once identified, vulnerabilities should be validated and triaged. Prioritisation and classification criteria might include how easy to exploit they are and the potential impact if exploited. The outcome of this triage process will tell you whether to fix, acknowledge or investigate further.
- Vulnerabilities should be fixed within a reasonable timeframe, according to their priority. If they are critical, you will need to issue an ‘out-of-band’ update that sits outside any regular update cadence. You may need to issue a temporary fix or mitigation to begin with, followed by a more stable solution.
- Updates should be signed and thoroughly tested.
- The release of any updates and patches should ideally be communicated to customers in a clear manner, specifying aspects such as that it is a security update (or includes a security update), whether it is a temporary mitigation or a full fix.