This article is a technical explanation and implementation example created using AI. Although the code and procedures provided are based on primary sources, the author has not verified their operation on actual hardware. Operation may vary depending on the environment and version.
The OWASP Top 10 is a standard document aimed at raising awareness about the most critical security risks in web applications. It is widely recognized among developers and in the field of web application security, positioned as a first step toward safer coding. For an enterprise, adopting this document and initiating a process to minimize application risks can be an effective first step in transforming the software development culture within the organization into one that produces secure code. Based on official information, this article outlines the components related to the history of the OWASP Top 10, data analysis plans, and alignment with operational checks.
Overview and Evolution of OWASP Top 10 Based on Official Information
The OWASP Top 10 is a document representing broad consensus regarding web application vulnerabilities and security risks. The most recent release is OWASP Top Ten 2025, while past versions such as OWASP Top Ten 2021, OWASP Top 10 2017 (PDF), and even older versions are publicly available on GitHub repositories and other platforms.
Additionally, with the release of each version, energetic multilingual translation activities have taken place. For example, records of completed translations and community contributions in Japanese and many other languages remain for the 2021, 2017, and 2013 versions.
Data Analysis Plan and Collection Process for the 2025 Version
For OWASP Top 10 2025, a detailed data analysis plan has been established to collect and analyze a comprehensive dataset related to identified application vulnerabilities.
Data Sources and Infrastructure
Data is collected from various sources, including security vendors, consulting firms, bug bounty programs, and contributions from companies and organizations. These are normalized to enable leveled comparisons between Human assisted Tooling (HaT) and Tooling assisted Humans (TaH). The analysis and storage are planned to leverage the OWASP Azure cloud infrastructure.
Forms of Data Contribution and Validation (Verified / Unverified)
Data contributions support both Known and Pseudo-anonymous forms. From the perspective of enhancing data validity, quality, and reliability, it is recommended that contributors be identifiable (“Known”). The verification status of contributors is classified into the following scenarios:
Verified Data Contribution
Scenario 1: The contributor is known and agrees to be publicly identified as the contributing party.
Scenario 2: The contributor is known, but prefers not to be publicly identified.
Scenario 3: The contributor is known, but does not wish to be recorded in the dataset.
Unverified Data Contribution
- Scenario 4: The contributor is anonymous. When unverified data is included in the analysis scope, it is handled with careful distinction.
Data Structure and Mandatory/Optional Fields
To conduct accurate analysis, necessary data elements and optional metadata are defined. Minimum required items include the time frame (period), the total number of applications tested, a list of CWEs, and the number of applications containing each respective CWE.
Furthermore, it is recommended to provide the following additional metadata:
Contributor name (organization name or anonymous)
Contributor contact email address
Time frame (2024, 2023, 2022, 2021, etc.)
Number of applications tested
Test type (TaH, HaT, tooling)
Primary language (code)
Geographic region (global, North America, EU, Asia, other)
Primary industry (multiple, financial, industrial, software, etc.)
Whether retesting or duplicate testing of the same application is included or not (T/F)
CWE data (list of CWEs and number of applications where detected; core CWEs are recommended rather than CWE categories)
Note that if an organization maintains two types of datasets—HaT (Human assisted Tools: tool-driven with high volume and frequency) and TaH (Tool assisted Human: human-driven with lower volume and frequency)—it is recommended to submit them separately.
Surveys and Community Supplementation
In addition to data analysis, similar to OWASP Top 10 2021, surveys using Google Forms or similar tools will be conducted to identify categories that are not yet reflected in the data but are considered important by the community. CWEs included in the survey are selected based on current trend findings and CWEs outside the Top 10 within the data.
Key Points of Analysis Methodology
While high-level data normalization is performed, versions of the raw datasets are also retained for future analysis. The distribution of CWEs is analyzed, and CWEs may be reclassified and consolidated into larger buckets (categories) as necessary, with all normalization actions clearly documented.
Additionally, as a risk evaluation methodology, the model of calculating and determining the incidence rate—which indicates the probability that an application contains at least one CWE instance, rather than the discovery frequency within a single application—is continued. The incidence rate is calculated by comparing the total number of applications tested in the dataset with the number of applications in which each CWE was found. Furthermore, progress is being made on developing baseline CWSS scores for the top 20 to 30 CWEs and incorporating potential impact into the Top 10 weighting.
Notes on Usage and Approaches to Mapping with Operational Checks
When mapping the OWASP Top 10 to an organization’s operational checks, a safe approach is to inventory configuration and monitoring items for each risk category, rather than reproducing attacks. As indicated in the primary sources, the first step should be transforming development culture and minimizing risk, while organizing the company’s application assets and test results by referring to publicly available standard documents and data structure definitions.
コメント