De flesta repo-problem börjar inte med ett dramatiskt intrång. De börjar med ett litet ”vem gjorde det?”-ögonblick: en okänd push, en ny medlem som läggs till eller att ett repo i tysthet växlas till publikt.
IT-chefer dras in i incidentläge. Engineering leads fastnar i att skanna loggar. Och en grundare vill bara veta att verksamheten inte är exponerad. Den här automatiseringen för GitHub Slack-varningar håller dig uppdaterad utan att göra Slack till en brandslang.
Du sätter upp ett flöde som kontrollerar specifika högriskhändelser i GitHub mot en whitelist, och pingar Slack bara när åtgärden ser obehörig ut. Ren signal. Snabb respons.
Så fungerar automatiseringen
Här är hela arbetsflödet som du kommer att sätta upp:
n8n Workflow Template: GitHub-varningar till Slack vid riskabla ändringar
flowchart LR
subgraph sg0["Schedule Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Schedule", pos: "b", h: 48 }
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>Filter Member Events"]
n2@{ icon: "mdi:cog", form: "rounded", label: "Check Whitelist", pos: "b", h: 48 }
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Github Events (HTTP)"]
n4@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Switch", pos: "b", h: 48 }
n5@{ icon: "mdi:swap-horizontal", form: "rounded", label: "PublicEvent", pos: "b", h: 48 }
n6@{ icon: "mdi:swap-horizontal", form: "rounded", label: "PushEvent", pos: "b", h: 48 }
n7@{ icon: "mdi:swap-horizontal", form: "rounded", label: "MemberEvent", pos: "b", h: 48 }
n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/slack.svg' width='40' height='40' /></div><br/>Push Event Alert"]
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/slack.svg' width='40' height='40' /></div><br/>Public Event Alert"]
n10["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/slack.svg' width='40' height='40' /></div><br/>Member Event Alert"]
n11@{ icon: "mdi:cog", form: "rounded", label: "No Operation, do nothing", pos: "b", h: 48 }
n4 --> n7
n4 --> n5
n4 --> n6
n0 --> n3
n6 --> n8
n6 --> n11
n7 --> n10
n5 --> n9
n2 --> n4
n1 --> n2
n3 --> n1
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n4,n5,n6,n7 decision
class n3 api
class n1 code
classDef customIcon fill:none,stroke:none
class n1,n3,n8,n9,n10 customIcon
Varför det här är viktigt: riskfyllda GitHub-ändringar går obemärkt förbi
GitHub är upptaget av design. Många pushes, många händelser, mycket ”normal” brus. Problemet är att verkligt riskfyllda åtgärder ofta ser ut som normal aktivitet tills du zoomar in på vem som gjorde det och vad som ändrades. En ny org-medlem läggs till sent en fredag. Ett repo blir publikt under en stressig config-uppdatering. Eller så pushar ett obekant konto kod till en kritisk branch och ingen ser det förrän nästa deploy skapar fel (eller ännu värre, hemligheter läcker). När du väl upptäcker det är du redan i städ-och-sanera-läge.
Det eskalerar snabbt. Så här faller det isär i verkliga team.
- Du blir beroende av manuell loggkontroll, vilket sällan sker i tid eller konsekvent.
- Generiska GitHub-notiser skapar larmtrötthet, så viktiga händelser ignoreras tillsammans med allt annat.
- Utan en enkel whitelist kan du inte snabbt skilja på ”push från känd utvecklare” och ”push från okänd aktör”.
- När ett repo blir publikt räknas minuter, men upptäckten kommer oftast timmar senare.
Vad du bygger: Slack-varningar bara för obehöriga GitHub-händelser
Det här flödet körs på ett tidsstyrt schema och hämtar nyliga GitHub-händelser för ett repository via en HTTP-förfrågan. I stället för att vidarebefordra allt filtrerar det ner till händelsetyper som ofta signalerar risk: pushes, medlemsändringar och att repos görs publika. För varje händelse som passerar filtret plockar flödet ut aktörens GitHub-användarnamn och kontrollerar det mot en enkel whitelist-tabell (med användarnamn och roller). Därefter skickas varje händelse genom rätt valideringsregel: pushes måste komma från kända användare, medan medlems-/publika händelser måste göras av administratörer. Om åtgärden inte blir godkänd av valideringen postar flödet ett tydligt Slack-meddelande med händelsetyp, aktör och repodetaljer. Om den blir godkänd gör flödet ingenting och går vidare.
Flödet startar med schemalagd övervakning. Sedan snävar det in till högriskhändelser, kontrollerar vem som utförde dem och först därefter avgör det om Slack ska notifieras. Resultatet blir ett litet antal varningar du faktiskt kan lita på.
Det här bygger du
| Vad som automatiseras | Vad du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att du ansvarar för ungefär 10 repos och gör en snabb manuell kontroll två gånger per dag. Även om varje kontroll bara tar 10 minuter är det cirka 20 minuter dagligen, plus alla ”något ser konstigt ut”-sidospår. Med det här flödet är den enda tiden du lägger när Slack varnar dig, och de flesta team ser bara några få meningsfulla ping per vecka. Du går från rutinmässig kontroll till riktad granskning, vilket brukar ge dig cirka 2 timmar tillbaka varje vecka.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
- GitHub för att hämta repo-händelser via API.
- Slack för att posta varningar i en vald kanal.
- GitHub Personal Access Token (skapa den i GitHub Developer settings)
Kunskapsnivå: Nybörjare. Du kopplar konton, skapar en enkel whitelist-tabell och justerar ett par regler.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
En tidsstyrd trigger kör kontrollen. Enligt ett schema du väljer startar n8n flödet och begär nyliga GitHub-händelser via GitHub API (via en HTTP Request-nod).
Riskfyllda händelsetyper isoleras. Ett filtreringssteg håller flödet fokuserat på PushEvent, MemberEvent och PublicEvent, så att du inte utvärderar varje enskild aktivitet med lågt värde.
Varje åtgärd valideras mot din whitelist. Flödet slår upp aktören i en intern datatabell som heter it_whitelist, routar händelsen efter typ och tillämpar sedan rätt regel: pushes måste komma från kända användare, medan medlems-/publika ändringar måste göras av administratörer.
Slack får bara ögonblicken som ”kräver uppmärksamhet”. Om valideringen inte blir godkänd postar n8n en varning till Slack med nyckeldetaljerna. Om den blir godkänd avslutas flödet tyst via ett no-op-steg.
Du kan enkelt ändra whitelist-rollerna så att de matchar din org-struktur efter behov. Se hela implementationsguiden nedan för alternativ för anpassning.
Steg-för-steg-guide för implementering
Steg 1: Konfigurera den schemalagda triggern
Ställ in arbetsflödet så att det pollar GitHub-händelser enligt ett återkommande schema med triggernoden.
- Lägg till noden Timed Trigger som arbetsflödets trigger.
- Ställ in Rule-intervallet på
hoursför att köra varje timme. - Lämna övriga fält på standardvärden om ni inte behöver en annan pollingfrekvens.
Steg 2: Anslut GitHub och hämta repository-händelser
Konfigurera GitHub API-anropet som hämtar nyligen inträffade repository-händelser för analys.
- Lägg till noden GitHub Events Request och anslut den till Timed Trigger.
- Ställ in URL till
https://api.github.com/repos/./ /events - Aktivera Send Headers och lägg till headers: Accept =
application/vnd.github+jsonoch X-GitHub-Api-Version =2022-11-28. - Inloggningsuppgifter krävs: Anslut era githubApi-inloggningsuppgifter.
Steg 3: Filtrera riskhändelser och slå upp tillåtna användare
Filtrera händelsetyper för att fokusera på säkerhetsrelevanta åtgärder och verifiera aktörer mot er tillåtelselista.
- Lägg till Filter Risk Events och anslut den till GitHub Events Request.
- Behåll JS Code som den är för att filtrera kritiska händelser som
MemberEvent,PublicEvent,TeamAddEventochPushEvent. - Lägg till Lookup Allowed Users och anslut den till Filter Risk Events.
- Ställ in Operation på
getoch Data Table på[YOUR_ID](er allowlist-tabell). - Ställ in filtret på github_username till
{{ $json.type === 'MemberEvent' ? $json.payload.member.login : $json.actor.login }}.
Steg 4: Routa efter händelsetyp och validera åtgärder
Dela upp händelser efter typ och tillämpa villkorskontroller för obehörig aktivitet.
- Lägg till Route by Event Type och anslut den till Lookup Allowed Users.
- Konfigurera tre regler med Left Value
{{ $('Filter Risk Events').item.json.type }}och Right Value somMemberEvent,PublicEventochPushEvent. - Anslut MemberEvent-utgången till Validate Member Change och ställ in villkoret Left Value
{{ $('Filter Risk Events').item.json.type }}notEqualsadmin. - Anslut PublicEvent-utgången till Validate Public Change och ställ in villkoret Left Value
{{ $json.role }}notEqualsadmin. - Anslut PushEvent-utgången till Validate Push Action och ställ in villkoret Left Value
{{ $json.role }}empty med Right Value=. - Behåll Idle Placeholder ansluten till false-grenen från Validate Push Action som en sink för händelser som inte ska trigga larm.
Steg 5: Konfigurera Slack-larmutgångar
Skicka larm till Slack när obehöriga ändringar upptäcks.
- Anslut Validate Member Change till Member Change Alert och ställ in Text till
Unauthorized MemberEvent! Actor: {{ $json.actor.login }} tried to add {{ $json.payload.member.login }}. ⚠️ This action was blocked/flagged because the actor is not an Admin.. - Anslut Validate Public Change till Public Repo Alert och ställ in Text till
epository {{ $json.repository.name }} was made PUBLIC by {{ $json.actor.login }}! 🚨 Immediate review required.. - Anslut Validate Push Action till Push Alert to Slack och ställ in Text till
=🚨 Security Alert: Unauthorized {{ $('Filter Risk Events').item.json.type }} by {{ $json.actor.login }}!. - För varje Slack-nod, ställ in Channel till er målkanal och uppdatera Channel ID från
[YOUR_ID]. - Inloggningsuppgifter krävs: Anslut era slackApi-inloggningsuppgifter i Member Change Alert, Public Repo Alert och Push Alert to Slack.
Steg 6: Testa och aktivera ert arbetsflöde
Validera flödet från start till mål innan ni aktiverar det i produktion.
- Klicka på Execute Workflow för att köra ett manuellt test från Timed Trigger.
- Bekräfta att GitHub Events Request returnerar händelser och att Filter Risk Events bara skickar vidare kritiska typer.
- Verifiera att Slack-larm endast visas för obehöriga åtgärder i Member Change Alert, Public Repo Alert eller Push Alert to Slack.
- När ni är nöjda, växla arbetsflödet till Active för att aktivera övervakning varje timme.
Tips för felsökning
- GitHub-inloggningsuppgifter kan gå ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera först scopes och giltighet för din Personal Access Token i GitHub Developer settings.
- Om du använder schemalagd pollning och GitHub är långsamt eller rate-limitar kan svaren bli ofullständiga. Öka schemaintervallet eller minska antalet repos/händelser du hämtar innan du antar att logiken är fel.
- Slack-varningar kan misslyckas utan tydliga fel om boten inte kan posta i kanalen. Bekräfta att boten är inbjuden till kanalen och att din Slack-token har behörigheten chat:write.
Snabba svar
Cirka 30 minuter om dina GitHub- och Slack-tokens är klara.
Nej. Du kopplar främst konton och fyller i whitelist-tabellen. Du kan behöva justera ett par villkor, men det är klick-och-välj.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in kostnader för GitHub och Slack (oftast 0 USD om du inte har betalplaner av andra skäl).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serveradministration.
Ja, och det bör du. Du kan lägga till fler händelsetyper i riskfiltret, justera routningslogiken i ”Route by Event Type”, eller ändra vad som räknas som behörigt genom att redigera whitelist-uppslaget och de tre valideringskontrollerna. Vanliga justeringar är att larma vid försök att radera repos, behandla konsulter som ”begränsade” användare och skicka kritiska varningar till en privat säkerhetskanal i stället för en delad utvecklarkanal.
Oftast är det token. Skapa en ny GitHub Personal Access Token, se till att den har scopes som krävs för att läsa org-/repo-händelser och uppdatera sedan credential som används i steget HTTP Request. Om token är okej, kontrollera rate limiting, eftersom frekvent pollning över många repos kan göra att GitHub stryper förfrågningar. Säkerställ också att du anropar rätt API-endpoint för de händelser du bryr dig om, eftersom vissa eventflöden skiljer sig mellan orgar och repos.
Mycket. Med n8n Cloud Starter kan du hantera några tusen körningar per månad, och högre planer går över det. Om du self-hostar finns ingen körningsgräns, men din server måste fortfarande orka med. I praktiken är det här flödet lättviktigt eftersom det filtrerar snabbt och bara skickar Slack-meddelanden för en liten del av händelserna.
Ofta, ja. Den här typen av säkerhetsnära flöde behöver förgreningar (olika kontroller för push vs medlemsändringar vs publika repo-händelser), en enkel ”gör ingenting”-väg och ett whitelist-uppslag som du kontrollerar, vilket n8n hanterar snyggt. Zapier och Make kan lösa delar av det, men logik med flera grenar och löpande volym kan bli dyrt. Dessutom är self-hosting en stor fördel om du vill ha förutsägbara kostnader. Med det sagt: om du bara behöver en enkel automatisering som ”skicka alla GitHub-händelser till Slack” är de verktygen snabba att komma igång med. Prata med en automationsexpert om du är osäker på vad som passar.
Du behöver inte fler notiser. Du behöver rätt notiser, snabbt, med tillräckligt sammanhang för att agera. Sätt upp detta en gång och låt Slack säga till när något faktiskt luktar fel.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.