Secure Coding Policy
ISO/IEC 27001 Toolkit: Version 13
Implementation guidance
The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.
Purpose of this document
This document sets out the principles that will be used when developing secure code.
Areas of the standard addressed
The following areas of the ISO/IEC 27001 standard are addressed by this document:
• A.5 Organizational controls
o A.5.1 Policies for information security
• A.8 Technological controls
o A.8.28 Secure coding
General guidance
Writing secure code is difficult and can be highly dependent on the techniques and languages used. An approach of continuous improvement over time will probably be most appropriate, based on the kinds of general principles set out in this document and elsewhere. There are some effective tools available for security testing particularly in a cloud environment and the use of these will encourage the creation of more secure code from the outset. Common advice is also to place security firmly on the agenda of all development-related meetings and reviews so that a clear focus is maintained on secure coding.
Review frequency
We would recommend that this document is reviewed annually and upon significant change to the organization.
Document fields
This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.
To update this field (and any others that may exist in this document):
1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.
2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).
3. Press F9 on the keyboard to update all fields.
4. When prompted, choose the option to just update TOC page numbers.
If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.
If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.
Further detail on the above procedure can be found in the toolkit Completion Instructions This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.
Copyright notice
Except for any specifically identified third-party works included, this document has been authored by CertiKit and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.
Licence terms
This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence.
If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third-party copyright included in this document.
Disclaimer
Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.
Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.
You should take all reasonable and proper legal and other professional advice before using this document.
CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.
Secure Coding Policy [Insert classification]
Secure Coding Policy
DOCUMENT CLASSIFICATION [Insert classification]
DOCUMENT REF ISMS-DOC-A08-28-1
VERSION 1
DATED [Insert date]
DOCUMENT AUTHOR [Insert name]
DOCUMENT OWNER [Insert name/role]
Revision history
Distribution
Approval
NAME
1 Introduction
Developing bespoke software provides a level of flexibility and functionality that is not always possible to reproduce using commercial off the shelf systems. [Organization Name] dedicates a significant amount of its resources to designing, coding, testing, releasing and maintaining its software according to industry best practice standards. As part of this, we have a responsibility to ensure that the computer code we produce is as secure as it reasonably can be. Insecure software allows vulnerabilities to be found which can provide a way in for malicious actors and requires our time to create and distribute patches. The increasing use of artificial intelligence (AI) systems further complicates the task.
In order to write software that minimises such vulnerabilities, there are a number of guiding principles that must be followed, in addition to the more detailed programming techniques that apply with specific languages. This policy defines these high-level principles as a starting point for the definition of lower-level procedures for the creation of secure code, as part of an effective, managed approach.
This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems.
The intended audience for this policy is employees responsible for designing, managing and writing code for bespoke software developments within [Organization Name]
Failure to comply with the contents of this policy may result in disciplinary action being taken by [Organization Name] against the individual(s) concerned.
Terms used in this policy are defined as follows:
• Artificial intelligence refers to the simulation of human intelligence in machines programmed to think, learn, and perform tasks autonomously.
• Integrated development environments are software applications that provide comprehensive tools for developers to write, test, and debug code.
• Vulnerability is a weakness in a system, network, or application that can be exploited by threats to gain unauthorized access or cause damage.
The following ISMS documents and external references are relevant to this document:
• Secure Development Environment Guidelines
• Secure Development Policy
• Principles for Engineering Secure Systems
• AI Security Policy
2 Secure coding policy
It is the policy of [Organization Name] to write software in such a way that the number of potential vulnerabilities in the code is minimised.
Secure coding within [Organization Name] will be based on the principles established by best practice organizations including (but not limited to) the following:
• OWASP (The Open Web Application Security Project®)
• SEI CERT (Software Engineering Institute Computer Emergency Response Team)
• UK NCSC (National Cyber Security Centre)
• USA NIST (National Institute of Standards and Technology)
• [Add further sources of best practice as applicable]
Secure coding practices in use within the organization will cover as a minimum the following topics (based on OWASP Secure Coding Practices V2.0):
• Input validation
• Output encoding
• Authentication and password management
• Session management
• Access control
• Cryptographic practices
• Error handling and logging
• Data protection
• Communication security
• System configuration
• Database security
• File management
• Memory management
• General coding practices
These general principles will be supplemented by technology-specific advice and guidance produced by the vendors of the technology in use, and third parties with particular expertise in them. For AI-based systems, best practice guidelines for tasks such as data validation and model training will be followed, based on emerging guidance from NIST and other bodies.
Secure coding practices will be established and documented for each development project, and will be communicated to third parties that create software on [Organization Name]’s behalf. Account will be taken of available threat intelligence and existing known vulnerabilities when defining these practices.
Good practice in writing code will be followed at all times including, where appropriate:
• The use of structured programming techniques
• Clear documentation and commenting of code
• Consistent naming of items such as classes, methods and variables
• Avoiding hard coding of credentials
• Correct handling of errors
Appropriate software testing will be carried out to confirm that the documented coding techniques have been properly implemented prior to the release of the software to production.
Where possible, the use of secure coding techniques will be mandated via settings and automation within development tools, such as integrated development environments (IDE).
External software libraries used as part of the development process must be examined to assess them against the secure coding practices adopted for the relevant project.
A process must be in place for the management of vulnerabilities discovered after the release of the software into production.
Software fixes and updates must be subject to the same secure coding practices as the original development.