Distribuera integration av GitHub Advanced Security

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 och sedan verifiera integreringen från slutpunkt till slutpunkt. Integreringen hjälper till att maximera Microsoft molnbaserade programsäkerhet genom att korrelera körningsrisker och kontext med ursprungskoden 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

Aspect	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ö

Genomför följande steg för att konfigurera ditt GitHub-arkiv och Defender för molnet-inställningar innan du validerar integrationen.

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

För att testa integrationen, använd dina egna arkiv eller ett exempel på sandlådeprojekt. Sandlådeprojektet tillhandahåller ett test-GitHub-repository med allt du behöver för att bygga en sårbar containerimage.

Logga in på Azure-portalen.
Gå till Microsoft Defender för molnet>DevOps-säkerhet.
Ange namnet på din kodlagringsplats i sökfältet (exempel: zava-webshop).
Kontrollera att den tillhör den organisation som du övervakar, till exempel zava-corporation-organisationen .
Granska om det finns några resultat för koddatabasen.
Se till att Avancerad säkerhetsstatus är På. Detta anger att GitHub Advanced Security är aktiverat på den övervakade lagringsplatsen.
Om ditt repository inte hittas, se GitHub Connector onboarding quickstart för felsökning och installation.
Kontrollera att agentlös genomsökning är aktiverat för din GitHub-anslutning.

Steg 2: Kontrollera att din miljö är redo

Denna miljövalidering bekräftar att ditt repository och molnresurser är korrekt inställda. Den kontrollerar att Defender kan visa rekommendationer från kod till körtid och ge användbara resultat. Under valideringssteget i miljön verifierar Defender att:

Validera full kod-till-körningstid-synlighet

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.

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 .

Verifiera att Defender för molnet (i Azure Container Registry) genomsökt containeravbildningen och använt den för att skapa en container.
I frågan lägger du till villkoren för din specifika distribution.
Kontrollera att containern körs och att Defender för molnet genomsökt AKS-klustret.
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 nästa 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. Förstå varningar i produktionskod.

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å.

I GitHub går du till den GitHub-organisation som du använde för konfigurationstestningen.
VäljSäkerhetskampanjer>>Skapa kampanj>Från kodgenomsökningsfilter.
Runtime-riskkampanjen hjälper till att prioritera GitHub Advanced Security (GHAS)-fynd som tillhör kod som verkligen är distribuerad och igång.
Välj Filter för körningsrisker för kampanjen.
Välj Spara>publicera som kampanj. Ange nödvändig information och publicera sedan kampanjen.
Spåra kampanjframsteg.

Steg 4: Agera på rekommendationerna

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.

I Defender för molnet-portalen går du till fliken Rekommendationer .
Sök efter namnet på containern som du skapade från din kodlagringsplats.
Öppna någon av rekommendationerna för uppdateringsprogramvaran . rekommendationsnamnet börjar med Uppdatera
Välj fliken Associerade CVE:er Säkerhetsaviseringar visas som en del av rekommendationens utvärderingsflöde. Dessa aviseringar visar vilka identifierade säkerhetsproblem i GitHub Advanced Security som redan är kända för utvecklingsteamet. Observera att vissa CVE-ID:er har en länk för att Visa på GitHub i kolumnen Relaterade GitHub-varningar.

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örigheter kan du alltid kopiera länken för nästa användning eller kontakta din GitHub administratör.)

Om kolumnen Relaterade GitHub Alerts visar en matchad Dependabot-varning är sårbarheten redan känd för ingenjörerna. Om varningsstatusen är Aktiv har ingen fixat det än, och problemet måste prioriteras för en fix.

Om ingen matchande GitHub-varning visas i kolumnen representerar CVE en körtidsrisk som är okänd för ingenjörerna och som måste prioriteras för en fix.

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

För att 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 i källkodsförrådet med alla CVE-ID:n som hittas inom rekommendationens omfattning, inklusive andra sammanhang relaterade till runtime, containrar och SDLC som kan hjälpa till vid åtgärd och testning.

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

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.
1. På fliken Remediation Insights granskar du den berörda 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.
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.
1. Spåra ägarskap och statusuppdateringar – ändringar i problemstatus eller tilldelning som görs i GitHub återspeglas i Microsoft Defender för molnet, så att du kan spåra ägarskap och åtgärdsförlopp i vyn Recommendations.