Add Belarusian translate

_articles/be/index.html

@@ -0,0 +1,6 @@
+---
+layout: index
+title: Кіраўніцтва па адкрытым праграмным забеспячэнні
+lang: be
+permalink: /be/
+---

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

@@ -0,0 +1,83 @@
+---
+lang: be
+title: Лепшыя практыкі бяспекі для вашага праекта
+description: Умацуйце будучыню свайго праекта, умацоўваючы давер з дапамогай асноўных метадаў забеспячэння бяспекі-ад шматфактарнага аўтэнтыфікацыі і сканавання кода да бяспечнага кіравання залежнасцямі і канфідэнцыйных справаздач аб уразлівасцях.
+class: security-best-practices
+order: -1
+image: /assets/images/cards/security-best-practices.png
+---
+
+Акрамя выпраўлення памылак і дадання новых функцый, доўгатэрміновае існаванне праекта залежыць не толькі ад яго карыснасці, але і ад даверу, якое ён заслугоўвае ў карыстальнікаў. Надзейныя меры бяспекі важныя для захавання гэтага даверу. Ніжэй прыведзены ключавыя дзеянні, якія вы можаце зрабіць, каб значна павысіць бяспеку вашага праекта.
+
+## Пераканайцеся, што ўсе прывілеяваныя ўдзельнікі ўключылі двухфакторную аўтэнтыфікацыю (MFA)
+
+### Зламыснік, якому ўдасца выдаць сябе за ўдзельніка з прывілеяваным доступам, можа нанесці катастрафічны ўрон.
+
+Атрымаўшы прывілеяваны доступ, такі зламыснік можа змяніць ваш код, каб той выконваў непажаданыя дзеянні (напрыклад, майнинг криптовалюты), распаўсюдзіць шкоднаснае ПА ў інфраструктуры вашых карыстальнікаў або атрымаць доступ да зачыненых рэпазітарах, каб выкрасці інтэлектуальную ўласнасць і канфідэнцыйныя дадзеныя, уключаючы ўліковыя дадзеныя для іншых сэрвісаў.
+
+MFA забяспечвае дадатковы ўзровень абароны ад захопу ўліковага запісу. Пасля ўключэння вы павінны ўвайсці з лагінам і паролем, а таксама забяспечыць дадатковую форму аўтэнтыфікацыі, да якой у вас ёсць доступ (напрыклад, аднаразовы код з прыкладання).
+
+## Забяспечце бяспеку кода ў рамках працэсу распрацоўкі
+
+### Уразлівасці ў кодзе танней выпраўляць на ранніх этапах, чым пасля выхаду ў прадакшн.
+
+Выкарыстоўвайце інструмент статычнага аналізу бяспекі (SAST), каб выяўляць уразлівасці ў кодзе. Гэтыя інструменты працуюць на ўзроўні кода і не патрабуюць выкананай асяроддзя, таму іх можна запускаць на ранніх этапах і лёгка інтэграваць у звычайны працэс распрацоўкі — на этапе зборкі або пры праверцы кода.
+
+Гэта як калі б дасведчаны эксперт перачытваў ваш рэпазітар і дапамагаў знаходзіць распаўсюджаныя ўразлівасці, якія могуць быць незаўважныя пры звычайнай распрацоўцы.
+
+Як выбраць SAST-інструмент?
+Праверце ліцэнзію: некаторыя інструменты бясплатныя для open-source праектаў, напрыклад GitHub CodeQL або SemGrep.
+Праверце падтрымку вашых моў праграмавання.
+
+* Выбірайце інструмент, які лёгка інтэгруецца з ужо выкарыстоўванымі вамі сродкамі і працэсамі. Напрыклад, лепш, калі абвесткі будуць адлюстроўвацца ў рамках Вашага бягучага працэсу праверкі кода, а не ў асобным інструменце.
+* Сцеражыцеся ілжывых спрацоўванняў! Вы не хочаце, каб інструмент запавольваў вашу працу без прычыны!
+* Праверце функцыянальнасць: некаторыя інструменты вельмі магутныя і падтрымліваюць аналіз патокаў дадзеных (напрыклад, GitHub CodeQL), іншыя прапануюць выпраўлення, згенераваныя ІІ, трэція спрашчаюць напісанне карыстацкіх запытаў (напрыклад, SemGrep).
+
+## Не захоўвайце і не публікуйце свае сакрэты
+
+### Канфідэнцыйныя дадзеныя, такія як API-ключы, токены і паролі, часам выпадкова трапляюць у рэпазітар.
+
+Уявіце сітуацыю: вы-суправаджалы папулярнага open-source праекта, у які ўносяць ўклад распрацоўшчыкі з усяго свету. Аднойчы ўдзельнік выпадкова камітаў ў рэпазітар API-ключы іншага сэрвісу. Праз некалькі дзён хтосьці знаходзіць гэтыя ключы і выкарыстоўвае іх для несанкцыянаванага доступу. Сэрвіс аказваецца скампраметаваны, карыстальнікі вашага праекта сутыкаюцца з прастоем, а рэпутацыя праекта пакутуе. Як суправаджалы, вы цяпер вымушаныя адклікаць скампраметаваныя ключы, высветліць, якія дзеянні зламыснік мог здзейсніць з гэтым доступам, паведаміць пацярпелых карыстальнікаў і ўкараніць выпраўлення.
+
+Каб прадухіліць такія інцыдэнты, існуюць рашэнні для сканавання сакрэтаў, якія дапамагаюць выяўляць такія дадзеныя ў вашым кодзе. Некаторыя інструменты, напрыклад Github Secret Scanning і Trufflehog ад Truffle Security, могуць прадухіліць адпраўку сакрэтаў у выдаленыя галінкі, а некаторыя аўтаматычна адклікаюць выяўленыя ключы.
+
+## Правярайце і абнаўляйце залежнасці
+
+### Уразлівасці ў залежнасці ад вашага праекта могуць падарваць яго бяспеку. Ручное абнаўленне залежнасцяў-працаёмкая задача.
+
+Уявіце: праект пабудаваны на трывалай аснове шырока выкарыстоўванай бібліятэкі. Пазней у гэтай бібліятэцы выяўляецца сур'ёзная ўразлівасць, але распрацоўшчыкі прыкладання пра гэта не даведаюцца. Канфідэнцыйныя дадзеныя карыстальнікаў застаюцца адкрытымі, і зламыснік, скарыстаўшыся гэтай уразлівасцю, выкрадае іх. Гэта не тэорыя-менавіта так адбылося з Equifax ў 2017 годзе: яны не абнавілі залежнасць Apache Struts пасля паведамлення аб крытычнай уразлівасці. Яна была эксплуатаваная, і ў выніку ўцечкі пацярпелі дадзеныя 144 мільёнаў карыстальнікаў.
+
+Каб пазбегнуць падобнага, інструменты аналізу складу па (SCA), такія, як Dependabot і Renovate, аўтаматычна правяраюць залежнасці на наяўнасць вядомых уразлівасцяў з публічных баз дадзеных (напрыклад, NVD або GitHub Advisory Database) і ствараюць pull request'ы для абнаўлення да бяспечных версій. Падтрыманне залежнасцяў ў актуальным стане абараняе ваш праект ад патэнцыйных рызык.
+
+## Абараніце асноўныя галіны ад непажаданых змен
+
+### Неабмежаваны доступ да асноўных галін можа прывесці да выпадковых або шкоднасных змен, якія выклічуць уразлівасці або парушаць стабільнасць праекта.
+
+Новы ўдзельнік атрымлівае правы на запіс у асноўную галінку і выпадкова пушит неправераныя змены. У выніку выяўляецца сур'ёзная ўразлівасць, выкліканая гэтымі зменамі. Каб пазбегнуць такіх праблем, правілы абароны галінак гарантуюць, што змены не могуць быць ўліты ў важныя галінкі без папярэдняй праверкі і праходжання названых праверак статусу. З гэтай дадатковай мерай вы будзеце ў большай бяспекі, забяспечваючы высокую якасць кода пры кожным змене.
+
+## Наладзьце механізм прыёму справаздач аб уразлівасцях
+
+### Добрай практыкай з'яўляецца спрашчэнне працэсу паведамленні пра памылкі, але галоўнае пытанне: як карыстальнікі могуць бяспечна паведаміць аб уразлівасці, не прыцягваючы ўвагу зламыснікаў?
+
+Уявіце: даследчык бяспекі выяўляе ўразлівасць у вашым праекце, але не знаходзіць зразумелага або бяспечнага спосабу паведаміць пра яе. Без выразнага працэсу ён можа Стварыць публічны issue або абмеркаваць праблему ў сацсетках. Нават калі ён дзейнічае добрасумленна і прапануе выпраўленне, пры публічным pull request'е іншыя ўбачаць ўразлівасць да яе выпраўлення! Такое раскрыццё зробіць ўразлівасць даступнай для зламыснікаў да таго, як вы зможаце яе ліквідаваць, што можа прывесці да эксплуатацыі «ў нуль» і атацы на ваш праект і яго карыстальнікаў.
+
+### Палітыка бяспекі
+
+Каб пазбегнуць гэтага, Апублікуйце палітыку бяспекі. Палітыка бяспекі, апісаная ў файле `SECURITY.md', дэталізуе крокі для паведамлення аб праблемах бяспекі, стварае празрысты працэс каардынаванага раскрыцця і вызначае абавязкі каманды праекта па ліквідацыі паведамленых праблем. Палітыка можа быць простай: "калі ласка, не публікуйце дэталі ў публічных issue або PR, адпраўце нам ліст на "security@example.com" , але таксама можа ўтрымліваць дадатковыя звесткі, напрыклад, калі чакаць адказу. Любая інфармацыя, якая дапаможа зрабіць працэс раскрыцця эфектыўным і хуткім, карысная.
+
+### Прыватнае паведамленне аб уразлівасцях
+
+На некаторых платформах можна спрасціць і ўзмацніць працэс кіравання ўразлівасцямі — ад прыёму да абвесткі-з дапамогай прыватных зваротаў. У GitLab гэта рэалізавана праз прыватныя issue. У GitHub гэта называецца прыватным паведамленнем аб уразлівасцях (PVR). PVR дазваляе суправаджаюць атрымліваць і апрацоўваць справаздачы аб уразлівасцях прама ў GitHub. GitHub аўтаматычна стварае прыватны форк для напісання выпраўленняў і чарнавік security advisory. Усё гэта застаецца канфідэнцыйным, пакуль вы не вырашыце раскрыць праблему і выпусціць выпраўлення. У завяршэнне, security advisory публікуюцца і інфармуюць, а таксама абараняюць ўсіх вашых карыстальнікаў праз іх SCA-інструменты.
+
+## Заключэнне: некалькі крокаў для вас-велізарнае паляпшэнне для вашых карыстальнікаў
+
+Гэтыя крокі могуць здацца вам простымі або базавымі, але яны значна павышаюць бяспеку вашага праекта для карыстальнікаў, забяспечваючы абарону ад найбольш распаўсюджаных праблем.
+
+## Удзельнік
+
+### Вялікі дзякуй усім суправаджальнікам, якія падзяліліся з намі сваім вопытам і парадамі для гэтага кіраўніцтва!
+
+Гэта кіраўніцтва было напісана [@nanzggits](https://github.com/nanzggits) і [@xcorail](https://github.com/xcorail) пры ўдзеле: 
+
+[@JLLeitschuh](https://github.com/JLLeitschuh)
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + [многія іншыя](https://github.com/github/opensource.guide/graphs/contributors)!