Konfigurera GitHub Advanced Securitys inbyggda integration med Microsoft Defender för Moln

Den här guiden innehåller installationssteg och andra åtgärder som hjälper dig att integrera GitHub Advanced Security (GHAS) och Microsoft Defender för molnet med ett användningsfall som hjälper dig att verifiera integreringen från slutpunkt till slutpunkt. Den här integreringen hjälper till att maximera Microsofts molnbaserade programsäkerhet genom att korrelera körningsrisker och kontext med den ursprungliga koden för snabbare AI-baserad reparation.

Genom att följa den här guiden:

  • Konfigurera din GitHub lagringsplats för Defender för molnet-täckning.
  • Skapa en körningstidsriskfaktor.
  • Testa verkliga användningsfall i Defender för molnet.
  • Länka kod till resurser vid körning.
  • Starta en säkerhetskampanj på GitHub. Den här kampanjen använder körmiljö för att prioritera GHAS-säkerhetsaviseringar.
  • Skapa GitHub-ärenden från Defender för molnet för att initiera åtgärder.
  • Stäng loopen mellan teknik- och säkerhetsteam.

Förutsättningar

Aspekt Detaljer
Miljökrav – GitHub-konto med en anslutning som skapats i Defender för Molnet
- GitHub ADVANCED Security-licens (GHAS) på anslutna lagringsplatser
– Defender DCSPM-plan (Cloud Security Posture Management) aktiverad för prenumerationen
– Microsoft Security Copilot (valfritt för AI-baserad automatiserad reparation)
Roller och behörigheter – Behörigheter för säkerhetsadministratör
– Säkerhetsadministratör för Azure-prenumerationen (för att visa resultat i Defender för molnet)
– GitHub organisationsägare (för att ansluta lagringsplatser och konfigurera säkerhetskampanjer)
Molnmiljöer – Endast tillgängligt i kommersiella moln (inte i Azure Government, Azure som drivs av 21Vianet eller andra nationella moln)

Förbered din miljö

Steg 1: Konfigurera GitHub-lagringsplatsen och kör arbetsflödet

Om du vill testa integreringen använder du dina egna lagringsplatser eller ett exempel sandbox-projekt som har ett test GitHub lagringsplats med allt innehåll för att skapa en sårbar containeravbildning.

  1. Logga in på Azure-portalen.

  2. Gå till Microsoft Defender för molnet>DevOps-säkerhet.

  3. Ange namnet på din kodlagringsplats i sökfältet (exempel: zava-webshop).

  4. Kontrollera att den verkligen tillhör den organisation som du övervakar (exempel: zava-corporation org).

  5. Granska om det finns några resultat för koddatabasen.

  6. Kontrollera att Avancerad säkerhetsstatus är On, vilket indikerar att du har GitHub Advanced Security aktiverat på den övervakade lagringsplatsen > den registrerade lagringsplatsen.

  7. Om lagringsplatsen inte hittas kan du läsa Microsoft Defender för molnet dokumentation för felsökning och GitHub anslutningsregistrering.

  8. Kontrollera att agentlös genomsökning är aktiverat för din GitHub-anslutning.

    Skärmbild av plankonfiguration i Defender CSPM med agentlös kodgenomsökning aktiverad och alla skanneralternativ aktiverade.

Steg 2: Kontrollera att din miljö är redo

Verifieringen bekräftar att din miljö är korrekt konfigurerad för att visa kod för körningsrekommendationer och generera åtgärdsbara resultat. Under det här steget verifierar Defender att:

Fullständig kod för körningssynlighet

  • Microsoft Defender för molnet övervakar kontinuerligt lagringsplatser för källkod för säkerhetsrisker.
  • Byggartefakter, till exempel containeravbildningar, genomsöks i containerregister före distributionen.
  • Körningsarbetsbelastningar som distribueras till Kubernetes-kluster övervakas för säkerhetsrisker.
  • Defender för molnet korrelerar och spårar varje artefakt från kod, via kompilering och distribution, till körning och tillbaka.

Anmärkning

Det kan ta upp till 24 timmar efter att föregående steg har tillämpats för att se följande resultat.

Testa att GitHub agentlös genomsökning hämtar lagringsplatsen.

Gå till Microsoft Defender för molnet>Cloud Security Explorer och utför frågan. Valideringsfrågorna testar om Defender kan identifiera artefakter som produceras av dina pipelines och arbetsbelastningar. Om frågorna returnerar resultat anger det att genomsökning och korrelation fungerar som förväntat.

Skärmbild av Defender för molnet Cloud Security Explorer som visar en fråga för GitHub-lagringsplatsen skickar till containeravbildningar.

Anmärkning

Om inga resultat returneras kan det tyda på att artefakter ännu inte har genererats, att genomsökningen inte har konfigurerats eller att behörigheter saknas. Mer information finns i Användarroller och behörigheter .

  1. Verifiera att Defender för molnet (i Azure Container Registry) genomsökt containeravbildningen och använt den för att skapa en container.

  2. I frågan lägger du till villkoren för din specifika distribution.

    Skärmbild av Defender för molnet Cloud Security Explorer som visar en fråga för GitHub-lagringsplatsen skickar till containeravbildningar med sårbarheter.

  3. Kontrollera att containern körs och att Defender för molnet genomsökt AKS-klustret.

    Skärmbild av Defender för molnet:s

  4. Kontrollera att riskfaktorerna är korrekt konfigurerade på Defender för molnet-sidan. Sök efter ditt containernamn på sidan Defender för molninventering och du bör se det markerat som kritiskt.

Anmärkning

Det här steget krävs endast om riskfaktorer inte redan har konfigurerats i din miljö. Om du redan använder riskfaktorer kan du verifiera konfigurationen under Inställningar > Resurskritiskhet.

Lyckad validering säkerställer att efterföljande steg, till exempel rekommendationer, kampanjer och GitHub problemgenerering, ger meningsfulla resultat.

Anmärkning

När du har klassificerat resursen som kritisk kan det ta upp till 12 timmar innan Defender för molnet skickar data till GitHub. Läs mer.

Steg 3: Skapa en GitHub kampanj

Om du vill skapa en genomsökningskampanj måste du arbeta på GitHub organisationsnivå. Den här upplevelsen är inte tillgänglig på enskild lagringsplatsnivå.

  1. I GitHub går du till den GitHub organisation som du använde för konfigurationstestningen.

  2. VäljSäkerhetskampanjer>>Skapa kampanj>Från kodgenomsökningsfilter.

  3. Den här kampanjen hjälper till att prioritera GHAS-resultat som tillhör kod som verkligen distribueras och körs.

  4. Välj Filter för körningsrisker för kampanjen.

    Skärmbild av skapandet av en GitHub-kodgenomsökningskampanj med ett filterfält, filterknappen och en knappbeskrivning om filtrering efter artefaktmetadata.

    Skärmbild av dialogrutan avancerade filter i GitHub kampanjskapande med Runtime Risk-filter och menyn för valbara riskfaktorer öppen.

  5. Välj Spara>publicera som kampanj. Ange nödvändig information och publicera sedan kampanjen.

  6. Spåra kampanjframsteg. Skärmbild av GitHub kampanjsida som visar förfallen status, kampanjförloppsindikator, lista över kritiska aviseringar och filteralternativ.

Steg 4: Rekommendationer för mobilisering

Använd funktionen för att köra Containers VA-rekommendationers kod-till-körningsfunktionalitet och korrelationen mellan identifierade CVE:er och Dependabot-säkerhetsaviseringar för att få en överblick över säkerhetsproblemens status. Du kan sedan tilldela rekommendationen för lösning till relevant teknikteam baserat på kod-till-körning-mappning.

  1. I Defender för molnet-portalen går du till fliken Rekommendationer .

  2. Sök efter namnet på containern som du skapade från din kodlagringsplats.

  3. Öppna någon av rekommendationerna för uppdateringsprogramvaran . rekommendationsnamnet börjar med Uppdatera

  4. Välj fliken Associerade CVE:er Säkerhetsaviseringar visas som en del av rekommendationens utvärderingsflöde. Dessa aviseringar ger indikationer på GitHub Avancerad säkerhet som redan är kända för ingenjörsteamet. Observera att vissa CVE-ID:er har en länk för att Visa på GitHub i kolumnen Relaterade GitHub-varningar.

    Skärmbild av fliken Defender för molnet Resultat som visar CVE-2024-21409-aviseringar, korrigeringsstatus, CVSS-poäng och GitHub aviseringsinformation popup.

Välj länken för att öppna relevant GHAS-säkerhetsavisering. (Om du vill visa GHAS-aviseringsinnehållet i GitHub måste du ha åtkomstbehörighet till relevant GitHub lagringsplats. Om du inte har åtkomstbehörighet kan du alltid kopiera länken för senare användning eller kontakta din GitHub administratör.)

Om det finns en aviseringsberikning finns det en matchad Dependabot-avisering som redan är känd för utveckling. Om statusen är Aktiv har ingen åtgärdat den ännu, och problemet måste prioriteras för en korrigering.

Om det inte finns någon berikning anger detta en körningsrisk som är okänd för teknik som måste prioriteras för en korrigering.

Vad händer härnäst? Hur vet jag vilket som är det relevanta teamet för åtgärden? Hur skulle jag veta vilket sammanhang som kan hjälpa ingenjörerna med att lösa problemet?

Skapa ett GitHub problem

Om du vill stänga loopen mellan säkerhets- och teknikteam kan du skapa ett GitHub problem som prioriterar de säkerhetsproblem som teknikteamet bör fokusera på. Den här prioriteringen kan omfatta att överföra resultat som GHAS inte upptäckte men som Defender för molnet identifierade för CVE-ID:er som inte ingår i direkta beroenden. Dessa resultat kan omfatta sårbarheter i basavbildningen, operativsystemet eller programvara som NGINX.

GitHub-ärendet genereras automatiskt på kodrepo vid ursprung, med alla CVE-ID:er som finns i rekommendationens omfång, inklusive andra runtime- och kontexter relaterade till container-SDLC som kan underlätta att åtgärda och testa.

Från rekommendationsvyn kan du uttryckligen generera ett GitHub problem för att spåra reparationsarbete.

  1. Gå till fliken Remediation Insights och visa diagrammet code-to-runtime. Diagrammet mappar din körande container till containerbilden i kodarkivet och till kodens ursprungliga lagringsplats i GitHub.

    Skärmbild av Remediation Insights som visar kod-till-körningsdiagram med risknivåer och menyn Vidta åtgärd öppen i rutan Körning.

    1. På fliken Remediation Insights granskar du den påverkade Runtime-rutan.

    2. Validera om det redan finns ett GitHub problem. Om det redan finns ett GitHub problem visas en GitHub-ikon i rutan. Hovra över ikonen för att visa probleminformation.

    3. Om det inte finns något problem och du har de behörigheter som krävs kan du generera ett nytt GitHub problem. Välj Gör något.

    4. Välj alternativet Generera GitHub-ärende i popupmenyn.

    5. Om ärendet skapades framgångsrikt kommer du att se ett popup-meddelande med en länk till ärendet. Problemet skapas i ursprungslagringsplatsen för kod.

      Skärmbild av GitHub problemlista som visar öppna problem för beroenden med etiketter som Defender för molnet och security.

    Anmärkning

    Om Generate GitHub problemalternativet inte är tillgängligt, kanske nödvändiga GitHub eller lagringsplatsbehörigheter saknas. Kontakta din GitHub- eller lagringsplatsadministratör för att begära åtkomst.

    Skärmbild av GitHub problemlista som visar öppna problem för beroenden med etiketter som Defender för molnet och security.

    1. Track ownership and status updates – ändringar av ärendestatus eller tilldelning som gjorts i GitHub återspeglas i Microsoft Defender för molnet, så att du kan spåra ägarskaps- och åtgärdsförloppet från vyn Recommendations.

      Skärmbild av sidan Microsoft Defender för molnet Rekommendationer som visar högriskproblem med GitHub-problemdetaljer-popup.

Göra agentiska korrigeringar

Om du har en GitHub Copilot licens på GitHub sidan kan du lösa problemet med hjälp av GitHub kodningsagenten:

  1. Tilldela ett GitHub kodningsagent till problemet.
  2. Granska den genererade korrigeringen.
  3. Om korrigeringen verkar rimlig, tillämpa den.
  4. Observera när Defender för molnet uppdaterar problemstatusen till Stängd.

Relaterat innehåll

  • Last updated on