Zarządzanie funkcjami i alertami usługi GitHub Advanced Security

Teraz, po skonfigurowaniu zabezpieczeń projektu, wystarczy monitorować funkcje i alerty usługi Advanced Security GitHub oraz zarządzać nimi.

W tej lekcji dowiesz się, jak monitorować zagrożenia bezpieczeństwa w projekcie przy użyciu przeglądu zabezpieczeń . Dowiesz się również, jak używać punktów końcowych GitHub Advanced Security do zarządzania funkcjami zabezpieczeń i alertami.

Korzystaj z omówienia zabezpieczeń

Przegląd zabezpieczeń jest dostępny na karcie Zabezpieczenia i jakość dla organizacji i repozytoriów. Można go użyć, aby uzyskać ogólny widok stanu zabezpieczeń organizacji lub zidentyfikować repozytoria, które wymagają uwagi.

• Poziom organizacji: Przedstawia zagregowane i specyficzne dla repozytoriów informacje o zabezpieczeniach dla repozytoriów należących do organizacji. Informacje można również filtrować według funkcji zabezpieczeń.
• Poziom zespołu: Wyświetla informacje o zabezpieczeniach specyficzne dla repozytoriów, w których zespół ma uprawnienia administratora.
• Poziom repozytorium: Pokazuje, które funkcje zabezpieczeń są włączone dla repozytorium i udostępnia opcje konfigurowania dostępnych funkcji, które nie są obecnie włączone.

Dzięki swoim interaktywnym interfejsom i możliwościom filtrowania przegląd zabezpieczeń obsługuje zarówno szeroką, jak i docelową analizę zabezpieczeń.

Na przykład można go użyć do:

• Monitorowanie wdrażania funkcji zabezpieczeń w całej organizacji.
• Śledzenie wdrażania przez poszczególne zespoły podczas wdrażania GitHub Advanced Security.
• Przejrzyj alerty określonego typu lub poziomu ważności we wszystkich repozytoriach.

Korzystanie z punktów końcowych zabezpieczeń zaawansowanych GitHub

Poniższa tabela zawiera podsumowanie dostępnych punktów końcowych interfejsu API dla każdej funkcji zabezpieczeń zaawansowanych GitHub.

Skonfiguruj uprawnienia GITHUB_TOKEN

Jeśli używasz GitHub Actions do automatyzacji przepływów pracy związanych z bezpieczeństwem, ważne jest skonfigurowanie uprawnień przyznanych elementowi GITHUB_TOKEN, używanemu do uwierzytelnionych wywołań API.

Poniższa tabela zawiera podsumowanie domyślnych uprawnień.

Możesz zmodyfikować uprawnienia przyznane GITHUB_TOKEN w poszczególnych plikach przepływu pracy.

• Jeśli uprawnienia domyślne są restrykcyjne, może być konieczne zwiększenie uprawnień, aby przepływy pracy mogły zakończyć się pomyślnie.
• Jeśli uprawnienia domyślne są permissive, należy usunąć niepotrzebne uprawnienia.

Najlepszym rozwiązaniem w zakresie zabezpieczeń jest zawsze przyznawanie najniższych wymaganych uprawnień .

Możesz również użyć permissions klucza, aby skonfigurować uprawnienia dla całego przepływu pracy lub poszczególnych zadań. Gdy określono permissions, wszystkie nieokreślone uprawnienia są ustawiane na none, z wyjątkiem zakresu metadata, który zawsze ma dostęp read.

name: Create issue on commit

on:
  - push

jobs:
  create_commit:
    runs-on: ubuntu-latest
    permissions:
      issues: write

    steps:
      - name: Create issue using REST API
        run: |
          curl --request POST \
            --url http(s)://[hostname]/api/v3/repos/${{ github.repository }}/issues \
            --header 'authorization: Bearer ${{ secrets.GITHUB_TOKEN }}' \
            --header 'content-type: application/json' \
            --data '{
              "title": "Automated issue for commit: ${{ github.sha }}",
              "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**.\n\nThe commit hash was: _${{ github.sha }}_."
            }' \
            --fail

W poprzednim przykładzie dostęp do zapisu jest przyznawany zakresowi problemów dla pojedynczego zadania.

Możesz również użyć klawisza permissions, aby dodać lub usunąć uprawnienia do odczytu dla przepływów pracy uruchamianych z repozytoriów rozwidlonych. Zazwyczaj nie można przyznać uprawnień do zapisu, chyba że w ustawieniach usługi GitHub Actions jest włączona opcja Wyślij tokeny z uprawnieniami do zapisu do przepływów pracy z żądań pull request.

Widoki wykrywania, naprawy i zapobiegania

Przegląd zabezpieczeń organizuje wgląd w trzy widoki podstawowe.

Widok Zapobieganie pomaga organizacjom ocenić, jak skutecznie mechanizmy kontroli zabezpieczeń zatrzymują ryzykowne zmiany przed ich scaleniem.

Oto kilka przykładów:

• Luki w zabezpieczeniach naprawione w trakcie przeglądu pull requestu.
• Problemy wykryte podczas skanowania kodu naprawiono przed scaleniem.
• Działanie naprawcze funkcji Copilot Autofix.
• Zdarzenia ochrony wypychania skanowania wpisów tajnych.
• Zapobieganie zagrożeniom zależności.

Interpretowanie alertów między funkcjami zabezpieczeń

Przegląd zabezpieczeń agreguje informacje z wielu funkcji zabezpieczeń GitHub, aby ułatwić zespołom zrozumienie ryzyka organizacyjnego.

Typowe źródła alertów obejmują:

• Alerty skanowania kodu: Luki w zabezpieczeniach i niezabezpieczone wzorce kodowania wykryte przez skanery CodeQL lub innych firm.
• Alerty skanowania sekretów: Ujawnione poświadczenia, klucze interfejsu API i tokeny.
• Alerty Dependabot: Podatne zależności i ryzyka związane z pakietami.
• Przegląd zależności: Zagrożenia wynikające ze zmian zależności w pull requestach.

Zespoły mogą filtrować alerty według:

• Severity
• Repozytorium
• Typ funkcji
• Zakres czasu
• Odpowiedzialność zespołu
• Stan alertu

Te filtry obsługują zarówno analizę w całej organizacji, jak i ukierunkowane badania.

Śledzenie działań naprawczych i informacje o automatycznych poprawkach

Omówienie zabezpieczeń pomaga również monitorować postęp korygowania.

Zespoły ds. zabezpieczeń mogą śledzić:

• Alerty pull requestów naprawione przed scaleniem.
• Trendy działań naprawczych.
• Żądania ściągnięcia wygenerowane przez Copilot Autofix.
• Współczynniki zakończenia walidacji i scalania.
• Repozytoria z cyklicznymi nierozwiązanymi alertami.

Te szczegółowe informacje ułatwiają organizacjom identyfikowanie wąskich gardeł, określanie priorytetów repozytoriów wysokiego ryzyka i mierzenie skuteczności korygowania.

Wgląd w zdarzenia obejścia i sygnały nadzoru

Przegląd zabezpieczeń zawiera również metryki ładu i zasad w całej organizacji.

Oto kilka przykładów:

• Zdarzenia ominięcia ochrony push.
• Aktywność egzekwowania ochrony gałęzi.
• Trendy odrzucania alertów.
• Aktywność dziennika audytu.
• Metryki stosowania zasad i ich zakresu.

Te metryki pomagają administratorom zrozumieć:

• Gdzie użytkownicy pomijają zabezpieczenia.
• Czy zasady wymagają uściślenia.
• Czy mechanizmy kontroli zabezpieczeń są stale wymuszane.

W połączeniu z dziennikami inspekcji, zestawami reguł i zasadami ochrony gałęzi te szczegółowe informacje obsługują raportowanie zgodności, przeglądy operacyjne i ciągłe ulepszanie zabezpieczeń.

Role i obowiązki zabezpieczeń

Pomyślne wdrożenie GitHub Advanced Security wymaga jasno określonego zakresu odpowiedzialności w zespołach programistycznych, bezpieczeństwa i administracyjnych.

Różne role korzystają z funkcji GitHub Advanced Security w całym cyklu życia tworzenia oprogramowania i reagowania na incydenty.

Przykładowa własność przepływu pracy

Typowy przepływ pracy GitHub Advanced Security obejmuje wiele ról, które współpracują ze sobą.

1. Deweloper otrzymuje alert dotyczący skanowania kodu w pull requeście.
2. Inżynier zabezpieczeń przegląda ważność alertu i zaleca podejście korygujące.
3. Copilot Autofix sugeruje aktualizację pull requestu.
4. Deweloper weryfikuje poprawkę i aktualizuje kod w razie potrzeby.
5. Administratorzy repozytorium wymuszają ochronę gałęzi i wymagane kontrole przed scaleniem.
6. Zespoły ds. zabezpieczeń przeglądają dzienniki inspekcji i trendy korygowania za pomocą przeglądu zabezpieczeń.

Jasne określenie zakresu odpowiedzialności pomaga organizacjom skalować wdrażanie rozwiązania GitHub Advanced Security przy jednoczesnym zachowaniu ładu, odpowiedzialności i spójności operacyjnej.