From f0a7fdaa400b1d1a2750a3834eb2e059a921516c Mon Sep 17 00:00:00 2001
From: TheBigStonk <64230005+TheBigStonk@users.noreply.github.com>
Date: Sat, 8 Feb 2025 16:23:20 +1300
Subject: [PATCH 1/3] Update 0xb0-next-devs.md with table cell linebreaks
Adding in linebreaks within the table of information to make readability better
---
editions/2023/en/0xb0-next-devs.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/editions/2023/en/0xb0-next-devs.md b/editions/2023/en/0xb0-next-devs.md
index 89139c49f..c55211e07 100644
--- a/editions/2023/en/0xb0-next-devs.md
+++ b/editions/2023/en/0xb0-next-devs.md
@@ -14,11 +14,11 @@ projects.
| | |
|-|-|
-| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC). For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs. The [OWASP Vulnerable Web Applications Directory Project][5] provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs. You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. |
-| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements. If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. |
+| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC).
For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs.
The [OWASP Vulnerable Web Applications Directory Project][5] provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs.
You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. |
+| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project.
OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements.
If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. |
| **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Cheat Sheet Series][10] is a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][11] and the [REST Assessment Cheat Sheet][12] as well the [GraphQL Cheat Sheet][13]. |
-| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][14] gives you a good overview of what security controls you should look to include in your project. OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
-| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][15] to improve your processes of building APIs. Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][16]. |
+| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][14] gives you a good overview of what security controls you should look to include in your project.
OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
+| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][15] to improve your processes of building APIs.
Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][16]. |
[1]: https://owasp.org/projects/
[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder
From fb2bef5340a6ad7c67d3e89843fe13922e5596c7 Mon Sep 17 00:00:00 2001
From: TheBigStonk <64230005+TheBigStonk@users.noreply.github.com>
Date: Sat, 8 Feb 2025 16:31:21 +1300
Subject: [PATCH 2/3] Add OWASP Threat Modelling Process into Architecture
Session
I believe this logically makes more sense than doing this as it's own cell.
---
editions/2023/en/0xb0-next-devs.md | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/editions/2023/en/0xb0-next-devs.md b/editions/2023/en/0xb0-next-devs.md
index c55211e07..b24490f49 100644
--- a/editions/2023/en/0xb0-next-devs.md
+++ b/editions/2023/en/0xb0-next-devs.md
@@ -15,10 +15,10 @@ projects.
| | |
|-|-|
| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC).
For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs.
The [OWASP Vulnerable Web Applications Directory Project][5] provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs.
You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. |
-| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project.
OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements.
If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. |
-| **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Cheat Sheet Series][10] is a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][11] and the [REST Assessment Cheat Sheet][12] as well the [GraphQL Cheat Sheet][13]. |
-| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][14] gives you a good overview of what security controls you should look to include in your project.
OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
-| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][15] to improve your processes of building APIs.
Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][16]. |
+| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements.
If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. |
+| **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Cheat Sheet Series][10] is a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][11] and the [REST Assessment Cheat Sheet][12] as well the [GraphQL Cheat Sheet][13].
When considering security in the architecture of a new API project, it is important to perform threat modelling against the current state of the design and architecture of the system. The [OWASP Threat Modelling Process][14] provides a structured approach to application threat modeling. |
+| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][15] gives you a good overview of what security controls you should look to include in your project.
OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
+| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][16] to improve your processes of building APIs.
Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][17]. |
[1]: https://owasp.org/projects/
[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder
@@ -33,6 +33,7 @@ projects.
[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html
[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
-[14]: https://owasp.org/www-project-proactive-controls/
-[15]: https://owasp.org/www-project-samm/
-[16]: https://owasp.org/www-project-code-review-guide/
+[14]: https://owasp.org/www-community/Threat_Modeling_Process
+[15]: https://owasp.org/www-project-proactive-controls/
+[16]: https://owasp.org/www-project-samm/
+[17]: https://owasp.org/www-project-code-review-guide/
From 02667c8fe7be56f2d391dff14c0f14e5afec5e7f Mon Sep 17 00:00:00 2001
From: TheBigStonk <64230005+TheBigStonk@users.noreply.github.com>
Date: Sat, 8 Feb 2025 16:59:54 +1300
Subject: [PATCH 3/3] Add Code Review Section
Small line break adjustments and branching a new section on code review for developers.
---
editions/2023/en/0xb0-next-devs.md | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/editions/2023/en/0xb0-next-devs.md b/editions/2023/en/0xb0-next-devs.md
index b24490f49..a54db5cbe 100644
--- a/editions/2023/en/0xb0-next-devs.md
+++ b/editions/2023/en/0xb0-next-devs.md
@@ -14,11 +14,13 @@ projects.
| | |
|-|-|
-| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC).
For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs.
The [OWASP Vulnerable Web Applications Directory Project][5] provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs.
You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. |
+| **Education** | The [Application Security Wayfinder][2] should give you a good idea about what projects are available for each stage/phase of the Software Development LifeCycle (SDLC).
For hands-on learning/training you can start with [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] or [OWASP Juice Shop][4]: both have intentionally vulnerable APIs. The [OWASP Vulnerable Web Applications Directory Project][5] also provides a curated list of intentionally vulnerable applications: you'll find there several other vulnerable APIs.
You can also attend [OWASP AppSec Conference][6] training sessions, or [join your local chapter][7]. |
| **Security Requirements** | Security should be part of every project from the beginning. When defining requirements, it is important to define what "secure" means for that project. OWASP recommends you use the [OWASP Application Security Verification Standard (ASVS)][8] as a guide for setting the security requirements.
If you're outsourcing, consider the [OWASP Secure Software Contract Annex][9], which should be adapted according to local law and regulations. |
| **Security Architecture** | Security should remain a concern during all the project stages. The [OWASP Cheat Sheet Series][10] is a good starting point for guidance on how to design security in during the architecture phase. Among many others, you'll find the [REST Security Cheat Sheet][11] and the [REST Assessment Cheat Sheet][12] as well the [GraphQL Cheat Sheet][13].
When considering security in the architecture of a new API project, it is important to perform threat modelling against the current state of the design and architecture of the system. The [OWASP Threat Modelling Process][14] provides a structured approach to application threat modeling. |
| **Standard Security Controls** | Adopting standard security controls reduces the risk of introducing security weaknesses while writing your own logic. Although many modern frameworks now come with effective built-in standard controls, [OWASP Proactive Controls][15] gives you a good overview of what security controls you should look to include in your project.
OWASP also provides some libraries and tools you may find valuable, such as validation controls. |
-| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][16] to improve your processes of building APIs.
Several other OWASP projects are available to help you during the different API development phases e.g., the [OWASP Code Review Guide][17]. |
+| **Secure Code Review** | It is important that developers continuously review code for potential security issues. The [OWASP Code Review Guide][16] has been written to assist technical staff in manual code review via an initial section on “why and how of code reviews” and a secondary section focusing on the “types of vulnerabilities and how to identify throughout the review”. |
+| **Secure Software Development Life Cycle** | You can use the [OWASP Software Assurance Maturity Model (SAMM)][17] to improve your processes of building APIs. |
+
[1]: https://owasp.org/projects/
[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder
@@ -35,5 +37,5 @@ projects.
[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
[14]: https://owasp.org/www-community/Threat_Modeling_Process
[15]: https://owasp.org/www-project-proactive-controls/
-[16]: https://owasp.org/www-project-samm/
-[17]: https://owasp.org/www-project-code-review-guide/
+[16]: https://owasp.org/www-project-code-review-guide/
+[17]: https://owasp.org/www-project-samm/