Като оставим настрана грешките и новите функции, дълголетието на един проект зависи не само от неговата полезност, но и от доверието, което печели от своите потребители. Силните мерки за сигурност са важни, за да се запази това доверие. Ето някои важни действия, които можете да предприемете, за да подобрите значително сигурността на вашия проект.

Уверете се, че всички привилегировани участници са активирали многофакторно удостоверяване (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, и след това създават заявки за изтегляне, за да ги актуализират до безопасни версии. Поддържането на актуалност с най-новите безопасни версии на зависимостите предпазва вашия проект от потенциални рискове.

Избягвайте нежелани промени със защитени клонове

Неограниченият достъп до основните ви клонове може да доведе до случайни или злонамерени промени, които могат да въведат уязвимости или да нарушат стабилността на проекта ви.

Нов участник получава достъп за запис в основния клон и случайно публикува промени, които не са тествани. След това се разкрива сериозен пропуск в сигурността, благодарение на последните промени. За да се предотвратят подобни проблеми, правилата за защита на клоновете гарантират, че промените не могат да бъдат публикувани или обединявани във важни клонове, без първо да бъдат прегледани и да преминат през определени проверки за състояние. С тази допълнителна мярка сте в по-голяма безопасност и по-добре, гарантирайки първокласно качество всеки път.

Настройте механизъм за прием на данни за докладване на уязвимости

Добра практика е да улесните потребителите си да докладват за грешки, но големият въпрос е: когато тази грешка има въздействие върху сигурността, как могат безопасно да ви я докладват, без да ви поставят в цел за злонамерени хакери?

Представете си: Изследовател по сигурността открива уязвимост във вашия проект, но не намира ясен или сигурен начин да я докладва. Без определен процес, той може да създаде публичен проблем или да го обсъди открито в социалните медии. Дори и да е добронамерен и да предложи поправка, ако го направи с публична заявка за изтегляне, други ще я видят, преди да бъде обединена! Това публично разкриване ще изложи уязвимостта на злонамерени лица, преди да имате шанс да я отстраните, което потенциално ще доведе до експлойт от нулев ден, атакуващ вашия проект и неговите потребители.

Политика за сигурност

За да избегнете това, публикувайте политика за сигурност. Политиката за сигурност, дефинирана във файл SECURITY.md, описва подробно стъпките за докладване на проблеми със сигурността, създава прозрачен процес за координирано разкриване и установява отговорностите на екипа на проекта за справяне с докладваните проблеми. Тази политика за сигурност може да бъде толкова проста, колкото “Моля, не публикувайте подробности в публичен проблем или PR, изпратете ни личен имейл на security@example.com”, но може да съдържа и други подробности, като например кога могат да очакват да получат отговор от вас. Всичко, което може да помогне за ефективността и ефикасността на процеса на разкриване.

Частно докладване на уязвимости

На някои платформи можете да рационализирате и подобрите процеса си на управление на уязвимости, от приемане до излъчване, с частни проблеми. В GitLab това може да се направи с частни проблеми. В GitHub това се нарича частно докладване на уязвимости (PVR). PVR позволява на поддържащите да получават и адресират доклади за уязвимости, всичко това в рамките на платформата GitHub. GitHub автоматично ще създаде частен fork за писане на корекциите и проект на съобщение за сигурност. Всичко това остава поверително, докато не решите да разкриете проблемите и да публикувате корекциите. За да се затвори цикълът, ще бъдат публикувани съобщения за сигурност, които ще информират и защитават всички ваши потребители чрез техния SCA инструмент.

Заключение: Няколко стъпки за вас, огромно подобрение за вашите потребители

Тези няколко стъпки може да ви се сторят лесни или основни, но те са от голяма полза за по-голяма сигурност на вашия проект за неговите потребители, защото ще осигурят защита срещу най-често срещаните проблеми.

Сътрудници

Много благодарности на всички администратори, които споделиха своя опит и съвети с нас за това ръководство!

Това ръководство е написано от @nanzggits & @xcorail с приноси от:

@JLLeitschuh @intrigus-lgtm + много други!