Merge pull request #57 from OWASP/mkdocs

switch over to mkdocs and update the top 10 to the 2023/24 version

Author: andreashappe

.DS_Store

@@ -0,0 +1,24 @@
+name: Build Github Pages
+on:
+  push:
+    branches:
+      - main
+permissions:
+  contents: write
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - uses: actions/cache@v2
+        with:
+          key: ${{ github.ref }}
+          path: .cache
+      - name: Install Dependencies
+        run: pip install mkdocs-material
+      - run: mkdocs gh-deploy --force --clean

.github/workflows/deploy.yml

@@ -2,3 +2,4 @@ __pycache__
 env
 .vscode
 _site/
+.DS_Store

.gitignore

@@ -1,13 +1,3 @@
----
-
-layout: col-document
-tags: OWASP Top Ten Proactive Controls 2024, Intro
-document: OWASP Top Ten Proactive Controls 2024
-order: 404
-permalink: /v4/en/introduction
-
----
-
 # Introduction
 
 For years, developers have suffered through introducing the same security issues into the things they build. The most common issues, which have existed for decades, have been documented by the OWASP Top Ten. Many of the issues in the earliest version still exist in some form today. A mechanism is needed to counter these challenges, and that mechanism is proactive controls.
@@ -24,30 +14,18 @@ Please note that while complying with best proactive practices will reduce the c
 
 The OWASP Top 10 Proactive Controls 2024 is a list of security techniques every software architect and developer should know and heed. The main goal of this document is to provide concrete, practical guidance that helps developers build secure software. These techniques should be applied proactively at the early stages of software development to ensure maximum effectiveness.
 
-***How to Use this Document***
+### How to Use this Document
 
 This document’s main purpose is to provide a solid foundation of topics to help drive introductory software security developer training. To be effective, these controls should be used consistently and thoroughly throughout all applications.
 
 However, this document is a starting point rather than a comprehensive set of techniques and practices.
 
 A fully secure development process should include comprehensive requirements from a standard such as the OWASP ASVS in addition to including a range of software development activities described in maturity models such as [OWASP SAMM](https://www.owasp.org/index.php/OWASP_SAMM_Project) and [BSIMM](https://www.bsimm.com/).
 
-***Target Audience***
+### Target Audience
 
 This document is primarily written for developers. However, development managers, product owners, Q/A professionals, program managers, and anyone involved in building software can also benefit from this document. 
 
-***How this List Was Created***
-This list was originally created by the current project leads with contributions from several volunteers. The document was then shared globally so even anonymous suggestions could be considered. Hundreds of changes were accepted from this open community process.
-
-## Relationship to other OWASP Projects
-OWASP is a volunteer-driven organization. Those volunteers contributed many useful documents, and this section points to some related OWASP documents and projects:
-
-- The best-known OWASP document is the [OWASP Top 10](https://owasp.org/Top10/). They detail the most common web application vulnerabilities and are also the base for this document. In contrast, this document is focused on defensive techniques and controls as opposed to risks. Each control in this document will map to one or more items in the risk-based OWASP Top 10. This mapping information is included at the end of each control description.
-- The OWASP ASVS: [The OWASP Application Security Verification Standard (ASVS)](https://owasp.org/www-project-application-security-verification-standard/) is a catalog of available security requirements and verification criteria. OWASP ASVS can be a source of detailed security requirements for development teams. Security requirements are categorized into different buckets based on a shared higher order security function. For example, the ASVS contains categories such as authentication, access control, error handling / logging, and web services. Each category contains a collection of requirements that represent the best practices for that category drafted as verifiable statements.
-- OWASP SAMM [Software Assurance Maturity Model (SAMM)](https://www.opensamm.org/) is an open framework to help organizations implement a strategy for maturing the software security tailored to the specific risks of the organization. . [SAMM] (https://owaspsamm.org/about/) supports the complete software lifecycle and can be used to identify what
-- Threat Modeling is an important part of secure application development, which can help identify potential security threats, derive security requirements, and tailor security controls to prevent potential threats. Successful use of security requirements involves four steps: discovery, documentation, implementation, and verification of the correct implementation of the functionality within an application. Threat modelling is one way to derive security requirements. Other sources are: industry standards, applicable laws, history of past vulnerabilities. Modeling tools, like [OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/) can be used to create threat model diagrams as part of a secure development lifecycle. 
-
-It is important to notice that this document primarily focuses on web applications, but other Top 10s could apply to your application, too. Examples of those are:
-- OWASP API Top 10
-- OWASP Mobile Application Top 10
+### How this List Was Created
 
+This list was originally created by the current project leads with contributions from several volunteers. The document was then shared globally so even anonymous suggestions could be considered. Hundreds of changes were accepted from this open community process.

Gemfile

@@ -1,28 +1,4 @@
----
-
-layout: col-document
-tags: OWASP Top Ten Proactive Controls 2024, Document Structure
-document: OWASP Top Ten Proactive Controls 2024
-order: 403
-
----
-
-# Document Structure
-
-This document is structured as a list of security controls. The list is ordered by importance with list item number 1 being the most important:
-
-* C1: Implement Access Control 
-* C2: Use Cryptography the right way
-* C3: Validate, Escape, Sanitize or Parameterize Untrusted Data
-* C4: Address Security from the Start
-* C5: Secure By Default Configurations 
-* C6: Assess and Update your Components 
-* C7: Implement Digital Identity
-* C8: Leverage Browser Security Features
-* C9: Implement Security Logging and Monitoring
-* C10: Stop Server Side Request Forgery
-
-## Security Controls
+# Security Controls
 
 The description of each control has the same structure. The control itself has an unique name preceeded by the control number: **Cx: Control Name**, e.g., *C1: Implement Access Control*.