March 28, 2025
This learning module is part of the building block:
Secure development is a broad term that deals with how to develop software that does not contain vulnerabilities that can be exploited by malicious actors. In this module, we describe various vulnerability lists that support a secure development process. A safe development process is typically necessary to achieve certain levels of security specified by a security standard (such as IEC 62443 or ETSI 303 645).
Vulnerability lists enumerate specific design and implementation flaws or categories of these that may pose security risks to products and applications. The lists help create a common language for secure design and routines around software development. Vulnerability lists are usually maintained by volunteers or non-profit organisations and are based on knowledge gathered from relevant industries.
The OWASP top 10 is a list of the most prevalent vulnerabilities found in web applications today organised in categories. Developed by the OWASP organisation, which is run by volunteers from all over the world, the OWASP top 10 helps companies make their developers and quality departments aware of the most frequent vulnerabilities in production software, which is useful for prioritising security efforts.
In addition to describing widespread vulnerabilities, the list describes various methods to avoid or mitigate them, which supports developers in writing more secure software.
MITRE CWE top 25 is a list of the most dangerous software weaknesses, i.e. the 25 most common and serious errors on MITRE's overall list, which is called CWE, 'Common Weakness Enumeration'. The full list includes hundreds of different software weaknesses organised by category.
Unlike the OWASP top 10, the CWE top 25 is more specific and does not aggregate vulnerabilities into broad categories, making it a useful index of specific bugs. It allows filtering by technology, such as specific programming languages or frameworks.
Like OWASP, MITRE also provides possible solutions and methods to avoid these software weaknesses and provides examples of real-world occurrences of these errors.
Standards such as IEC 62443 and ETSI 303 645 describe specific requirements that must be implemented in order for a product to achieve a given level of security. Understanding common security flaws and vulnerabilities, helps you stay ahead of the requirements of such formal standards.
As an example, the ETSI 303 645 standard has a requirement not to use universal default passwords. Vulnerabilities related to the use of universal default passwords are described on both MITRE's and OWASP's vulnerability lists. Moreover, both resources describe methods to protect against their use.
On MITRE's vulnerability list is 'CWE-798: Use of Hard-coded Credentials' number 22. It covers the use of standard passwords (or other access-granting data) across different installations of the same product.
On OWASP's vulnerability list, the category 'Identification and Authentication Failures' is number 7. It covers a wide range of errors in identification and authentication mechanisms, such as the use of default passwords, which are not unique per installation.
Another example is the requirement in the IEC 62443-4-2 standard that users and devices must use an authorization mechanism. Such a mechanism makes sure that users of the product can only do what they are authorized to do. Lack of authorization is also a vulnerability that appears on both OWASP's and MITRE's vulnerability lists.
At MITRE's, 'CWE-862: Missing Authorization' is number 9, and the category 'Broken Access Control' is no. 1 on OWASP's top 10.
Vulnerability lists can be used as a starting point for static analysis of one's software. Analysis tools such as Semgrep and CodeQL can be used to find vulnerabilities in code that relate specifically to individual OWASP top 10 categories or specific weaknesses on MITRE's CWE list.
These tools can use predefined rules to help you find instances of errors, but you can also write your own 'rules' and thus use the tools to maintain internal code standards.
The tools can be run continuously or periodically during the development process, either locally at the developers or centrally as part of a CI pipeline. The sooner developers can be informed of bugs and flaws in their code, the sooner they can fix them.
Make your developers aware of these widespread vulnerabilities, especially if you intend to meet the requirements of a security standard. Incorporate automatic analysis (such as static analysis) into your development process to identify errors before the product goes into production.
The contents described above have been developed in the project:
’CyPro – Cybersecure manufacturing in Denmark’ by Aarhus University, Alexandra Institut, DAMRC, UGLA Insights and FORCE Technology funded by The Danish Industry Foundation. Material from the project is published under licence CC BY-SA 4.0
Get your certificate for this completed building block. Request the certificate and we will send you the personal certificate.
