diff --git a/editions/2023/en/0xb0-next-devs.md b/editions/2023/en/0xb0-next-devs.md index 89139c49f..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]. | -| **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]. | +| **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 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 @@ -33,6 +35,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/ +[14]: https://owasp.org/www-community/Threat_Modeling_Process +[15]: https://owasp.org/www-project-proactive-controls/ [16]: https://owasp.org/www-project-code-review-guide/ +[17]: https://owasp.org/www-project-samm/