[DRAFT] of Security Best Practices for Developers Guide

[riverma]

Purpose

• A guide for developers to adhere to security best practices for APIs, web-applications, CI/CD systems.
• Content provided curtesy @anrucker

Proposed Changes

• [ADD] Guide contents

Issues

• [New Best Practice Guide]: Security Reference Architecture #109

Testing

• Not yet tested

[riverma]

CC @anrucker for feedback / adjustments based on provided content at #109

[anrucker]

This guide looks great. Thanks so much, Rishi!

[jpl-jengelke]

I would consider adding a link to CISA's Secure-by-Design/Default initiative. They've produced a guide.

IEEE Computer Society also provides a number of recommendations that promote using OWASP.

NIST also published a Secure Software Development Framework (SSDF) standard.

[riverma]

Thanks @jpl-jengelke! @anrucker - what are your thoughts on the above recommendations? Should we include or do you feel your original list already covers the above?

[jpl-jengelke]

Could it be "Review updated security guidance from industry-leading experts, such as ..." and then include additional resources?

[riverma]

Thinking more about this guide, I'm wondering if we can make the following changes (CC @jpl-jengelke @anrucker):

• Can we offer any automation to either check for the "top 10" vulnerabilities automatically? Else - recommendations for IDEs or other tools that would help developers avoid the vulnerabilities? The best place to put those recs would be in the Quick Start section (which is empty right now). Going with the philosophy of SLIM - we should lean more towards automation than asking people to read lengthy guides.
• "Security Best Practices for Developers Guide" is a pretty broad category. Perhaps we should keep the focus for this specific guide on helping developers deal with common vulnerabilities instead? Naming the guide "Common Vulnerabilities For Developers" or something to that effect?

[jpl-jengelke]

Thinking more about this guide, I'm wondering if we can make the following changes (CC @jpl-jengelke @anrucker):

• Can we offer any automation to either check for the "top 10" vulnerabilities automatically? Else - recommendations for IDEs or other tools that would help developers avoid the vulnerabilities? The best place to put those recs would be in the Quick Start section (which is empty right now).
• "Security Best Practices for Developers Guide" is a pretty broad category. Perhaps we should keep the focus for this specific guide on helping developers deal with common vulnerabilities instead? Naming the guide "Common Vulnerabilities For Developers" or something to that effect?

True regarding the observation of a broad topic but it is an area of cybersecurity focus. Recently, the focus has been on implementing shift-left strategies that more tightly integrate development very early on with DevSecOps.

[jpl-jengelke]

• Can we offer any automation to either check for the "top 10" vulnerabilities automatically?
• "Security Best Practices for Developers Guide" is a pretty broad category.

I'd endorse option two since I think the project can offer a range of recommendations, and I think this may best serve as implementation guidance. We could also refer users to the #148 product for implementation.

[riverma]

• Can we offer any automation to either check for the "top 10" vulnerabilities automatically?
• "Security Best Practices for Developers Guide" is a pretty broad category.

I'd endorse option two since I think the project can offer a range of recommendations, and I think this may best serve as implementation guidance. We could also refer users to the #148 product for implementation.

I like option 2 as well. Keeps the focus of this guide simple and we can cross link to a separate guide on tools. If there's specific or common CVEs then we could also offer specific invocations to SCRUB or other tools to check for those CVEs.