Ugrás a tartalomra
CtrlSecKapcsolat

Secure SDLC · CI/CD

DevSecOps és AppSec pipeline-integráció

A biztonsági ellenőrzéseket oda tesszük, ahol a kód keletkezik: a pull requestbe és a build pipeline-ba. A kritikus sérülékenység merge előtt akad fenn, nem egy negyedéves pentest-riportban.

Egyeztetés kéréseIdőtartam: 3–4 hét

< 90 mp

hozzáadott pipeline-idő PR-onként (inkrementális szkenneléssel)

merge előtt

akad fenn az új kritikus finding

SBOM

minden release artefaktumhoz

Tipikus kiinduló helyzet

CTO-knak, engineering managereknek és platform csapatoknak, akik 5–200 fejlesztős szervezetben szállítanak szoftvert.

  • 01A SAST eszköz több száz találatot jelez, a fejlesztők ezért kikapcsolták vagy figyelmen kívül hagyják.
  • 02A függőségek (npm, NuGet, Maven, PyPI) sérülékenységeiről csak incidens vagy ügyfél-kérdőív után derül ki bármi.
  • 03A konténer-image-ek alap rétege hónapok óta nem frissült, ismert kritikus CVE-kkel megy élesbe.
  • 04Nincs egyértelmű szabály arra, mi blokkolja a merge-et és mi csak figyelmeztetés.

Hatókör és módszertan

  1. 01

    Pipeline-felmérés és fenyegetésmodell

    Feltérképezzük a meglévő CI/CD folyamatot (Azure DevOps, GitHub Actions, GitLab CI), a repók nyelveit, a build-időt és a deploy-célokat. STRIDE-alapú, könnyített fenyegetésmodell a kritikus szolgáltatásokra.

  2. 02

    SAST és secret scanning

    Semgrep vagy SonarQube szabálykészlet a tényleges stackre hangolva, zajos szabályok kiszűrésével. Gitleaks/TruffleHog a commitokba került titkok ellen, pre-commit hookkal és pipeline-lépéssel.

  3. 03

    SCA és konténer-szkennelés

    Függőségelemzés (Trivy, OWASP Dependency-Check vagy Dependabot/Renovate) SBOM-generálással (CycloneDX). Image-szkennelés a registry push előtt, alap-image frissítési szabályzattal.

  4. 04

    DAST staging környezetben

    OWASP ZAP baseline és hitelesített API-szkennelés (OpenAPI alapján) a staging deploy után, a findingok automatikus jegyesítésével.

  5. 05

    Quality Gate-ek és fejlesztői visszacsatolás

    Súlyosság- és kihasználhatóság-alapú kapuk: csak az új, kritikus és elérhető találat blokkol. A findingok inline PR-kommentként jelennek meg, nem külön portálon.

Leszállítandók

  • Működő pipeline-lépések a saját repóitokban (YAML, merge-elve)
  • Hangolt SAST szabálykészlet és suppress-szabályzat
  • SBOM-generálás és SCA-kapu
  • Quality Gate mátrix: mi blokkol, mi figyelmeztet
  • Fejlesztői workshop (2 óra) és üzemeltetési runbook

Eszközök és szabványok

SemgrepSonarQubeOWASP ZAPTrivyGitleaksCycloneDXAzure DevOpsGitHub ActionsGitLab CI

Fix hatókörű csomagként

Secure SDLC & DevSecOps Sprint

3–4 hét · egyedi ajánlat 48 órán belül

Összes csomag →

Gyakori kérdések

Mennyivel lassul a build a biztonsági lépésektől?

PR-szinten csak a változott fájlokat szkenneljük (diff-aware SAST), a teljes szkennelés éjszakai ütemezéssel fut. Jellemzően 60–90 másodperc a többletidő, amit párhuzamos jobokkal tovább csökkentünk.

Meglévő SonarQube licencünket fel tudjátok használni?

Igen. Ha van SonarQube vagy GitHub Advanced Security licenc, arra építünk, és csak a hiányzó rétegeket (pl. DAST, konténer-szkennelés) egészítjük ki nyílt forráskódú eszközökkel.

Mi történik a meglévő, több száz régi találattal?

Baseline-t rögzítünk: a meglévő találatok külön backlogba kerülnek kockázati sorrendben, a kapu csak az újonnan bevezetett problémákra blokkol. Így a csapat nem áll le az első napon.

Kell a fejlesztőknek új eszközt megtanulniuk?

Nem. A találatok PR-kommentként és a meglévő issue trackerben jelennek meg, javítási javaslattal. A 2 órás workshop a triázsra és a suppress-folyamatra fókuszál.

Kapcsolódó szolgáltatások

Egyeztessük a hatókört.

30 perc technikai hívás, utána 48 órán belül írásos ajánlat.

Egyeztetés kérése
30 perces technikai egyeztetésAjánlat 48 órán belülKapcsolat