Debesų saugumo patarimai naudingi tik tada, kai jie skirti tikroms spragoms, kuriomis naudojasi užpuolikai: viešam S3 segmentui, kurio niekas nepastebėjo, CI vykdytojui su pakaitos simboliu. AWS leidimai, nutekėjęs slaptas kodas kūrimo žurnale arba kenkėjiška priklausomybė, kuri tyliai įdiegta atliekant pipeline paleisti. Dauguma debesijos saugumo incidentų kyla ne dėl nežinomų grėsmių. Juos sukelia žinomi trūkumai, kurie niekada nebuvo ginami, prioritetizuojami ar ištaisomi.
Šiame vadove pateikiama 20 praktinių debesijos saugumo patarimų, suskirstytų pagal lygmenis: tapatybė, duomenys, infrastruktūra, programinės įrangos tiekimo grandinė, CI/CD pipelines, aptikimas ir reagavimas į incidentus. Nesvarbu, ar stiprinate vienos debesies paskyros apsaugą, ar kelių komandų apsaugą „DevSecOps“ pipelinešios kontrolės priemonės padeda užkirsti kelią pažeidimams, kurie iš tikrųjų įvyksta.
Kodėl debesijos saugumas vis dar stringa, nepaisant daugybės debesijos saugumo patarimų
Debesijos saugumas – tai valdiklių, politikų ir įrankių rinkinys, apsaugantis debesijos aplinkoje veikiančius duomenis, programas ir infrastruktūrą. Jis apima tapatybę, tinklą, duomenis, programos kodą, priklausomybes, infrastruktūros konfigūraciją ir kūrimo procesą. pipelines.
Priežastis, kodėl net ir brandžioms komandoms nepavyksta, yra ne žinių stoka. Tai trys struktūrinės problemos:
- Greitis ir saugumas. Pipelinejuda greitai. Trinties didinantys valdikliai yra išjungiami. Komandos, kurios tinkamai įgyvendina debesijos saugumą, neprideda vartų, o automatizuoja jų vykdymą tiesiai į darbo eigą.
- Įrankio fragmentacija. Paslapčių nuskaitymas viename įrankyje, SCA kitame, IaC trečdalyje. Nesant vieningo požiūrio, atsiranda spragų tarp aprėpties lygių, o išvados niekada nesusiejamos su realia rizika.
- Budrumo nuovargis. Skeneriai, kurie per dieną aptinka šimtus CVE atakų, moko inžinierius ignoruoti radinius, įskaitant ir kritinius. Prioritetų nustatymas nėra neprivalomas; tai lemia, ar saugumas iš tikrųjų veikia.
Žemiau pateikti debesijos saugumo patarimai skirti praktiškai užpildyti šias spragas. Užuot debesijos saugumą traktavę kaip tik vykdymo laiko problemą, jie apima visą kodo pateikimo kelią nuo debesijos iki debesijos.
20 debesijos saugumo patarimų:
Tapatybės ir prieigos valdymo debesies saugumo patarimai
1. Įjunkite daugiafaktorinį autentifikavimą visur
MFA išlieka vienintele didžiausią investicijų grąžą užtikrinančia debesijos saugumo valdymo priemone. Ji iš karto sustabdo kredencialų vagystės atakas, ir užpuolikai tai žino. Bet kuri paskyra be MFA yra lengvas taikinys.
Įjunkite daugiafaktorinį autentifikavimą (MFA) kiekvienai žmogaus tapatybei debesijos aplinkose: kūrėjų paskyrose, administratoriaus konsolėse, debesijos paslaugų teikėjų portaluose, CI/CD dashboards. Privilegijuotoms paskyroms naudokite sukčiavimui atsparią daugiafaktorinę autentifikaciją (aparatinės įrangos raktus, prieigos raktus). Laiku pagrįsti kodai, įvedami per autentifikavimo programėlę, yra minimalus reikalavimas.
2. Taikykite mažiausias privilegijas, ypač ne žmonių tapatybėms
Mažiausios privilegijos principas yra gerai suprantama žmonėms. Dalis, kurią komandos nuolat praleidžia, yra ne žmonių tapatybės: CI/CD paslaugų paskyros, „Lambda“ funkcijos, konteinerių darbo krūviai, „GitHub Actions“ vykdikliai.
Šios tapatybės kaupia pakaitos simbolių teises, nes jos konfigūruojamos vieną kartą ir niekada nebeperžiūrimos. Būtent į jas užpuolikai taip pat taikosi tiekimo grandinės atakose, nes jos turi prieigą prie paslapčių, saugyklų, gamybos išteklių ir žemesniųjų sistemų.
Kas ketvirtį tikrinkite paslaugos paskyros teises. Pašalinkite viską, kas nebuvo naudojama 90 dienų.
3. Ilgalaikius įgaliojimus pakeiskite trumpalaikiais žetonais
Statiniai API raktai ir ilgai gyvuojantys žetonai yra viena iš dažniausių debesijos pažeidimų priežasčių. Jie gauna commitperkelta į saugyklas, nutekinta į CI žurnalus, nukopijuota į „Slack“ ir pamiršta .NS failai, tada galioja mėnesius ar metus.
Kai tik įmanoma, pakeiskite juos trumpalaikiais įgaliojimais: AWS STS prisiima vaidmenį, GCP darbo krūvio tapatybės federacija, „GitHub“ veiksmai OIDCKai statinių prisijungimo duomenų išvengti neįmanoma, saugokite juos slaptų duomenų tvarkytuvėje („Vault“, „AWS Secrets Manager“, „Azure Key Vault“) ir keiskite automatiškai.
4. Įdiekite „Just-in-Time“ prieigą padidintoms privilegijoms
Nuolatinė administratoriaus prieiga yra nuolatinė rizika. Nuolatiniai padidinti leidimai reiškia, kad vienos pažeistos tapatybės pakanka, kad būtų galima pasiekti gamybinę aplinką.
JIT prieigos sistemos („AWS IAM Identity Center“, „GCP Privileged Access Manager“, „Okta Access Requests“) suteikia padidintą prieigą pagal poreikį, ribotą laiką ir su visais audito žurnalais. Kūrėjai gauna tai, ko jiems reikia, kada jiems to reikia. Užpuolikai neranda nuolatinio taikinio.
5. Užtikrinkite nulinį pasitikėjimą paslaugų tarpusavio komunikacijoje
Tradiciniai perimetro modeliai daro prielaidą, kad viskas tinkle yra patikima. Debesijos pagrindu sukurtose aplinkose su mikropaslaugomis, konteineriais ir dinaminiais darbo krūviais ši prielaida yra pavojinga.
Nulis pasitikėjimo reiškia, kad kiekviena užklausa yra autentifikuojama ir autorizuojama, nepriklausomai nuo jos kilmės. Įdiekite paslaugų tarpusavio autentifikavimą (mTLS, paslaugų tinklo tapatybė), vykdykite tinklo politiką darbo krūvio lygmeniu ir pagal numatytuosius nustatymus vidinį srautą traktuokite kaip nepatikimą.
Duomenų apsaugos debesies saugumo patarimai
6. Užšifruokite viską, įskaitant vidinį srautą
Šifravimas ramybės būsenoje (AES-256, valdoma KMS) dabar yra standard praktika. Daugelio komandų skirtumas yra šifravimas perduodant vidinį srautą.
VPC su mikropaslaugomis ir konteinerių tarpusavio ryšiu srautas, kuris lieka „viduje“, nėra savaime saugus. Vidiniam paslaugų ryšiui įdiekite abipusį TLS (mTLS). Naudokite paslaugų tinklą („Istio“, „Linkerd“) arba nulinio pasitikėjimo tinklo sluoksnį, kad tai būtų užtikrinta automatiškai, o ne pasikliaukite kiekviena komanda, kad ji tai tinkamai sukonfigūruotų.
7. Aptikti ir ištaisyti atskleistas paslaptis prieš joms išplintant
Paslaptis commitĮ saugyklą įtraukta informacija nelieka paslaptyje. „GitHub“ indeksuoja viešąsias saugyklas per kelias sekundes. Vidinės saugyklos nėra apsaugotos – kai paslaptis patenka į „Git“ istoriją, ją gali pasiekti visi, turintys prieigą prie saugyklos, dabar ar ateityje.
Svarbūs prevenciniai sluoksniai (pre-commit hooks, IDE įskiepiai), bet to nepakanka. Jums reikia nuolat nuskaityti visas saugyklas, įskaitant istorinius duomenis commits, CI/CD rąstai, IaC failus ir konteinerio vaizdus. Aptikus paslaptį, reaguoti reikia nedelsiant: atšaukti, pakeisti ir įvertinti, ar prie jos buvo prieita nuo jos atskleidimo iki aptikimo.
8. Klasifikuokite duomenis ir taikykite valdiklius pagal jautrumą
Ne visi duomenys jūsų debesijos aplinkoje yra vienodai rizikingi, jei jiems atsiskleidžia duomenys. Viską traktuoti vienodai reiškia per daug investuoti į mažos rizikos duomenų kontrolę ir nepakankamai apsaugoti duomenis, kurie iš tikrųjų yra svarbūs.
Klasifikuokite duomenis pagal jautrumą (vieši, vidiniai, konfidencialūs, riboto naudojimo). Taikykite prieigos kontrolės priemones, šifravimą. standardIr kiekvieno lygio audito žurnalavimo reikalavimus. Automatizuokite klasifikavimą, kai įmanoma, rankinis žymėjimas nėra keičiamo mastelio.
Infrastruktūros ir konfigūracijos saugumas
9. Nuskaitykite IaC kiekvieną CommitNe tik prieš dislokavimą
Infrastruktūra kaip kodas yra ta vieta, kur kuriamos neteisingos konfigūracijos, o ne gamyboje. Viešas S3 segmentas, atvira saugos grupė arba IAM vaidmuo su *:* „permissions“ neatsiranda atsitiktinai. Jis prasideda kaip eilutė „Terraform“ faile arba „Kubernetes“ manifeste, kurios niekas nepažymėjo.
IaC nuskaitymas turi būti atliekamas kiekvieną pull request, o išvados buvo aptiktos kodo peržiūros darbo eigoje. Nuskaitykite „Terraform“, „Kubernetes“ manifestus, „CloudFormation“, „Helm“ diagramas, „Dockerfiles“ ir CI/CD konfigūracijos.
Ksigeni IaC Security nuskaito kiekvieną palaikomą formatą kiekvieną commit, susieja išvadas su konkrečiais ištekliais ir integruojasi su jūsų PR darbo eiga, kad kūrėjai gautų atsiliepimus ten, kur dirba, o ne atskirame įrenginyje. dashboard jie niekada neatsidaro. Pradėti nemokamą bandomąją versiją →
10. Saugumo politiką traktuokite kaip kodą
Rankinės saugumo peržiūros nėra pritaikomos. Tai daroma taikant politiką kaip kodą.
Naudokite tokius įrankius kaip OPA (atvirosios politikos agentas) arba „Kyverno“, kad saugumo taisyklės būtų išreikštos kaip versijaizuotas, testuojamas kodas. Užtikrinkite jų vykdymą pipeline lygis, taigi „Kubernetes“ diegimas su privilegijuota: tiesa Arba konteineris, veikiantis kaip root, automatiškai kiekvieną kartą nepavyksta sukurti. Kai politikos yra kode, jos yra peržiūrimos ir tobulinamos kaip ir bet kuris inžinerinis artefaktas. Kai jos yra dokumentacijoje, jos kinta.
11. Įgyvendinkite saugios konfigūracijos bazinius duomenis ir stebėkite, ar nėra nuokrypių
Numatytosios konfigūracijos optimizuotos patogumui, o ne saugumui. Debesijos paslaugos, konteinerių vykdymo aplinkos ir valdomi „Kubernetes“ klasteriai pateikiami su nustatymais, kuriuos lengva naudoti ir išnaudoti.
Pradėti nuo CIS Jūsų debesijos paslaugų teikėjo, konteinerio vykdymo aplinkos ir OS etalonai. Užkoduokite juos kaip politiką kaip kodą, kad jie būtų automatiškai taikomi. Nuolat stebėkite, ar nėra nukrypimų – konfigūracija, atitinkanti reikalavimus praėjusią savaitę, šiandien gali neatitikti reikalavimų po greito pakeitimo, kurį spaudė greitas pakeitimas.
12. Segmentuoti tinklus ir apriboti šoninį judėjimą
Plokščios tinklo architektūros reiškia, kad užpuolikui pažeidus vieną darbo krūvį, jis gali pasiekti visus kitus. Tinklo segmentavimas apima sprogimo spindulį.
Naudokite VPC, potinklius ir saugos grupes, kad sukurtumėte izoliacijos zonas pagal funkciją ir jautrumą. Apribokite rytų-vakarų srautą tarp paslaugų, kad jis būtų tik būtinas. Įdiekite išeinančio srauto filtravimą, nes dauguma pažeistų darbo krūvių turi pasiekti užpuoliko kontroliuojamą serverį, o išeinančio srauto valdymas yra viena geriausių galimybių tai aptikti arba užkirsti kelią.
Programinės įrangos tiekimo grandinės debesijos saugumo patarimai
Kai kurie svarbiausi debesijos saugumo patarimai nebėra debesijos paslaugų teikėjo konsolėje. Jie prasideda anksčiau, programinės įrangos tiekimo grandinėje. Priklausomybės, CI/CD Darbo eigos, paslaptys, kūrimo scenarijai ir artefaktai gali sukelti debesijos riziką prieš diegimą.
13. Nuskaitykite kiekvieną priklausomybę prieš jai patenkant į jūsų kompiliaciją
Atvirojo kodo paketai yra labiausiai paplitęs pradinės prieigos vektorius šiuolaikinėse tiekimo grandinės atakose. 2024 m. „Shai-Hulud“ kampanija pavogė daugiau nei 830 npm paketų. „XZ Utils“ galinės durys beveik pakenkė SSH autentifikavimui milijonuose „Linux“ sistemų. Abiem atvejais kenkėjiškas kodas pateko per įprastą priklausomybių diegimo procesą.
Pagrindinis SCA (Programinės įrangos sudėties analizės) neapdorotų CVE sąrašų nepakanka. Ko jums iš tikrųjų reikia:
- Pasiekiamumo analizėAr jūsų kode iš tikrųjų iškviečiama pažeidžiama funkcija?
- Kenkėjiškų programų aptikimas: ar šis paketas pasižymi kenkėjiška elgsena, užmaskuotais scenarijais, netikėtais tinklo skambučiais, gyvavimo ciklu hooks kurios diegia išorines vykdymo aplinkas?
- EPSS balasKokia tikimybė, kad šis CVE yra aktyviai išnaudojamas natūralioje aplinkoje dabar, ne tik teoriškai?
14. Užrakinti CI/CD Pipelines
CI/CD sistemos turi prieigą prie paslapčių, debesies kredencialų ir gamybos aplinkų. Jos taip pat paprastai yra mažiau apsaugotos nei gamybos sistemos, kuriose jos diegiamos.
Vykdymo užtikrinimo priemonės:
- Reikalauti kodo peržiūros dėl bet kokių pakeitimų pipeline konfigūracijos failai (.github/workflows/, Dženkinsfile, Ir tt)
- Apribokite savarankiškai talpinamų vykdytojų prieigą prie patvirtintų saugyklų, neperžiūrėta vykdytojų prieiga yra tiesioginis kelias į kredencialų vagystę.
- Niekada neperduokite paslapčių kaip paprasto teksto aplinkos kintamųjų; naudokite paslapčių tvarkyklės integraciją
- Auditas pipeline netikėtų komandų, neįprastų tinklo skambučių ar vykdymo netikėtomis valandomis žurnalai
Ksigeni CI/CD saugumas vykdo guardrails tiesiai tavo pipeline , blokuojant nesaugias versijas, aptinkant įterptus darbo eigų procesus ir užtikrinant pipeline vientisumas kiekviename etape. Užsisakykite demonstraciją →
15. Patvirtinkite kūrinio vientisumą ir pasirašykite artefaktus
Jei užpuolikas gali įterpti kodą į kūrimo scenarijų, modifikuoti artefaktą po kompiliavimo arba pažeisti CI vykdiklį, jis valdo jūsų programinės įrangos tiekimo grandinę, nepriklausomai nuo to, koks švarus yra jūsų šaltinio kodas.
Įgyvendinkite kūrimo vientisumo valdiklius:
- Prisegti visas priklausomybių versijas ir bazinius vaizdus prie tikslių santraukų, o ne prie žymų
- Pasirašykite kūrimo artefaktus ir patikrinkite parašus prieš diegimą
- Stebėkite netikėtus pokyčius CI/CD Įterpti darbo eigos failai buvo pagrindinis rodiklis tokiuose išpuoliuose kaip „Shai-Hulud“
- Įdiegti SLSA atestacijas, kad būtų galima kriptografiškai įrodyti, kas buvo sukurta, iš kokio šaltinio ir kuo pipeline
Grėsmių aptikimas ir reagavimas į incidentus
16. Centralizuokite registravimą ir užtikrinkite matomumą visame duomenų rinkinyje
Negalite aptikti to, ko nematote. Dauguma debesies saugumo stebėjimo funkcijų sutelktos į vykdymo laiką, „CloudTrail“, VPC srautų žurnalus ir „GuardDuty“. Tai būtina, bet nepakankama.
Tokios atakos kaip „Shai-Hulud“ ir „SolarWinds“ iš dalies pavyko dėl to, kad kompromitacija įvyko dar kūrimo metu. pipeline, gerokai anksčiau, nei kas nors pasiekė gamybinę stebėseną. Norint visapusiškai matyti, reikia aprėpti šaltinio kodo pakeitimus, kūrimo ir artefaktų sluoksnius, debesies vykdymo aplinką ir API veiklą.
17. Išvadas skirstykite pagal panaudojimo galimybes, o ne tik pagal sunkumą
Skeneris, per savaitę pateikiantis 500 radinių, išmoko komandas ignoruoti radinius, įskaitant ir svarbiausius. Prioritetų nustatymas skiria veikiančias saugumo programas nuo tų, kurios egzistuoja tik popieriuje.
Efektyvus prioritetų nustatymas apima: pasiekiamumą (ar pažeidžiamas kodas iš tikrųjų vykdomas?), matomumą (ar paslauga pasiekiama internetu?), EPSS balą (aktyvaus išnaudojimo tikimybę) ir verslo kontekstą (gamybinė ir kūrimo aplinka).
Xygeni ASPM pateikia visus radinius SAST, SCA, IaC, paslaptys ir pipeline security į vieningą rizikos vaizdą su kontekstiniu prioritetų nustatymu, kuris tiksliai nurodo jūsų komandai, ką pirmiausia taisyti. Užsisakykite demonstraciją →
18. Nustatykite elgesio bazinius lygius ir įspėkite apie nukrypimus
Žinomos blogos atakų parašai aptinka žinomas grėsmes. Elgesio anomalijų aptikimas aptinka nežinomas grėsmes, nulinės dienos atakas, naujus atakų modelius ir vidines grėsmes.
Jūsų CI/CD konkrečiai aplinkai, nustatykite tipinės kompiliavimo trukmės, įprastų paketų diegimo modelių, numatomų tinklo paskirties vietų kompiliavimo metu ir bazinius lygius standard paslapčių prieigos modeliai. Nukrypimai nuo šių bazinių linijų yra ankstyviausias įspėjamasis signalas ir sluoksnis, kurio dauguma komandų visiškai nemato.
19. Apibrėžkite vykdymo rinkinius debesies kompiuterijai būdingiems incidentų scenarijams
Bendrieji incidentų reagavimo planai neatsižvelgia į debesijos kompiuterijai būdingus scenarijus: pažeistą paketą, jau įdiegtą 40 paslaugų, CI vykdiklį, kurio kredencialus pavogė kenkėjiškas išankstinio diegimo scenarijus, kompiliavimo artefaktą, kuris galėjo būti pakeistas per pastarąsias 72 valandas.
Sukurkite specialius operacijų rinkinius, skirtus: pažeistoms priklausomybėms, pipeline kredencialų vagystė, netinkamos konfigūracijos sukeltas duomenų atskleidimas ir kenkėjiška CI darbo eigos injekcija. Kiekviena vykdymo knyga turėtų apibrėžti, kam priklauso atsakymas, kas nedelsiant atšaukiama ir kokie teismo ekspertizės tyrimai reikalingi sprogimo spinduliui nustatyti.
20. Bėk stalo pratimuscises, mažiausiai du kartus per metus
Neišbandytas vykdymo sąsiuvinis yra hipotezė. Stalinis pratimascisatskleidžia jūsų atsako plano spragas anksčiau, nei tai padaro užpuolikas. Tikslas nėra tobulai laikytis veiksmų plano, o atrasti, ko trūksta.
Bėkite bent du pratimuscisper metus, imituojant skirtingus scenarijų tipus: tiekimo grandinės pažeidimą, dėl netinkamos konfigūracijos sukeltą duomenų nutekėjimą, pažeistą integraliosios infrastruktūros administratorių. Įtraukite komandas, kurios iš tikrųjų reaguos, saugumo, „DevOps“ ir budinčius kūrėjus.
Debesijos saugumo patarimų kontrolinis sąrašas: trumpa nuoroda
| sluoksnis | Pagrindiniai valdikliai |
|---|---|
| Tapatybė | MFA visur, mažiausiai privilegijų, trumpalaikiai įgaliojimai, prieiga prie JIT |
| Duomenys | Šifravimas saugojimo ir perdavimo metu, slaptų duomenų nuskaitymas ir automatinis atšaukimas, duomenų klasifikavimas |
| Infrastruktūra | IaC nuskaitymas įjungtas commit, politika kaip kodas, CIS bazinio lygio užtikrinimas, tinklo segmentavimas |
| Tiekimo grandinė | SCA su pasiekiamumu ir kenkėjiškų programų aptikimu, CI/CD grūdinimas, konstrukcijos vientisumas ir SLSA |
| Aptikimas | Centralizuotas registravimas, EPSS pagrįstas prioritetų nustatymas, elgesio anomalijų aptikimas |
| atsakymas | Debesijos technologijoms skirtos vykdymo knygos, stalo pratimaicisdokumentuotas sprogimo spindulio įvertinimas |
Kaip „Xygeni“ padeda pritaikyti debesies saugumo patarimus visame steke
Debesijos saugumo patarimai veikia tik tada, kai komandos gali juos nuosekliai taikyti per visą programinės įrangos tiekimo gyvavimo ciklą. Dauguma įrankių apima vieną lygmenį: vykdymo aplinką, kodą, priklausomybes, paslaptis arba CI/CDTačiau tikros atakos persikelia per sluoksnius.
„Xygeni“ sujungia šiuos sluoksnius integruotu aptikimu, prioritetų nustatymu ir taisymu nuo pirmojo „git“ perkėlimo į gamybinę aplinką.
| sluoksnis | „Xygeni“ pajėgumai | Ko tai neleidžia |
|---|---|---|
| Originalus kodas | SAST + Dirbtinio intelekto taisymas | Įpurškimas, autentifikavimo klaidos, nesaugus dizainas |
| Priklausomybės | SCA + Kenkėjiškų programų aptikimas + EPSS | Tiekimo grandinės pažeidimai, pažeidžiami paketai |
| Paslaptys | Paslapčių saugumas + automatinis atšaukimas | Kvalifikacijos stoka, ilgalaikė žetonų rizika |
| IaC & Konfigūracija | IaC Security | Neteisingos konfigūracijos prieš pasiekiant gamybą |
| CI/CD Pipeline | CI/CD Saugumas + anomalijų aptikimas | Pipeline injekcija, bėgiko kompromisas |
| Sukurkite artefaktus | Build Security + SLSA provenance | Sugadinti artefaktai, nepasirašyti leidimai |
| Rizikos pozicija | ASPM | Vieningas vaizdas, kelių sluoksnių prioritetizavimas |
Rezultatas: saugumo komandos gauna signalą, o ne triukšmą. Kūrėjai gauna atsiliepimus ten, kur dirba, o ne atskirame įrankyje, kurio niekada neatidaro. Ir saugumas tampa pristatymo proceso dalimi, o ne vartais, kurie jį sulėtina.
Baigiamosios mintys
Debesijos saugumo patarimus lengva išvardyti, bet sunkiau įgyvendinti. Komandos, kurios mažina realią debesijos riziką, nesiremia rankinėmis peržiūromis, išsklaidytais įrankiais ar tik pagal svarbą nustatomu prioritetu. Vietoj to, jos automatizuoja saugumo kontrolę viduje. pipelineprioritetus nustatyti pagal išnaudojimo galimybes ir visą programinės įrangos tiekimo grandinę traktuoti kaip debesijos atakų paviršiaus dalį.
Tai reiškia daugiau nei vykdymo laiko infrastruktūros apsaugą. Tai reiškia šaltinio kodo, priklausomybių, paslapčių apsaugą. IaC, CI/CD darbo eigas, kūrimo artefaktus ir programų rizikos vertinimą kartu.
Jei jūsų dabartiniai įrankiai palieka tarpų tarp šių sluoksnių, „Xygeni“ padeda juos užpildyti integruotu aptikimu, prioritetų nustatymu ir taisymu visame kelyje nuo kodo iki debesies.
👉 Pradėkite nemokamą 7 dienų bandomąją versiją , kreditinės kortelės nereikia, nuskaitymo rezultatai gaunami per kelias minutes
👉 Kontaktas ir pažiūrėkite, kaip „Xygeni“ susieja jus su konkrečiu debesiu ir pipeline nustatymas
Apie Autorius:
Vienas iš įkūrėjų ir CTO
Fatima Said specializuojasi kūrėjams skirto turinio srityje, skirto programėlių saugumui (AppSec), „DevSecOps“ ir kt. software supply chain securityJi sudėtingus saugumo signalus paverčia aiškiomis, veiksmingomis gairėmis, kurios padeda komandoms greičiau nustatyti prioritetus, sumažinti triukšmą ir pateikti saugesnį kodą.
