No data and information processing can be operated without software. Software development focuses primarily on the task-specific functioning of algorithms. However, the fact that poor writing of program code often also gives rise to security problems, such as faulty access control, SQL injection, incorrect session management and authentication, cross-site scripting, etc., is now well known.

The high importance of secure coding practices is highlighted in the updated information security standards ISO/IEC 27002 and ISO/IEC 27001:2022. As a new information security measure ( control), the principles for "Secure Coding" in software development are entering the catalog of measures in Annex A of ISO/IEC 27001. Read about the significance of this measure for your information security and what this means for future audits in our blog post.

Security vulnerabilities in code

Operating system software, application software or firmware in an embedded system are elementary components of any digital infrastructure. However, increasing acceleration and deadline pressure in digitization projects often lead to a neglect of imperative information security aspects. The development requirements for software are usually function-centric and emphasize constructive aspects, so that the destructive view of potential security vulnerabilities is mostly diametrically opposed to the actual development goals: many programmers simply also lack a structured and sharpened view of cybersecurity.

Under these conditions, development teams have a hard time continuously reviewing and consistently securing the coding of their software, as evidenced by the many vulnerabilities that the non-profit MITRE Corporation publishes each year in its CVE (Common Vulnerabilities and Exposures) list. The regular security patches of even well-known software manufacturers are an indicator of the Sisyphean task of closing security-relevant bugs, let alone identifying them before they are even launched on the market.

Open source code - a special case

When coding self-developed software, programmers like to resort to open source libraries and modules. The practical advantages are obvious: If you don't have to reinvent the wheel over and over again, you benefit from this technology boost, speedy development, lower development costs, more transparency through open source code, and higher interoperability through open standards and interfaces.

It is also often said that code from open source offers a high degree of security because the code has been validated by many users and the swarm intelligence of the open source community enables fast and efficient bug fixing.

In practice, this trust must now be evaluated in a differentiated and critical manner. The most serious example is the zero-day security vulnerability Log4Shell in the widely used logging library Log4J for Java applications, which was discovered in November 2021. You may have heard about the red alert level issued by the German Federal Office for Information Security (BSI) for Log4Shell. The Log4J library, distributed as a reliably functioning quasi-standard via the Apache Foundation, has established itself in many systems since 2013 - including well-known web services such as Amazon AWS.

The complexity of these well-developed and also maintained libraries implicitly provides powerful functionalities of which an importing developer is often unaware in his own combined new development, but which can be exploited by attackers.

Another insecurity factor of open source components are so-called supply chain attacks, i.e., intended built-in vulnerabilities by malicious actors who pose as part of the open source community and assist in code development. Such a vulnerability is an extremely efficient way for hackers to attack a large number of downstream user organizations. No wonder, then, that this attack vector is growing rapidly: a Sonatype study diagnosed a 650% increase when comparing 2020 and 2021.

whitepaper-ISO 27001-faq-dqs-cover picture

ISO/IEC 27001:2022 FAQ

"The New One" for Information Security: 38 Questions and Answers

What you need to know about the "new kid on the block" for information security: 38 answers from our experts to 38 user questions

What are the new controls all about?

  •  When should we transition to the new standard?
  • Where can I find a list of correspondences old vs. new?
  •    ... as well as 35 more! 

Information security control 8.28 secure coding

In order to safeguard the software development process in a timely manner, the International Organization for Standardization (ISO - committee ISO/IEC JTC 1/SC 27) has included "Secure Coding" as a new control 8.28 in the new ISO/IEC 27002 and ISO/IEC 27001:2022, Annex A standards. The purpose of the technical measure for secure coding is the preventive protection of software.

A minimum level of security is created as early as the writing stage on the basis of procedural regulations, thus minimizing the number of potential security vulnerabilities in the software. The regulatory framework for secure code generation is to be applied holistically both to the company's own program code and to software from third parties and open source sources. Notable principles for implementation are Security by Design and Least Privilege, which must also be considered in coding.

Principles of secure coding

Measure 8.28 addresses so-called principles of secure coding several times. Guidance on what these might be is provided by numerous organizations and institutes that regularly issue guides and best practices for secure coding. These include, for example, the Secure Coding Practices of the OWASP Foundation, the Secure Coding Standards of the Computer Emergency Response Team (CERT) of the Software Engineering Institute (SEI), and the German BSI's catalog of measures for the security of web applications. Despite the different sources, the elaborations show many parallels, for example with regard to the following points:

  • Validation of data input
  • Securing authentication and password management
  • Secure access control
  • Simple, transparent code
  • Sustainably tested cryptographic measures and components
  • Error handling and logging
  • Data protection
  • Threat modeling

In the ISO/ISO 27002:2022 standard, the recommended actions for Control 8.28 are divided into three sections, "Planning and precoding," "During coding," and "Verification and maintenance," the core contents of which are outlined below.


Watch it now: What is changing with the new ISO/IEC 27001:2022

The new version of ISO/IEC 27001, adapted to contemporary information risks, was published on October 25, 2022. What does this mean for users of the standard? In our free webinar recording, you will learn about 

  • New features of ISO/IEC 27001:2022 - Framework and Annex A 
  • ISO/IEC 27002:2022-02 - structure, content, attributes and hashtags 
  • Timeline for transition and your next steps

Planning and precoding

Both new code development and code reuse require the application of secure coding principles - regardless of whether the code is written for internal software or for external products and services. This requires the evaluation of the organization-specific expectations and definition of recognized principles in advance. In addition, recommended actions for planning and precoding take into account known common and historical coding practices and errors that could lead to vulnerabilities.

The configuration of development tools, such as rule-based in integrated development environments (IDE), should enforce the creation of secure code. Quite critical is the qualification of developers and their familiarity with secure architectures and programming standards. The inclusion of information security expertise in the development team goes without saying.

During the coding process

During the coding process, coding practices and structured programming techniques play a primary role, taking into account the specific use case and its security needs. Insecure design techniques - for example, hard-coded passwords - should be consistently prohibited. Code should be adequately documented and reviewed to best eliminate security-related bugs. Code review should take place both during and after development, via static application security testing (SAST) or similar. Static testing methods support the shift left approach ("test early and often") by shifting left in the lifecycle by testing visible code for rule conformance early.

This allows early identification of tainted code, connections to files or specific object classes, or application-level gaps that can be abused for unnoticed interaction with third-party programs as exploitable vulnerabilities. Before the software is put into operation, Control 8.28 requires an evaluation of attack surfaces and the implementation of the least privilege principle. The analysis performed of the most common programming errors and documentation of their correction should be evaluated.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen

This may interest you as well:

Detection and prevention in information security management

Verification and maintenance

Even after the software has gone live, the topic of secure coding remains relevant. This includes secure updates as well as checks for known vulnerabilities in one's code. In addition, errors and suspected attacks must be documented so that necessary adjustments can be made promptly. In any case, unauthorized access to the source code must be reliably prevented by suitable tools.

Open source code

In the area of verification and maintenance, Measure 8.28 additionally lists explicit instructions for the use of external tools and libraries, such as open source software. These code components should be managed, updated and maintained in inventories. This can be done, for example, via a Software Bill of Material (SBOM). An SBOM is a formal, structured record of a software's packages and libraries and their relationships to each other and within the supply chain, in particular to keep track of reused code and open source components. The SBOM supports software maintainability and targeted security updates.

dqs-question-answer-question mark on wooden cubes on table

Certification according to ISO 27001

What effort do you have to reckon with to have your ISMS certified according to ISO 27001? Get information free of charge and without obligation.

We look forward to talking to you.


Secure code is an elementary foundation for putting a stop to potential attacks. The new Control 8.28 takes this long-suffering insight into account and upgrades the key role of secure coding in its importance for information security. However, since the measure comprises a large number of detailed recommendations for action and is technically demanding, its implementation will involve a comparatively high level of effort - this should be taken into account as early as the planning stage.

With the professional view of our experienced auditors, we support you in the compliant implementation of the measure. With our audit and certification expertise of more than 35 years, we are your ideal contact partner and will be happy to assist you with the topic of information security and certification in accordance with the ISO/IEC 27001:2022 standards.

Revision of ISO 27001: What does the update mean for your certification?

ISO/IEC 27001:2022 was published on October 25, 2022. This results in the following deadlines and timeframes for users to transition:

Last date for initial/re-certification audits according to the "old" ISO 27001:2013 

  • After April 30, 2024, DQS will conduct initial and recertification audits only according to the new standard ISO/IEC 27001:2022

Transition of all existing certificates according to the "old" ISO/IEC 27001:2013 to the new ISO/IEC 27001:2022 

  • There is a 3-year transition period starting from October 31, 2022 
  • Certificates issued according to ISO/IEC 27001:2013 or DIN EN ISO/IEC 27001:2017 are valid until October 31, 2025 at the latest, or have to be withdrawn on this date.

DQS: Simply leveraging Security.

Due to the transition periods, companies have sufficient time to adapt their ISMS in accordance with the new requirements and have it certified. However, the duration and effort of the entire change process should not be underestimated - especially if you do not have sufficient specialized personnel. If you want to be on the safe side, you should deal with the issue sooner rather than later and call on experienced specialists if necessary.

As audit and certification experts with more than 35 years of expertise, we are happy to support you in evaluating your current status, maybe as part of a delta audit. Find out from our numerous experienced auditors about the most important changes and their relevance for your organization. Together we will discuss your potential for improvement and support you until you receive your new certificate. Take advantage of our competence in information security! We look forward to hearing from you.

dqs-question-answer-question mark on wooden cubes on table

Any questions?

Contact us!

Without obligation and free of charge.

Markus Jegelka

DQS expert for information security management systems (ISMS) and long-time auditor for the standards ISO 9001, ISO/IEC 27001 and IT security catalog according to para 11.1a/b of the German Energy Industry Act (EnWG) with test procedure competence for § 8a (3) BSIG


You Might Also Enjoy These Reads

Discover more articles that dive deep into related themes and ideas.
autonomous driving by a e-car, e-mobility

ENX VCS versus ISO 21434: Vehicle Cyber Security Audit

experience-with iso-27001-dqs-enterbrain-software-ag server cabinets

Lessons learned from ISO 27001 - a case study of ENTERBRAIN Software

Mixing console in a recording studio with sliders at different heights

Configuration management in information security