Software Security Code of Practice - Assurance Principles and Claims (APCs)
Helps vendors measure how well they meet the Software Security Code of Practice, and suggests remedial actions should they fall short.
About this document
This document allows technical staff to self-assess their own software practices against the Software Security Code of Practice, a set of outcomes that – if met – means the vendor can claim that their software has achieved a baseline of software security and resilience.
This document considers each principle within the four themes in the Code, and breaks them down into a set of individual claims that describe a way to fully meet the associated principle. If all these claims are well-evidenced, then a vendor can claim in good faith that they are meeting the principle.
Note that:
- The type of evidence can vary but examples include document inspection, interviewing individuals, or auditing test plans and results.
- Vendors requiring independent audit of compliance with the code should contact any NCSC-approved cyber resilience test facility.
- Where users recognise that they are unable to evidence a claim fully then it should be clear what steps to take to correct this. For example, certain processes or information may need to be more fully documented, or additional testing may need to be put in place.
- If it is unclear whether a form of evidence is suitable, vendors can refer to the claims trees in the appendix. The claim trees use a claims argument evidence method, similar to that used in the NCSC Principles Based Assurance (PBA) method.
Theme 1: Secure design and development
This theme ensures that software is secure when first provided to customers, along with subsequent updates. The use of appropriate design and development practices reduces the likelihood of errors and the presence of vulnerabilities in software and updates.
| Principle 1.1 | Claims |
|---|---|
| Follow an established secure development framework. |
|
| Principle 1.2 | Claims |
| Understand the composition of the software and assess risks linked to the ingestion and maintenance of third-party components throughout the development lifecycle. |
|
| Principle 1.3 | Claims |
| Have a clear process for testing software and software updates before distribution. |
|
| Principle 1.4 | Claims |
| Follow secure by design and secure by default principles throughout the development lifecycle of the software. |
|
Theme 2: Build environment security
This theme ensures appropriate steps are taken to prevent the build environment from being accessed by a person (or machine) without a legitimate need. This helps prevent interference with the software during the build and release process. The ‘build environment’ refers to the environment where software is compiled, built and packaged ready for release. This should be logically or physically separate from areas where code is written and tested.
| Principle 2.1 | Claims |
|---|---|
| Protect the build environment against unauthorised access. |
|
| Principle 2.2 | Claims |
| Control and log changes to the build environment. |
|
Theme 3: Secure deployment and maintenance
This theme ensures that the software remains secure throughout its lifetime. The use of appropriate mechanisms and processes for managing and deploying updates to software reduces the likelihood of errors and vulnerabilities persisting in software.
| Principle 3.1 | Claims |
|---|---|
| Distribute software securely to customers. |
|
| Principle 3.2 | Claims |
| Implement and publish an effective vulnerability disclosure process. |
|
| Principle 3.3 | Claims |
| Have processes and documentation in place for proactively detecting, prioritising and managing vulnerabilities in software components. |
|
| Principle 3.4 | Claims |
| Report vulnerabilities to relevant parties where appropriate. |
|
| Principle 3.5 | Claims |
| Provide timely security updates, patches and notifications to customers. |
|
Themes 4: Communication with customers
This theme ensures that vendors provide sufficient information to customers to enable them to effectively manage risks and incidents throughout the software’s lifetime.
| Principle 4.1 | Claims |
|---|---|
| Provide information to the customer specifying the level of support and maintenance provided for the software being sold. |
|
| Principle 4.2 | Claims |
| Provides at least 1 year’s notice to customers of when the software will no longer be supported or maintained by the vendor. |
|
| Principle 4.3 | Claims |
| Make information available to customers about notable incidents that may cause significant impact to customer organisations. |
|
Appendix: Claims trees
The following claims trees display the reasoning behind the claims in the body of this document. The themes are presented as stated in the code whilst the principles are expressed as ‘top-level claims’ that enable the use of the claims argument evidence method to further deconstruct top-level claims to ‘low-level claims’ that can be simply and objectively evidenced.
If a vendor is unclear on the intention of one of the claims in this document, then the claims tree can be useful in gaining an understanding of the provenance and rationale for the claim in relation to the principles.
Similarly, if a user cannot fully evidence a claim, then the claims tree can help in understanding the implications of this (for example as risk against the underlying principle), and the changes or improvements that can be made to help develop evidence in the future.
Theme 1: Secure design and deployment
Theme 2: Build environment security
Theme 3: Secure deployment and maintenance
Theme 4: Communication with customers
