A modern szoftverfejlesztés egyik alappillére a folyamatos integráció és szállítás (CI/CD), amelynek köszönhetően a fejlesztési ciklus gyorsabbá, megbízhatóbbá és hatékonyabbá válik. A GitHub Actions az egyik legnépszerűbb eszköz ezen a területen, amely lehetővé teszi a fejlesztők számára, hogy automatizált munkafolyamatokat hozzanak létre közvetlenül a GitHub tárolóikon belül. Azonban a kényelem és a hatékonyság mellett a biztonság kérdése is kiemelten fontossá válik. Egy rosszul konfigurált GitHub Actions munkafolyamat súlyos biztonsági kockázatokat jelenthet, amelyek akár adatszivárgáshoz, jogosulatlan hozzáféréshez vagy rosszindulatú kódinjektáláshoz vezethetnek. Ebben a cikkben bemutatjuk a leggyakoribb biztonsági hibákat, amelyekkel a GitHub Actions munkafolyamatokban találkozhatunk, és megvizsgáljuk, hogyan kerülhetjük el őket.
1. A GITHUB_TOKEN túlengedékeny engedélyei
Minden GitHub Actions munkafolyamat automatikusan kap egy ideiglenes hozzáférési tokent, a GITHUB_TOKEN-t, amely lehetővé teszi számára, hogy a tárolóban végezzen műveleteket (pl. kód klónozása, pull requestek megnyitása, kommentek hozzáadása). Alapértelmezés szerint ez a token széles körű engedélyekkel rendelkezik, beleértve az olvasási és írási hozzáférést számos erőforráshoz. Ha egy munkafolyamat sebezhetővé válik, egy támadó kihasználhatja ezt a tokent a tároló manipulálására vagy érzékeny adatok megszerzésére.
A hiba lényege és a kockázat
A probléma abból adódik, hogy a GITHUB_TOKEN alapértelmezett engedélyei gyakran sokkal szélesebbek, mint amennyire a munkafolyamatnak valójában szüksége van. Ha egy külső action-t vagy egy bemeneti adatot kihasználnak, a támadó teljes hozzáférést kaphat a token által biztosított összes művelethez.
Megoldás: A legkisebb jogosultság elve
Alkalmazzuk a legkisebb jogosultság elvét (principle of least privilege). Explicit módon korlátozzuk a GITHUB_TOKEN engedélyeit minden egyes munkafolyamatban a minimálisan szükséges szintre. Ezt a munkafolyamat YAML fájljában tehetjük meg a permissions kulcsszóval. Például, ha egy munkafolyamatnak csak olvasási hozzáférésre van szüksége a tartalomhoz, és pull requesteket kell nyitnia, akkor:
permissions:
contents: read
pull-requests: write
checks: write # Ha státusz ellenőrzést is végez
# Minden más engedélyt alapértelmezetten megtagadunk
Ez drámaian csökkenti a potenciális támadási felületet.
2. Harmadik féltől származó Actions: A függőségi lánc kockázata
A GitHub Actions piactéren rengeteg hasznos, előre elkészített action található, amelyek felgyorsíthatják a fejlesztést. Ezek használata azonban a szoftverellátási lánc (supply chain) biztonsági kockázatait is magával hozza.
A hiba lényege és a kockázat
Sok fejlesztő egyszerűen a legújabb verzióra hivatkozik (pl. uses: actions/checkout@v3 vagy @master), anélkül, hogy ellenőrizné az action forráskódját. Ez azt jelenti, hogy ha az action fejlesztőjének tárolóját feltörik, vagy rosszindulatú kódot injektálnak a legújabb verzióba, az a te munkafolyamataidban is lefuthat, és komoly károkat okozhat. Ráadásul egy akció fejlesztője bármikor kiadhat egy rosszindulatú frissítést.
Megoldás: Rögzítés commit SHA-hoz és auditálás
Mindig rögzítsd az action-öket egy specifikus commit SHA-hoz, ne csak a főverzióhoz vagy ághoz. Ez biztosítja, hogy pontosan azt a kódot futtatod, amit auditáltál és amit vársz. Példa:
uses: actions/checkout@v3 # Kerüld!
uses: actions/checkout@8e5cd47f6507a21349f7b6053351a029c7882200 # Helyes! (teljes SHA)
Továbbá:
- Feltétlenül auditáld a külső action-ök forráskódját, mielőtt használnád őket, különösen, ha érzékeny adatokat kezelnek.
- Lehetőség szerint részesítsd előnyben a hivatalos GitHub action-öket vagy a nagy, megbízható szervezetek által fenntartott action-öket.
- Fontold meg saját, privát action-ök létrehozását a kritikus műveletekhez.
3. Titkok nem megfelelő kezelése
A munkafolyamatok gyakran igényelnek hozzáférést érzékeny információkhoz, mint például API kulcsok, adatbázis jelszavak vagy felhőszolgáltatói hitelesítő adatok. Ezek nem megfelelő kezelése az egyik legnagyobb biztonsági kockázat.
A hiba lényege és a kockázat
A leggyakoribb hiba, hogy a titkokat közvetlenül a munkafolyamat YAML fájljába vagy a tárolóba kódolják. Másik gyakori hiba a titkok nem biztonságos környezeti változókként való használata vagy naplókba való kikerülése.
Megoldás: GitHub Secrets, OIDC és biztonságos környezet
Használjuk a GitHub beépített Secrets funkcióját. Ezek titkosítottak, és csak a munkafolyamatokban érhetők el. Soha ne írd ki a titkokat a naplókba! Használhatod a core.set-output helyett a biztonságosabb kimenetkezelést, vagy győződj meg róla, hogy a titkok soha ne jelenjenek meg a kimenetben.
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Használd a titkot
run: echo "Ez a titok: ${{ secrets.MY_API_KEY }}" # NE TEDD EZT!
- name: Helyes titokhasználat (például környezeti változóként)
env:
API_KEY: ${{ secrets.MY_API_KEY }}
run: echo "Futtatás API kulccsal..." # A kulcs nem jelenik meg a naplóban
Emellett, amennyiben felhőszolgáltatókat (AWS, Azure, GCP) használsz, fontold meg az OpenID Connect (OIDC) használatát. Az OIDC lehetővé teszi, hogy a GitHub Actions munkafolyamatok ideiglenes, rövid élettartamú hitelesítő adatokat kapjanak közvetlenül a felhőszolgáltatótól, anélkül, hogy hosszú élettartamú titkokat kellene tárolni a GitHub Secretsben. Ez jelentősen növeli a biztonságot, mivel minimalizálja a kiszivárgás kockázatát.
4. Bemeneti adatok validálásának hiánya
A workflow_dispatch esemény lehetővé teszi a munkafolyamatok kézi indítását, paraméterek átadásával. A pull_request eseményeknél pedig a pull request címe, leírása vagy a módosított fájlok nevei is felhasználhatók. Ha ezeket a bemeneti adatokat nem validáljuk megfelelően, kódinjektálási vagy parancs-injektálási támadások áldozatául eshetünk.
A hiba lényege és a kockázat
Ha egy munkafolyamat közvetlenül használja a felhasználó által megadott bemeneti adatokat shell parancsokban (pl. git checkout ${{ github.event.inputs.branch }}) anélkül, hogy validálná vagy megfelelően „escapelné” azokat, egy támadó rosszindulatú parancsokat injektálhat. Például, ha egy ágnevet vár, és valaki "my-branch; rm -rf /"-t ad meg, az katasztrofális következményekkel járhat.
Megoldás: Szigorú bemeneti validáció
Minden külső bemeneti adatot szigorúan validálj és tisztíts meg, mielőtt felhasználnád őket a shell parancsokban. Használd a GitHub Actions kifejezéseit (expressions) a validációhoz:
on:
workflow_dispatch:
inputs:
branch:
description: 'Melyik ágon fusson a workflow?'
required: true
default: 'main'
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Ellenőrizd az ág nevét
if: ${{ !startsWith(github.event.inputs.branch, 'feature/') && github.event.inputs.branch != 'main' }}
run: |
echo "Érvénytelen ág név. Csak 'main' vagy 'feature/' előtagú ágak engedélyezettek."
exit 1
- name: Checkout kód
uses: actions/checkout@v3
with:
ref: ${{ github.event.inputs.branch }}
Ezen felül használj további sanitizálási technikákat, ha shell parancsokkal dolgozol, vagy preferáld a beépített action-öket, amelyek már kezelik a biztonságos bemeneteket.
5. Önálló futtatók (Self-Hosted Runners) nem megfelelő biztonsága
Míg a GitHub által hosztolt futtatók biztonságos, izolált környezetet biztosítanak minden egyes futtatáshoz, az önálló futtatók (self-hosted runners) telepítésével a felhasználó vállalja a futtató környezet biztonságának felelősségét.
A hiba lényege és a kockázat
Ha egy önálló futtató nincs megfelelően konfigurálva és védve, a munkafolyamatok során futtatott kód hozzáférhet a futtató gép erőforrásaihoz, a hálózati erőforrásokhoz, sőt, akár más projektek adataihoz is, ha nem megfelelő a szegmentálás. Egy rosszindulatú munkafolyamat könnyedén kompromittálhatja a futtatót és az azt tartalmazó infrastruktúrát.
Megoldás: Szigorú izoláció és monitorozás
- Izoláció: Ne futtass érzékeny, éles környezeti munkafolyamatokat ugyanazon az önálló futtatón, mint a nem megbízható forrásokból (pl. külső hozzájárulásokból származó pull requestek) származó munkafolyamatokat. Különítsd el a futtatókat cél szerint (pl. dev, prod, külső PR).
- Ephemeral runners: Használj ideiglenes, egyszer használatos futtatókat, amelyek minden futás után megsemmisülnek. Ez megakadályozza az állapotfenntartó támadásokat.
- Hálózati korlátozások: Korlátozd a futtató hálózati hozzáférését a minimálisan szükségesre. Használj tűzfalakat és biztonsági csoportokat.
- Host biztonság: Rendszeresen frissítsd a futtatók operációs rendszerét és szoftvereit, és alkalmazz szigorú hozzáférés-szabályozást a host gépen.
- Monitorozás: Figyeld a futtatók tevékenységét, a rendellenes viselkedést, és integráld a logokat a központi naplózási rendszerekbe.
6. Ágazati védelmi szabályok hiánya vagy gyengesége
Az ágazati védelmi szabályok (branch protection rules) kritikus fontosságúak a kódintegritás és a biztonság fenntartásában. Ezek hiánya vagy gyenge konfigurálása megnyithatja az utat a jogosulatlan vagy ellenőrizetlen kódmódosítások előtt.
A hiba lényege és a kockázat
Ha nincsenek beállítva ágazati védelmi szabályok, bárki, aki írási hozzáféréssel rendelkezik a tárolóhoz, közvetlenül a fő ágra (pl. main vagy master) küldhet kódot, megkerülve a kódellenőrzéseket és a CI/CD folyamatokat. Ez rosszindulatú kód bejuttatásához vagy a kritikus rendszerek megzavarásához vezethet.
Megoldás: Erős ágazati védelem
Konfigurálj erős ágazati védelmi szabályokat a kritikus ágaidon (pl. main, production):
- Pull requestek kötelezővé tétele: Követeld meg, hogy minden módosítás pull requesten keresztül történjen.
- Minimális felülvizsgálók száma: Követelj meg legalább egy (vagy több) jóváhagyó felülvizsgálatot a pull requestek merge-elése előtt.
- Kötelező státuszellenőrzések: Követeld meg, hogy a CI/CD munkafolyamatok sikeresen lefutottak legyenek a merge előtt. Ide tartozhatnak a tesztek, a linterek, a biztonsági ellenőrzések.
- Kód tulajdonosok: Használj CODEOWNERS fájlt, hogy bizonyos kódterületek módosításához specifikus csapatok vagy személyek jóváhagyására legyen szükség.
- Futtatási történet törlésének tiltása: Tiltsd le a futtatási történet átírását vagy törlését.
7. Naplózás és monitorozás hiánya
Ahogy minden más informatikai rendszerben, a CI/CD munkafolyamatokban is elengedhetetlen a megfelelő naplózás és monitorozás. A biztonsági incidensek gyors felismerésének kulcsa, hogy lássuk, mi történik a rendszereinkben.
A hiba lényege és a kockázat
Ha nem figyeled aktívan a GitHub Actions munkafolyamatok futásait, a sikertelen vagy gyanús futásokat, valamint az audit naplókat, akkor egy esetleges támadás észrevétlen maradhat, vagy csak későn derül ki, amikor már nagy a kár.
Megoldás: Aktív naplózás és értesítések
Használd ki a GitHub beépített audit naplóit, amelyek rögzítik a tárolóban és a szervezetben történt minden fontos eseményt. Integráld a GitHub Actions naplókat a központi logkezelő rendszeredbe (SIEM), ha van. Állíts be értesítéseket a gyanús tevékenységekre:
- Sikertelen biztonsági ellenőrzések
- Váratlanul hosszú futási idők
- Sikertelen bejelentkezési kísérletek (self-hosted runner-ek esetében)
- Munkafolyamatok, amelyek váratlanul módosítják a konfigurációt vagy a titkokat.
A GitHub Advanced Security funkciói, mint a Code scanning és a Secret scanning, szintén segíthetnek a proaktív hibafeltárásban.
8. Függőségek és szoftverellátási lánc sebezhetőségei
A munkafolyamatok gyakran építenek harmadik féltől származó könyvtárakra, csomagokra és image-ekre. Ezek elavult vagy sebezhető verzióinak használata jelentős kockázatot jelenthet.
A hiba lényege és a kockázat
Ha egy munkafolyamat olyan build környezetet használ, amely elavult függőségeket vagy sebezhető alap image-eket tartalmaz, az könnyen kihasználhatóvá válhat. Egy ilyen sebezhetőség lehetővé teheti a támadók számára, hogy rosszindulatú kódot futtassanak a CI/CD környezetben, vagy kompromittálják a generált artefaktumokat.
Megoldás: Dependabot és sebezhetőségi szkennerek
- A Dependabot automatikusan ellenőrzi a tároló függőségeit, és pull requesteket hoz létre a biztonsági javításokkal és a verziófrissítésekkel. Aktiváld a Dependabot alerts és security updates funkcióit.
- Integrálj sebezhetőségi szkennereket (pl. OWASP Dependency-Check, Snyk, Trivy) a munkafolyamataidba, hogy a build folyamat során ellenőrizzék a függőségeket és a Docker image-eket.
- Használj megbízható és rendszeresen frissített alap image-eket a Docker konténereidhez.
9. Statisztikai elemzések (pl. CodeQL) hiánya
A kód biztonságának biztosítása nem ér véget a munkafolyamatok konfigurációjával. Magát az alkalmazáskódot is folyamatosan ellenőrizni kell a potenciális sebezhetőségek szempontjából.
A hiba lényege és a kockázat
Ha nem használsz statikus alkalmazásbiztonsági tesztelő (SAST) eszközöket a munkafolyamataidban, a potenciális biztonsági hibák (pl. SQL injekció, XSS, Path Traversal) bekerülhetnek az éles rendszerbe, anélkül, hogy a fejlesztési ciklus korai szakaszában észrevették volna őket.
Megoldás: Integrálj SAST eszközöket
Integráld a GitHub beépített CodeQL eszközét, vagy más SAST megoldásokat (pl. SonarQube, Bandit Pythonhoz) a munkafolyamataidba. Ezek az eszközök automatikusan elemzik a kódot minden push vagy pull request esetén, és jelentik a talált sebezhetőségeket. Ez lehetővé teszi, hogy a hibákat már a fejlesztési ciklus elején javítsd, minimalizálva a „shift-left” biztonsági megközelítés jegyében a kockázatokat és a javítási költségeket.
name: "CodeQL"
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
permissions:
security-events: write
contents: read
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Initialize CodeQL
uses: github/codeql-action/init@v2
with:
languages: javascript # vagy a használt nyelvek listája
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v2
Összefoglalás és jövőbeli lépések
A GitHub Actions egy rendkívül erőteljes eszköz, de mint minden ilyen erejű platform, megfelelő odafigyelést és biztonsági tudatosságot igényel. A fent részletezett gyakori hibák elkerülésével jelentősen megerősítheted a szoftverfejlesztési folyamatod biztonságát és minimalizálhatod a potenciális támadási felületeket.
Ne feledd, a biztonság nem egy egyszeri feladat, hanem egy folyamatos folyamat. Rendszeresen ellenőrizd a munkafolyamataidat, tartsd naprakészen az action-öket és a függőségeket, és tájékozódj a legújabb biztonsági fenyegetésekről és bevált gyakorlatokról. A proaktív megközelítés és a folyamatos éberség kulcsfontosságú ahhoz, hogy a GitHub Actions munkafolyamataid továbbra is hatékonyak és biztonságosak maradjanak.
Investálj az oktatásba, ösztönözd a csapatodat a biztonsági szempontok figyelembevételére a fejlesztési folyamat minden szakaszában, és építs ki egy robusztus, ellenálló CI/CD környezetet. Ezzel nemcsak a kódod, hanem a teljes fejlesztési ökoszisztémád biztonságát is garantálni tudod.
Leave a Reply