Jaka jest najlepsza praktyka w zakresie obsługi PR usuwających luki w zabezpieczeniach w publicznym repozytorium?


22

Jak projekt open source z publicznym repozytorium najlepiej obsługiwać żądania ściągania (PR), które rozwiązują bezpiecznie zgłoszone, ale jeszcze nie ujawnione publicznie luki w zabezpieczeniach?

Jestem zaangażowany w projekt open source z udziałem kilkuset współpracowników. Informacje o zagrożeniach i luki w zabezpieczeniach publikujemy kilka razy w roku w ramach regularnie zaplanowanego comiesięcznego wydania. Nie publikujemy informacji o lukach, dopóki nie udostępnimy łatanej wersji. Jesteśmy w stanie bezpiecznie zarządzać problemami bezpieczeństwa w naszym systemie zarządzania projektami (JIRA). Ale nie mamy dobrego procesu maskowania PR, które naprawiają luki w zabezpieczeniach, gdy są one przesyłane do GitHub. Obawiamy się, że ludzie mogą znaleźć te poprawki przed ich opublikowaniem i stworzyć exploity zero-day.

Zastanawialiśmy się nad użyciem prywatnych repozytoriów, które rozwidlają główne repozytorium, ale znaczna część naszych obecnie sprawdzanych przepływów pracy i kontroli jakości dotyczy PR. Gdybyśmy przenieśli przepływ pracy do zespołu ds. Bezpieczeństwa tylko do prywatnego repozytorium, zmniejszyłoby to okno, gdy poprawka jest publiczna, do godzin potrzebnych do wygenerowania plików tar i opublikowania ich na sourceforge, co byłoby dużym ulepszeniem. Prawdopodobnie musielibyśmy również unikać łączenia PR z naszą publiczną wersją beta.

Przed pójściem w tym kierunku chciałbym wiedzieć, jaka jest najlepsza praktyka w zakresie obsługi poprawek błędów bezpieczeństwa przed wydaniem w projektach open source z otwartymi repozytoriami? Jeśli problem można lepiej rozwiązać za pomocą innej platformy niż GitHub, powinienem wspomnieć, że oceniamy migrację do GitLab.


1
Nie jestem pewien, czy istnieje najlepsza praktyka. GitLab jest zasadniczo prywatnym GitHub. Równoważenie problemów związanych z rozwiązaniami typu open source i zabezpieczeniami nie jest łatwe. Ile poprawek zabezpieczeń pochodzi od osób spoza zespołu ds. Bezpieczeństwa?
— Berin Loritsch,

Większość problemów zgłaszają inni, ale prawdopodobnie mniej niż jedna piąta poprawek pochodzi od osób spoza zespołu ds. Bezpieczeństwa.
— Joe Murray,

1
Moim zdaniem, jeśli potrzebujesz części swojego procesu, aby był prywatny, należy to zrobić poza GitHub (ponieważ GH jest publiczny); po zakończeniu tej konkretnej części i przejrzeniu jej kodu przez wszystkich; możesz utworzyć PR na GH, który zostanie scalony tak szybko, jak to możliwe, aby „powrócić” do oficjalnego procesu. Możesz użyć innego narzędzia do zarządzania tymi wyjątkami.
— Emerson Cardoso,

2
Pełne natychmiastowe ujawnienie (tj. Publiczne ujawnienie bez zwłoki) jest całkowicie uzasadnionym postępowaniem.
— Miles Rout,

1
Pytanie to wydaje się zakładać, że dopóki zespół nie ujawni problemu bezpieczeństwa, nie będzie on znany światu. To po prostu nieprawda; wszelkie wykryte problemy z bezpieczeństwem powinny być uznawane przez kogoś o złych zamiarach. Teraz, jeśli założysz, że ktoś już wie o tym problemie i może go wykorzystać, nie możesz dłużej odkładać wydania poprawki do czasu regularnej comiesięcznej wersji. Musisz zwolnić jak najszybciej. Oznacza to, że nie ma problemu z przestrzeganiem regularnego przepływu PR. Po prostu PR w stosunku do najnowszej gałęzi wydania, scalenia, tagowania, wydania.
— Jory Geerts,

Odpowiedzi:


1

Protokół służy do decydowania o czynnikach ryzyka w publicznym ujawnieniu podatności. W przypadku jakichkolwiek kwestii związanych z bezpieczeństwem te PR muszą znajdować się w prywatnym repozytorium, które może zobaczyć tylko Twój zespół ds. Bezpieczeństwa. To obowiązuje niezależnie od platformy, której używasz do tworzenia i realizacji zleceń ściągania.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.