6.2 Secure development life cycle

Requirement

Before developing a network and information system, including software, the relevant entities shall lay down rules for the secure development of network and information systems and apply them when developing network and information systems in-house or when outsourcing the development of network and information systems. The rules shall cover all development phases, including specification, design, development, implementation and testing.

Guidance

• Take into account the entity’s policies and norms (if available) and industry-recognised standards when developing the rules for the secure development of network and information systems (51).

Examples of evidence

• Documented rules for the secure development of network and information systems which align with the entity’s policies and norms and are based on relevant standards and good practices.

Requirement

For the purpose of point 6.2.1., the relevant entities shall: (a) carry out an analysis of security requirements at the specification and design phases of any development or acquisition project undertaken by the relevant entities or on behalf of those entities; (b) apply principles for engineering secure systems and secure coding principles to any information system development activities such as promoting cybersecurity-by-design, zero-trust architectures; (c) lay down security requirements regarding development environments;

(d) establish and implement security testing processes in the development life cycle; (e) appropriately select, protect and manage security test data; (f) sanitise and anonymise testing data according to the risk assessment carried out pursuant to point 2.1.

Guidance

• A secure software development life cycle (S SDLC) process should be implemented by all entities. However, smaller entities can use a less demanding process such as implementing secure-by-design practices and security-testing processes.
• Depending on the type of requirement, the rules for the secure development of software and systems should include appropriate software testing methods (e.g. black-box, ad-hoc testing, static versus dynamic application security testing).
• Test security by design at various stages of the secure development of the SSDLC prior to go-live, utilising independent tools and a self-service testing platform throughout the SSDLC.
• When real production data - or derived variations of it - is used for testing, ensure that such data is properly sanitised or anonymised. An indicative, non-exhaustive list of techniques:
  • masking or pseudonymization on fields like names, emails, IDs;
  • deletion or redaction of identifiers (e.g. personal IDs, birth dates, ZIP codes); and
  • non-irreversible or one-way anonymisation.
• When using Free and Open Source Software components, entities should take into account the voluntary nature of open source projects (see guidance of section 5.1). Where possible, entities should assist the open source projects that they depend on in adopting secure systems and secure coding principles (such as introducing SSDLC processes suited to the project’s way of working).

Examples of evidence

• Evidence that secure development rules have been adopted (indicative, non-exhaustive list):
  • documentation for each phase of the life cycle,
  • process and workflow diagrams,
  • audit and testing reports,
  • version control,
  • change management logs,
  • code reviews, and
  • project management tools.
• Evidence of the test results from secure development environments, including that measures for protecting test data are maintained.
• Evidence of the software-testing methods chosen for a particular test scenario and an explanation of the choice.
• Test results of each phase of the SSDLC maintained and up to date.
• Test results maintained and, where appropriate, approved by management bodies.
• Evidence that a software-testing method is chosen at each stage of the software development life cycle.

Requirement

For outsourced development of network and information systems, the relevant entities shall also apply the policies and procedures referred to in points 5 and 6.1.

Guidance

• Align the secure development rules with the security testing policy (Annex to the regulation, point 6.5) and procedures and with the secure acquisition of ICT services, systems or product processes (Annex to the regulation, point 6.1).
• Communicate the internal development rules with the relevant personnel from outsourced development.
• Hold regular cross-organisational unit meetings during all phases of the development life cycle.

Examples of evidence

• Comparison of the secure development rules with the security-testing policy and with the secure acquisition of ICT services, systems or product processes, checking whether the security requirements are set consistently in all these documents.
• Evidence of communicating the internal development rules with relevant personnel from outsourced development.
• Records or minutes from cross organisational unit meetings where the development of a network and information system, including software, was discussed.

Requirement

The relevant entities shall review and, where necessary, update their secure development rules at planned intervals.

Guidance

• Review the rules for the secure development of network and information systems at least once every two years.

Examples of evidence

• Documentation that outlines the schedule and frequency for reviewing secure development rules.
• Documented evidence of the process for reviewing the patch development process and secure-by design software configurations.
• Meeting minutes, review findings and actions taken to improve the development rules.
• Version history or change log of secure development procedures showing updates made as a result of reviews.
  • Specific sections in the documents highlighting what changes were made and the rationale behind them.
• Reports from internal and external audits that evaluate the process for reviewing secure development rules.
• Documentation of change requests related to secure development rules, including those arising from review findings.
• Logs or records tracking the implementation of changes to ensure they are applied throughout the development process.

Tips: guidance

• Consider threat modelling as part of the security requirements analysis.
• Keep separate environments for development purposes, testing purposes and production.
• Ensure the use of results of application assessments to regularly enhance developer training and the SSDLC process.
• Defined methods and tooling for performing analysis and tracking of usage of third party libraries should be in place.
• Consider integrating root cause analysis results into SSDLC process changes, if any.
• In addition to the regular reviews, the entity should review and, where necessary, update its secure development rules when there are significant changes to technology, operations or risks or in the event of significant incidents.

Tips: examples of evidence

• Evidence of the use of threat modelling (indicative, non-exhaustive list):
  • documentation of the process used for example STRIDE or DREAD,
  • data flow diagrams, and
  • meeting minutes.
• Evidence of separate environments for development, testing and production, for example different network segments, servers, databases, existence of accounts used for this purpose and change management records.
• Relevant personnel aware of the secure development rules.
• Meeting minutes, logs, reports, etc. showing that the secure development rules were reviewed and possibly changed following significant changes to technology, operations or risks or in the event of significant incidents.