add security best pratices for your project md file in file bg

Author: BlueButterflies

_articles/bg/security-best-practices-for-your-project.md

@@ -0,0 +1,84 @@
+---
+lang: en
+untranslated: true
+title: Най-добри практики за сигурност за вашия проект
+description: Укрепете бъдещето на вашия проект, като изградите доверие чрез основни практики за сигурност – от многофакторна автентификация (MFA) и сканиране на код до безопасно управление на зависимостите и отчитане на частни уязвимости.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Като оставим настрана грешките и новите функции, дълголетието на един проект зависи не само от неговата полезност, но и от доверието, което печели от потребителите си. Силните мерки за сигурност са важни, за да се запази това доверие. Ето някои важни действия, които можете да предприемете, за да подобрите значително сигурността на вашия проект.
+
+## Уверете се, че всички привилегировани участници са активирали многофакторно удостоверяване (MFA)
+
+### Злонамерен участник, който успее да се представи за привилегирован участник във вашия проект, ще причини катастрофални щети.
+
+След като получи привилегирован достъп, този участник може да промени вашия код, за да го накара да извършва нежелани действия (напр. да копае криптовалута), или може да разпространява зловреден софтуер в инфраструктурата на вашите потребители, или може да има достъп до частни хранилища за код, за да открадне интелектуална собственост и чувствителни данни, включително идентификационни данни за други услуги.
+
+MFA предоставя допълнителен слой сигурност срещу поглъщане на акаунт. След като е активирано, трябва да влезете с вашето потребителско име и парола и да предоставите друга форма на удостоверяване, която само вие знаете или до която имате достъп.
+
+## Защитете кода си като част от работния процес на разработка
+
+### Уязвимостите в сигурността на вашия код са по-евтини за отстраняване, когато бъдат открити в началото на процеса, отколкото по-късно, когато се използват в продукцията.
+
+Използвайте инструмент за статично тестване на сигурността на приложенията (SAST), за да откриете уязвимости в сигурността на вашия код. Тези инструменти работят на ниво код и не се нуждаят от среда за изпълнение, следователно могат да бъдат изпълнени в началото на процеса и могат да бъдат безпроблемно интегрирани в обичайния ви работен процес на разработка, по време на изграждането или по време на фазите на преглед на кода.
+
+Все едно квалифициран експерт да прегледа вашето хранилище за код, помагайки ви да откриете често срещани уязвимости в сигурността, които биха могли да се крият на видно място, докато кодирате.
+
+Как да изберете вашия SAST инструмент?
+Проверете лиценза: Някои инструменти са безплатни за проекти с отворен код. Например GitHub CodeQL или SemGrep.
+Проверете покритието за вашия(ите) език(ци)
+
+* Изберете такъв, който лесно се интегрира с инструментите, които вече използвате, със съществуващия ви процес. Например, по-добре е, ако предупрежденията са налични като част от съществуващия ви процес и инструмент за преглед на код, вместо да използвате друг инструмент, за да ги видите.
+* Пазете се от фалшиви положителни резултати! Не искате инструментът да ви забавя без причина!
+* Проверете функциите: някои инструменти са много мощни и могат да проследяват дефекти (пример: GitHub CodeQL), някои предлагат генерирани от изкуствен интелект предложения за корекции, а някои улесняват писането на персонализирани заявки (пример: SemGrep).
+
+## Не споделяйте тайните си
+
+### Чувствителни данни, като API ключове, токени и пароли, понякога могат случайно да бъдат добавени към вашето хранилище.
+
+Представете си следния сценарий: Вие сте администратор на популярен проект с отворен код с принос от разработчици от цял ​​свят. Един ден, сътрудник несъзнателно добавя към хранилището някои API ключове на услуга на трета страна. Дни по-късно някой намира тези ключове и ги използва, за да влезе в услугата без разрешение. Услугата е компрометирана, потребителите на вашия проект изпитват прекъсвания и репутацията на вашия проект е засегната. Като администратор, вие сте изправени пред трудните задачи за отмяна на компрометирани тайни, разследване на злонамерени действия, които атакуващият би могъл да извърши с тази тайна, уведомяване на засегнатите потребители и внедряване на корекции.
+
+За да се предотвратят подобни инциденти, съществуват решения за „тайно сканиране“, които да ви помогнат да откриете тези тайни във вашия код. Някои инструменти като GitHub Secret Scanning и Trufflehog от Truffle Security могат да ви попречат да ги преместите в отдалечени клонове, а някои инструменти автоматично ще отменят някои тайни вместо вас.
+
+## Проверете и актуализирайте зависимостите си
+
+### Зависимостите във вашия проект могат да имат уязвимости, които компрометират сигурността му. Ръчното поддържане на зависимостите актуални може да бъде времеемка задача.
+
+Представете си: проект, изграден върху здравата основа на широко използвана библиотека. Библиотеката по-късно открива голям проблем със сигурността, но хората, които са изградили приложението, използвайки я, не знаят за него. Чувствителни потребителски данни остават изложени на риск, когато атакуващ се възползва от тази слабост и се нахвърли, за да ги грабне. Това не е теоретичен случай. Точно това се случи с Equifax през 2017 г.: Те не успяха да актуализират зависимостта си от Apache Struts след известието, че е открита сериозна уязвимост. Тя беше експлоатирана и скандалният пробив в Equifax засегна данните на 144 милиона потребители.
+
+За да предотвратят подобни сценарии, инструменти за анализ на състава на софтуера (SCA), като Dependabot и Renovate, автоматично проверяват вашите зависимости за известни уязвимости, публикувани в публични бази данни като NVD или GitHub Advisory Database, и след това създават заявки за изтегляне, за да ги актуализират до безопасни версии. Поддържането на актуална информация с най-новите версии на безопасни зависимости предпазва вашия проект от потенциални рискове.
+
+## Избягвайте нежелани промени със защитени клонове
+
+### Неограниченият достъп до основните ви клонове може да доведе до случайни или злонамерени промени, които могат да въведат уязвимости или да нарушат стабилността на вашия проект.
+
+Нов участник получава достъп за запис в основния клон и случайно добавя промени, които не са тествани. След това се разкрива сериозен пропуск в сигурността, благодарение на последните промени. За да се предотвратят подобни проблеми, правилата за защита на клоновете гарантират, че промените не могат да бъдат добавяни или обединявани във важни клонове, без първо да бъдат прегледани и да преминат през определени проверки за състояние. Вие сте в по-голяма безопасност и по-добре с тази допълнителна мярка, гарантираща първокласно качество всеки път.
+
+## Настройте механизъм за приемане на доклади за уязвимости
+
+### Добра практика е да улесните потребителите си да докладват за грешки, но големият въпрос е: когато тази грешка има въздействие върху сигурността, как могат безопасно да ви я докладват, без да ви поставят в цел за злонамерени хакери?
+
+Представете си: Изследовател по сигурността открива уязвимост във вашия проект, но не намира ясен или сигурен начин да я докладва. Без определен процес, той може да създаде публичен проблем или да го обсъди открито в социалните медии. Дори и да са добронамерени и да предложат поправка, ако го направят с публичен пул рекейв (pull request), други ще я видят, преди да бъде обединена! Това публично разкриване ще изложи уязвимостта на злонамерени лица, преди да имате възможност да я отстраните, което потенциално ще доведе до zero-day експлойт, атакуващ вашия проект и неговите потребители.
+
+### Политика за сигурност
+
+За да избегнете това, публикувайте политика за сигурност. Политиката за сигурност, дефинирана във файл `SECURITY.md`, описва подробно стъпките за докладване на проблеми със сигурността, създава прозрачен процес за координирано разкриване и установява отговорностите на екипа на проекта за справяне с докладваните проблеми. Тази политика за сигурност може да бъде толкова проста, колкото „Моля, не публикувайте подробности в публичен проблем или PR, изпратете ни личен имейл на [email protected]“, но може да съдържа и други подробности, като например кога могат да очакват да получат отговор от вас. Всичко, което може да помогне за ефективността и ефикасността на процеса на разкриване.
+
+### Частно докладване на уязвимости
+
+На някои платформи можете да рационализирате и подобрите процеса си на управление на уязвимости, от приемане до излъчване, с частни проблеми. В GitLab това може да се направи с частни проблеми. В GitHub това се нарича частно докладване на уязвимости (PVR). PVR позволява на поддържащите да получават и адресират доклади за уязвимости, всичко това в рамките на платформата GitHub. GitHub автоматично ще създаде частен fork за писане на корекциите и чернова на съобщение за сигурност. Всичко това остава поверително, докато не решите да разкриете проблемите и да публикувате корекциите. За да се затвори цикълът, ще бъдат публикувани съвети за сигурност, които ще информират и защитават всички ваши потребители чрез техния SCA инструмент.
+
+## Заключение: Няколко стъпки за вас, огромно подобрение за вашите потребители
+
+Тези няколко стъпки може да ви се сторят лесни или основни, но те са от голяма полза, за да направят проекта ви по-сигурен за неговите потребители, защото ще осигурят защита срещу най-често срещаните проблеми.
+
+## Сътрудници
+
+### Много благодарности на всички администратори, които споделиха своя опит и съвети с нас за това ръководство!
+
+Това ръководство е написано от [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) с приноси от:
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + много други!