Secure Coding

Applies to. Requirement 6 applies secure coding to bespoke and custom software: code the entity writes or has written for it. 6.2.2 requires developers of that software to be trained at least once every 12 months in secure design and secure coding techniques for the languages they use. 6.2.3 requires the code to be reviewed before release to check it follows secure coding guidelines and to catch existing and emerging vulnerabilities, and 6.2.3.1 adds that manual reviewers must be someone other than the author and must know secure coding practices.

Example. A subscription service builds its own checkout on a web framework. Its developers attend an annual course on the injection and authentication flaws relevant to that framework, every change to payment code is reviewed by a second developer who has done the same course, and the release ticket records the reviewer's and a manager's sign-off. That chain of training, review and approval is what an assessor examines under 6.2.2, 6.2.3 and 6.2.3.1.

Limits. Secure coding is not a certification or a single checklist; 6.2.1 points to industry standards and best practices and leaves the entity to choose which. It applies to code the entity controls, not to off-the-shelf products or third-party components, which are handled through inventory and patching rather than code review. Nor is it the same as security testing: 6.2.4 lists the attack classes the code must resist, and a review that reads the code is a different activity from a scan or penetration test that probes the running system. Following secure coding practices does not remove the need for the review itself.