11 практик безопасной разработки. Карточки SecPost
Проблемы с безопасностью могут возникнуть на любом этапе разработки. Они появляются уже при постановке задачи, могут быть связаны с архитектурными решениями, ошибками в коде, сторонними компонентами, сборкой или настройкой продукта. Поэтому важен не отдельный сканер перед релизом, а процесс, который сопровождает продукт от требований до работы с уязвимостями после выпуска. SecPost выделил 11 практик, на которых строится безопасная разработка.
Безопасная разработка складывается из множества небольших решений, которые повторяются от версии к версии. Требования учитываются заранее, код и зависимости проверяются по ходу работы, сборка защищена, происхождение выпуска можно подтвердить, а найденные уязвимости возвращаются в процесс в виде новых требований и проверок. Если эта цепочка работает постоянно, безопасность перестает зависеть от аврала перед релизом.
Источники:
- https://hyperproof.io/resource/secure-software-development-best-practices/
- https://www.blackduck.com/blog/nist-ssdf-secure-software-development.html
- https://www.ncsc.gov.uk/collection/developers-collection/principles
- https://about.gitlab.com/the-source/security/10-tips-to-prioritize-security-in-software-development/
- https://www.redalertlabs.com/blog/the-10-things-to-know-about-nist-secure-software-development-framework
- https://csrc.nist.gov/projects/ssdf
Дополнительные:
- NIST — Secure Software Development Framework, публикации
https://csrc.nist.gov/projects/ssdf/publications - NIST SP 800-218, SSDF 1.1
https://csrc.nist.gov/pubs/sp/800/218/final - OWASP Application Security Verification Standard — ASVS
https://owasp.org/www-project-application-security-verification-standard/ - OWASP Software Assurance Maturity Model — SAMM
https://owaspsamm.org/ - CISA — Secure by Design
https://www.cisa.gov/securebydesign - SLSA — Build Provenance
https://slsa.dev/spec/v1.2/build-provenance - SLSA — спецификация
https://slsa.dev/spec/v1.2/
Читайте также
