6.2.4 The relevant entities shall review and, where necessary, update their secure development rules at …

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.

1. Pregled

1.1 Reference

1.2 Utvrđeni zahtjevi

1.3 Povezani propisi

2. Utvrđeni zahtjevi

3. Povezani propisi

Povezani zadaci

• ENISA -