Jak zachować bezpieczne repozytorium GitHub

Ukończone

W tym miejscu omówimy niektóre podstawowe narzędzia i techniki zabezpieczeń dostępne dla administratorów repozytorium GitHub.

Notatka

Poniższa zawartość nie obejmuje podstaw pisania bezpiecznego kodu, ale raczej ważnych zagadnień dotyczących zabezpieczeń, narzędzi i funkcji do użycia w repozytorium GitHub.

Znaczenie bezpiecznej strategii rozwoju

Bezpieczeństwo aplikacji jest ważne. Usługi informacyjne często opowiadają o naruszeniu systemów firmy i prywatnych danych firmowych i klientów, które zostały skradzione.

Jakie są więc problemy, które należy wziąć pod uwagę podczas planowania bezpiecznej strategii rozwoju? Oczywiście musimy chronić informacje przed ujawnieniem osobom, które nie powinny mieć do niego dostępu, ale co ważniejsze, musimy zapewnić, że informacje są zmieniane lub niszczone tylko wtedy, gdy są one odpowiednie.

Musimy upewnić się, że prawidłowo uwierzytelniamy, kto uzyskuje dostęp do danych i że mają odpowiednie uprawnienia do tego celu. Za pomocą danych historycznych lub archiwalnych lub dzienników musimy znaleźć dowody, gdy coś jest nie tak.

Istnieje wiele aspektów tworzenia i wdrażania bezpiecznych aplikacji. Oto trzy kwestie, które należy wziąć pod uwagę:

• Istnieje ogólny problem z wiedzą: wielu deweloperów i innych pracowników zakłada, że rozumieją bezpieczeństwo, ale nie. Cyberbezpieczeństwo to stale rozwijająca się dyscyplina. Niezbędny jest program edukacji i szkoleń.

• Kod musi zostać utworzony poprawnie i bezpiecznie: musimy mieć pewność, że kod został utworzony poprawnie i bezpiecznie implementuje wymagane funkcje. Musimy również upewnić się, że funkcje zostały zaprojektowane z myślą o zabezpieczeniach.

• Aplikacje muszą być zgodne z regułami i przepisami: musimy upewnić się, że kod jest zgodny z wymaganymi regułami i przepisami. Musimy przetestować zgodność podczas kompilowania kodu, a następnie okresowo testować, nawet po wdrożeniu.

Zabezpieczenia na każdym kroku

Zabezpieczenia nie są czymś, co można dodać później do aplikacji lub systemu. Bezpieczne programowanie musi być częścią każdego etapu cyklu życia tworzenia oprogramowania. Ta koncepcja jest jeszcze ważniejsza w przypadku krytycznych aplikacji i aplikacji, które przetwarzają poufne lub wysoce poufne informacje.

W praktyce, aby trzymać zespoły do odpowiedzialności za to, co opracowują, procesy muszą przesunięcie w lewolub zostać ukończone wcześniej w cyklu projektowania. Przenosząc kroki z ostatniej bramy w czasie wdrażania do wcześniejszego kroku, mniejsza liczba błędów jest popełniana, a deweloperzy mogą szybciej przechodzić.

Pojęcia dotyczące zabezpieczeń aplikacji nie były przedmiotem zainteresowania deweloperów w przeszłości. Oprócz kwestii edukacyjnych i szkoleniowych, wynika to z faktu, że ich organizacje podkreślały szybki rozwój funkcji.

Wraz z wprowadzeniem praktyk DevOps testowanie zabezpieczeń jest jednak łatwiejsze do zintegrowania z ciągiem DevOps. Zamiast być zadaniem wykonywanym przez specjalistów ds. zabezpieczeń, testowanie zabezpieczeń powinno być tylko częścią codziennych procesów dostarczania.

Ogólnie rzecz biorąc, gdy czas ponownej pracy jest brany pod uwagę, dodanie zabezpieczeń do praktyk DevOps wcześniej w cyklu życia programowania umożliwia zespołom deweloperów przechwytywanie problemów wcześniej. Wcześniejsze przechwytywanie problemów może skrócić całkowity czas opracowywania oprogramowania o jakości.

Przesunięcie w lewo to zmiana procesu, ale nie jest to pojedyncze narzędzie ani kontrolka. Chodzi o to, aby wszystkie zabezpieczenia były bardziej skoncentrowane na deweloperach i dostarczały deweloperom informacje zwrotne dotyczące zabezpieczeń tam, gdzie pracują.

Funkcje zakładki zabezpieczeń

Usługa GitHub oferuje funkcje zabezpieczeń, które pomagają zapewnić bezpieczeństwo danych w repozytoriach i organizacjach. Aby znaleźć kartę zabezpieczeń:

1. Na GitHub.com przejdź do strony głównej repozytorium.

2. Pod nazwą repozytorium wybierz pozycję Security.

Na karcie Zabezpieczenia możesz dodawać funkcje do przepływu pracy usługi GitHub, aby uniknąć luk w zabezpieczeniach w repozytorium i bazie kodu. Te funkcje obejmują:

• zasady zabezpieczeń, które umożliwiają określenie sposobu zgłaszania luk w zabezpieczeniach w projekcie przez dodanie pliku SECURITY.md do repozytorium.
• Alerty Dependabot, które powiadamiają cię, gdy GitHub wykryje, że twoje repozytorium korzysta z podatnej zależności lub złośliwego oprogramowania.
• Porady dotyczące bezpieczeństwa, których można użyć do prywatnego omawiania, rozwiązywania i publikowania informacji o lukach w zabezpieczeniach w repozytorium.
• Skanowanie kodu, które ułatwia znajdowanie, klasyfikowanie i naprawianie luk i błędów w kodzie.

Aby uzyskać więcej informacji, zobacz funkcje zabezpieczeń GitHub.

Notatka

Alerty Dependabot dotyczące złośliwego oprogramowania są obecnie w wersji beta i mogą ulec zmianie. Tylko poradniki, które zostały przejrzane przez GitHub, wyzwolą alerty Dependabot.

Następnie zapoznamy się z niektórymi z tych funkcji i poznamy sposoby dystrybucji obowiązków związanych z zabezpieczeniami i operacjami we wszystkich fazach cyklu życia tworzenia oprogramowania.

Komunikowanie zasad zabezpieczeń za pomocą SECURITY.md

Korzyści społeczności usługi GitHub są istotne, ale również niosą ze sobą potencjalne zagrożenia. Fakt, że każdy może zaproponować poprawki błędów publicznie pochodzi z pewnych obowiązków. Najważniejsze jest odpowiedzialne ujawnienie informacji, które mogłyby prowadzić do luk w zabezpieczeniach przed naprawieniem ich podstawowych usterek. Deweloperzy, którzy chcą zgłaszać lub rozwiązywać problemy z zabezpieczeniami, szukają pliku SECURITY.md w katalogu głównym repozytorium, aby odpowiedzialnie ujawnić swoje obawy. Dostarczanie wskazówek w tym pliku ostatecznie przyspiesza rozwiązywanie tych krytycznych problemów.

Aby dowiedzieć się więcej o SECURITY.md, zobacz Dodawanie zasad zabezpieczeń do repozytorium.

Poradniki bezpieczeństwa GitHub

Porady dotyczące zabezpieczeń GitHub umożliwiają konserwatorom repozytorium prywatne omawianie i naprawianie luki w zabezpieczeniach w projekcie. Gdy osoby odpowiedzialne za repozytorium współpracują nad poprawką, mogą publikować porady dotyczące zabezpieczeń, aby publicznie ujawnić lukę w zabezpieczeniach społeczności projektu. Publikując biuletyny zabezpieczeń, osoby odpowiedzialne za repozytorium ułatwiają społeczności aktualizowanie zależności pakietów i badanie konsekwencji luk w zabezpieczeniach. GitHub przechowuje opublikowane ostrzeżenia w ramach listy Common Vulnerabilities and Exposures (CVE). Ta lista jest używana do automatycznego powiadamiania repozytoriów, których dotyczy problem, korzystających z oprogramowania, które ma wymienioną lukę w zabezpieczeniach. Aby uzyskać więcej informacji, zobacz Informacje o biuletynach zabezpieczeń repozytorium.

Przechowywanie poufnych plików poza repozytorium za pomocą polecenia .gitignore

Deweloperzy mogą łatwo przeoczyć pliki zawarte w zatwierdzeniu. Czasami te pomijane pliki są nieszkodliwe, takie jak pliki pośrednie kompilacji. Jednak zawsze istnieje ryzyko, że ktoś może przypadkowo zatwierdzić poufne dane. Na przykład ktoś może zatwierdzić klucz interfejsu API lub prywatne dane konfiguracji, których może użyć złośliwy aktor. Jedną z technik, które pomagają uniknąć tego ryzyka, jest tworzenie i utrzymywanie .gitignore plików. Te pliki instruują narzędzia klienckie, takie jak narzędzie wiersza polecenia git, aby ignorować ścieżki i wzorce podczas agregowania plików dla zatwierdzenia.

Poniższy przykład ilustruje niektóre typowe scenariusze użycia do ignorowania plików.

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Repozytorium może zawierać wiele plików .gitignore. Ustawienia są dziedziczone z katalogów nadrzędnych, ale gdy w nowych plikach .gitignore znajdują się pola zastępujące, mają one pierwszeństwo przed ustawieniami nadrzędnymi w odniesieniu do ich folderów i podfolderów. Utrzymanie pliku .gitignore w katalogu głównym wymaga znacznego wysiłku, chociaż dodanie pliku .gitignore do katalogu projektu może być przydatne, gdy ten projekt ma określone wymagania, które są łatwiejsze do utrzymania oddzielnie od katalogu nadrzędnego, takie jak pliki, które powinny nie być ignorowane.

Aby dowiedzieć się więcej o .gitignore, zobacz Ignorowanie plików. Zapoznaj się również z kolekcją plików startowych .gitignore oferowanych dla różnych platform w repozytorium gitignore .

Usuwanie poufnych danych z repozytorium

Chociaż pliki .gitignore mogą być przydatne w pomaganiu współautorom w unikaniu zatwierdzania poufnych danych, jest to tylko silna sugestia. Deweloperzy mogą nadal obejść ten proces, aby dodać pliki, jeśli są wystarczająco zmotywowani, a czasami pliki mogą przejść niezauważone, ponieważ nie spełniają konfiguracji plików .gitignore. Uczestnicy projektu zawsze powinni znajdować się w poszukiwaniu zatwierdzeń zawierających dane, które nie powinny być uwzględnione w repozytorium ani jego historii.

Ważny

Należy założyć, że wszystkie dane zatwierdzone w usłudze GitHub w dowolnym momencie zostały naruszone. Po prostu zastąpienie zatwierdzenia nie wystarczy, aby mieć pewność, że dane nie będą dostępne w przyszłości. Aby uzyskać pełny przewodnik dotyczący usuwania poufnych danych z usługi GitHub, zobacz Usuwanie poufnych danych z repozytorium.

Reguły ochrony gałęzi

Możesz utworzyć regułę ochrony gałęzi , aby wymusić określone procesy robocze dla co najmniej jednej gałęzi. Na przykład można wymagać zatwierdzającej recenzji lub zdania kontroli stanu dla wszystkich pull requestów scalanych z chronioną gałęzią.

Możesz użyć przepływów pracy, które chronią gałąź, aby:

• Uruchamianie kompilacji w celu sprawdzenia, czy można skompilować zmiany kodu
• Uruchom linter, aby sprawdzić pisownię i zgodność z wewnętrznymi konwencjami kodowania
• Uruchamianie testów automatycznych w celu sprawdzenia, czy nie wprowadzono zmian zachowania kodu
• I tak dalej

Dodaj plik CODEOWNERS

Dodając plik CODEOWNERS do repozytorium, możesz przypisać poszczególnych członków zespołu lub całe zespoły jako właścicieli kodu do ścieżek w repozytorium. Ci właściciele kodu są następnie zobowiązani do przeglądów żądań ściągnięcia na wszelkie zmiany w plikach w ścieżce, dla której są skonfigurowane.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Plik CODEOWNERS można utworzyć w katalogu głównym repozytorium lub w folderze docs lub .github.