Mākoņa drošības padomi ir noderīgi tikai tad, ja tie novērš reālas nepilnības, kuras uzbrucēji izmanto: publisku S3 segmentu, ko neviens nepamanīja, CI skrējēju ar aizstājējzīmi. AWS atļaujas, nopludināta slepenība būvēšanas žurnālā vai ļaunprātīga atkarība, kas nemanāmi instalēta laikā pipeline Lielāko daļu mākoņa drošības incidentu neizraisa nezināmi draudi. Tos izraisa zināmas ievainojamības, kas nekad netika īstenotas, prioritizētas vai novērstas.
Šajā rokasgrāmatā ir apkopoti 20 praktiski mākoņa drošības padomi, kas sakārtoti pa slāņiem: identitāte, dati, infrastruktūra, programmatūras piegādes ķēde, CI/CD pipelineincidentu atklāšana un reaģēšana. Neatkarīgi no tā, vai jūs aizsargājat vienu mākoņkontu vai vairāku komandu tīklu DevSecOps pipelinešīs kontroles palīdz novērst pārkāpumus, kas faktiski notiek.
Kāpēc mākoņa drošība turpina neizdoties, neskatoties uz tik daudziem mākoņa drošības padomiem
Mākoņdatošanas drošība ir kontroles mehānismu, politiku un rīku kopums, kas aizsargā datus, lietojumprogrammas un infrastruktūru, kas darbojas mākoņvidē. Tā aptver identitāti, tīklu, datus, lietojumprogrammu kodu, atkarības, infrastruktūras konfigurāciju un būvējumu. pipelines.
Iemesls, kāpēc tas turpina neizdoties pat nobriedušām komandām, nav zināšanu trūkums. Tās ir trīs strukturālas problēmas:
- Ātrums pretstatā drošībai. Pipelinevirzās ātri. Vadīklas, kas rada papildu berzi, tiek atspējotas. Komandas, kas pareizi ievieš mākoņa drošību, nepievieno vārtus, bet gan automatizē ieviešanu tieši darbplūsmā.
- Instrumentu fragmentācija. Noslēpumu skenēšana vienā rīkā, SCA citā, IaC trešdaļā. Vienota viedokļa trūkums nozīmē, ka starp pārklājuma slāņiem pastāv atšķirības, un atklājumi nekad netiek korelēti ar reālu risku.
- Modinājuma nogurums. Skeneri, kas dienā atklāj simtiem CVE, apmāca inženierus ignorēt atradumus, tostarp kritiskos. Prioritāšu noteikšana nav izvēles iespēja; tā ir tā, kas nosaka, vai drošība patiešām darbojas.
Tālāk sniegtie mākoņa drošības padomi ir izstrādāti, lai praktiski novērstu šīs nepilnības. Tā vietā, lai mākoņa drošību uzskatītu tikai par izpildlaika problēmu, tie aptver visu piegādes ceļu no koda līdz mākonim.
20 mākoņa drošības padomi:
Identitātes un piekļuves pārvaldības mākoņa drošības padomi
1. Iespējojiet daudzfaktoru autentifikāciju visur
MFA joprojām ir vienīgais augstākais ieguldījumu atdeves rādītājs mākoņdrošībā. Tas nekavējoties novērš akreditācijas datu zādzības uzbrukumus, un uzbrucēji to zina. Jebkurš konts bez MFA ir viegls mērķis.
Ieviesiet daudzfaktoru autentifikāciju (MFA) katrai cilvēka identitātei jūsu mākoņvidēs: izstrādātāju kontos, administratora konsolēs, mākoņpakalpojumu sniedzēju portālos, CI/CD dashboards. Privilēģiju kontiem izmantojiet pret pikšķerēšanu aizsargātas daudzfaktoru autentifikācijas (MFA) (aparatūras atslēgas, piekļuves atslēgas). Laikā balstīti kodi, izmantojot autentifikācijas lietotni, ir minimālais ierobežojums.
2. Pielietojiet vismazākās privilēģijas, īpaši necilvēciskām identitātēm
Mazāko privilēģiju princips ir labi saprotama cilvēkiem. Daļa, ko komandas pastāvīgi nepamana, ir necilvēciskas identitātes: CI/CD pakalpojumu konti, Lambda funkcijas, konteineru darba slodzes, GitHub darbību izpildītāji.
Šīs identitātes uzkrāj aizstājējzīmju atļaujas, jo tās tiek konfigurētas vienreiz un nekad netiek atkārtoti izmantotas. Tās ir arī tieši tas, ko uzbrucēji vērš piegādes ķēdes uzbrukumos, jo tām ir piekļuve noslēpumiem, krātuvēm, ražošanas resursiem un lejupējām sistēmām.
Veiciet pakalpojuma konta atļauju auditu reizi ceturksnī. Noņemiet visu, kas nav izmantots 90 dienu laikā.
3. Aizstājiet ilgstošas darbības akreditācijas datus ar īslaicīgas darbības žetoniem
Statiskās API atslēgas un ilgstoši lietojamie tokeni ir viens no biežākajiem mākoņdatošanas pārkāpumu cēloņiem. Tie iegūst commitievietots repozitorijos, nopludināts CI žurnālos, kopēts Slack un aizmirsts .env faili, pēc tam tie ir derīgi mēnešiem vai gadiem ilgi.
Cik vien iespējams, aizstājiet tos ar īslaicīgiem akreditācijas datiem: AWS STS pieņemtā loma, GCP darba slodzes identitātes federācija, GitHub darbību OIDCJa statiskie akreditācijas dati nav nepieciešami, glabājiet tos noslēpumu pārvaldniekā (Vault, AWS Secrets Manager, Azure Key Vault) un automātiski rotējiet.
4. Ieviesiet piekļuvi tieši laikā paaugstinātām privilēģijām
Pastāvīga administratora piekļuve rada pastāvīgu risku. Pastāvīgas paaugstinātas atļaujas nozīmē, ka viena apdraudēta identitāte ir pietiekama, lai piekļūtu ražošanas videi.
JIT piekļuves sistēmas (AWS IAM Identity Center, GCP Privileged Access Manager, Okta Access Requests) piešķir paaugstinātu piekļuvi pēc pieprasījuma, uz ierobežotu laiku un ar pilniem audita žurnāliem. Izstrādātāji saņem nepieciešamo informāciju tieši tad, kad tā ir nepieciešama. Uzbrucēji neatrod pastāvīgu mērķi.
5. Nodrošiniet nulles uzticēšanos pakalpojumu savstarpējā komunikācijā
Tradicionālie perimetra modeļi pieņem, ka viss tīklā ir uzticams. Mākoņvides ar mikropakalpojumiem, konteineriem un dinamiskām darba slodzēm padara šo pieņēmumu bīstamu.
Nulle uzticība nozīmē, ka katrs pieprasījums tiek autentificēts un autorizēts neatkarīgi no tā izcelsmes. Ieviesiet pakalpojumu savstarpējo autentifikāciju (mTLS, pakalpojumu tīkla identitāte), ieviesiet tīkla politikas darba slodzes līmenī un pēc noklusējuma apstrādājiet iekšējo datplūsmu kā neuzticamu.
Datu aizsardzības mākoņa drošības padomi
6. Šifrējiet visu, ieskaitot iekšējo datplūsmu
Šifrēšana miera stāvoklī (AES-256, pārvaldīta KMS) tagad ir standard prakse. Lielākajai daļai komandu ir atšķirība šifrēšana iekšējās datplūsmas pārsūtīšanas laikā.
VPC ar mikropakalpojumiem un konteineru savstarpēju komunikāciju datplūsma, kas paliek “iekšpusē”, nav principiāli droša. Iekšējai pakalpojumu komunikācijai ieviesiet savstarpēju TLS (mTLS). Izmantojiet pakalpojumu tīklu (Istio, Linkerd) vai nulles uzticamības tīkla slāni, lai to ieviestu automātiski, nevis paļaujoties uz to, ka katra komanda to pareizi konfigurēs.
7. Atklāt un novērst atklātos noslēpumus, pirms tie izplatās
Noslēpums commitIevietots repozitorijā, tas nepaliek slepens. GitHub indeksē publiskās repozitorijus dažu sekunžu laikā. Iekšējās repozitoriji nav imūni — tiklīdz noslēpums ir iekļauts Git vēsturē, tas ir pieejams ikvienam, kam ir piekļuve repozitorijam, tagad vai nākotnē.
Prevencijas slāņi ir svarīgi (pre-commit hooks, IDE spraudņi), bet tie nav pietiekami. Jums ir nepieciešama nepārtraukta skenēšana visās krātuvēs, tostarp vēsturiskajās datnēs commits, CI/CD baļķi, IaC faili un konteinera attēli. Kad tiek atklāts noslēpums, reakcijai jābūt tūlītējai: jāatsauc, jāmaina un jānovērtē, vai tam ir piekļūts laikā starp izpaušanu un atklāšanu.
8. Datu klasificēšana un kontroles piemērošana, pamatojoties uz jutīgumu
Ne visiem datiem jūsu mākoņvidē ir vienāds risks, ja tie tiek atklāti. Visu apstrāde vienādi nozīmē pārmērīgu investīciju kontroles pasākumos zema riska datos un nepietiekamu aizsardzību datiem, kas patiesībā ir svarīgi.
Klasificējiet datus pēc sensitivitātes (publiski, iekšēji, konfidenciāli, ierobežotas piekļuves). Lietojiet piekļuves kontroles un šifrēšanu. standardun audita reģistrēšanas prasības katram līmenim. Automatizējiet klasifikāciju, ja iespējams, manuāla atzīmēšana netiek mērogota.
Infrastruktūras un konfigurācijas drošība
9. Skenēt IaC katru Commit, Ne tikai pirms izvietošanas
Infrastruktūra kā kods ir vieta, kur tiek radītas nepareizas konfigurācijas, nevis ražošanas vidē. Publisks S3 segments, atvērta drošības grupa vai IAM loma ar *:* atļaujas neparādās nejauši. Tās sākas kā rinda Terraform failā vai Kubernetes manifestā, kuru neviens nav atzīmējis.
IaC skenēšana jāveic ik pēc pull request, un atklājumi tika atklāti koda pārskatīšanas darbplūsmā. Skenējiet Terraform, Kubernetes manifestus, CloudFormation, Helm diagrammas, Dockerfiles un CI/CD konfigurācijas.
Ksigēni IaC Security skenē katru atbalstīto formātu katrā commit, sasaista atradumus ar konkrētiem resursiem un integrējas ar jūsu sabiedrisko attiecību darbplūsmu, lai izstrādātāji saņemtu atsauksmes tur, kur viņi strādā, nevis atsevišķā vietā. dashboard tie nekad neatveras. Sākt bezmaksas izmēģinājumu →
10. Drošības politika ir jāuztver kā kods
Manuālas drošības pārskatīšanas netiek mērogotas. To dara politika kā kods.
Izmantojiet tādus rīkus kā OPA (Open Policy Agent) vai Kyverno, lai drošības noteikumus izteiktu kā versiju nodrošinātu, pārbaudāmu kodu. Ieviesiet tos plkst. pipeline līmenī, tāpēc Kubernetes izvietošana ar priviliģēts: patiess vai arī konteiners, kas darbojas kā root lietotājs, automātiski neizdodas veidot. Kad politikas ir iekļautas kodā, tās tiek pārskatītas un uzlabotas tāpat kā jebkurš inženiertehnisks artefakts. Kad tās atrodas dokumentācijā, tās mainās.
11. Ieviesiet drošas konfigurācijas bāzes līnijas un uzraugiet novirzes
Noklusējuma konfigurācijas ir optimizētas ērtībai, nevis drošībai. Mākoņpakalpojumi, konteineru izpildlaiki un pārvaldītie Kubernetes klasteri tiek piegādāti ar iestatījumiem, kas ir viegli lietojami un viegli izmantojami.
Sāciet no CIS Jūsu mākoņpakalpojumu sniedzēja, konteinera izpildlaika un operētājsistēmas etaloni. Kodējiet tos kā politikas kodu, lai tie tiktu automātiski ieviesti. Nepārtraukti uzraugiet novirzes; konfigurācija, kas pagājušajā nedēļā atbilda prasībām, šodien var nebūt atbilstoša pēc ātrām izmaiņām, kas tika ieviestas spiediena ietekmē.
12. Segmentējiet tīklus un ierobežojiet sānu kustību
Plakanās tīkla arhitektūras nozīmē, ka, tiklīdz uzbrucējs apdraud vienu darba slodzi, viņš var sasniegt visu pārējo. Tīkla segmentācija ietver sprādziena rādiusu.
Izmantojiet VPC, apakštīklus un drošības grupas, lai izveidotu izolācijas zonas pēc funkcijas un jutības. Ierobežojiet austrumu-rietumu virziena datplūsmu starp pakalpojumiem, lai tā būtu tikai nepieciešama. Ieviesiet izejošās plūsmas filtrēšanu, jo lielākajai daļai apdraudēto darba slodžu ir jānonāk uzbrucēja kontrolētā serverī, un izejošās plūsmas kontrole ir viena no labākajām iespējām to atklāt vai novērst.
Programmatūras piegādes ķēdes mākoņa drošības padomi
Daži no svarīgākajiem mākoņa drošības padomiem vairs nesākas mākoņpakalpojumu sniedzēja konsolē. Tie sākas agrāk, programmatūras piegādes ķēdē. Atkarības, CI/CD Darbplūsmas, noslēpumi, veidošanas skripti un artefakti var radīt mākoņrisku pirms izvietošanas.
13. Skenējiet katru atkarību, pirms tā nonāk jūsu versijā
Atvērtā pirmkoda pakotnes ir visizplatītākais sākotnējās piekļuves vektors mūsdienu piegādes ķēdes uzbrukumos. 2024. gada Shai-Hulud kampaņa apdraudēja vairāk nekā 830 npm pakotnes. XZ Utils aizmugurējās durvis gandrīz apdraudēja SSH autentifikāciju miljoniem Linux sistēmu. Abos gadījumos ļaunprātīgais kods nonāca, izmantojot parasto atkarību instalēšanas procesu.
pamata SCA (Programmatūras sastāva analīze), neapstrādāti CVE saraksti, nav pietiekami. Kas jums faktiski ir nepieciešams:
- Sasniedzamības analīzeVai jūsu kodā patiešām tiek izsaukta ievainojama funkcija?
- Ļaunprātīgas programmatūras noteikšana: vai šī pakotne uzrāda ļaunprātīgu darbību, apmulsinātus skriptus, negaidītus tīkla izsaukumus, dzīves ciklu hooks kas instalē ārējas izpildlaika vides?
- EPSS vērtēšanaKāda ir varbūtība, ka šis CVE tiek aktīvi izmantots savvaļā tieši tagad, ne tikai teorētiski?
14. Bloķēt CI/CD Pipelines
CI/CD sistēmām ir piekļuve slepenajiem datiem, mākoņa akreditācijas datiem un ražošanas vidēm. Tās parasti ir arī mazāk aizsargātas nekā ražošanas sistēmas, kurās tās tiek izvietotas.
Kontroles mehānismi, lai nodrošinātu:
- Pieprasīt koda pārskatīšanu jebkādu izmaiņu gadījumā pipeline konfigurācijas faili (.github/darbplūsmas/, Dženkinsfails, Uc)
- Ierobežojiet pašizvietoto skrējēju piekļuvi apstiprinātām krātuvēm, nepārskatīta skrējēju piekļuve ir tiešs ceļš uz akreditācijas datu zādzību.
- Nekad nenododiet noslēpumus kā vienkārša teksta vides mainīgos; izmantojiet noslēpumu pārvaldnieka integrāciju
- Revīzija pipeline žurnālus negaidītām komandām, neparastiem tīkla izsaukumiem vai izpildēm neparedzētās stundās
Ksigēni CI/CD Drošība piespiež guardrails tieši tavā pipeline , bloķējot nedrošas versijas, atklājot ievadītās darbplūsmas un nodrošinot pipeline integritāti katrā posmā. Rezervējiet demonstrāciju →
15. Validējiet būvējuma integritāti un parakstiet artefaktus
Ja uzbrucējs var ievadīt kodu būvēšanas skriptā, modificēt artefaktu pēc kompilācijas vai apdraudēt CI runner, viņš pieder jūsu programmatūras piegādes ķēdei neatkarīgi no tā, cik tīrs ir jūsu pirmkods.
Ieviest būvējuma integritātes kontroles:
- Piespraust visas atkarību versijas un bāzes attēlus precīziem īssavilkumiem, nevis tagiem
- Parakstiet būvējuma artefaktus un pārbaudiet parakstus pirms izvietošanas
- Uzraudzīt negaidītas izmaiņas CI/CD darbplūsmas faili, ievadītās darbplūsmas bija galvenais rādītājs tādos uzbrukumos kā Shai-Hulud
- Ieviesiet SLSA apliecinājumus, lai kriptogrāfiski pierādītu, kas tika izveidots, no kāda avota un ar ko pipeline
Draudu noteikšana un incidentu reaģēšana
16. Centralizējiet reģistrēšanu un izveidojiet pārskatāmību visā kaudzē
Nevar atklāt to, ko neredz. Lielākā daļa mākoņa drošības uzraudzības koncentrējas uz izpildlaika datiem, CloudTrail, VPC plūsmas žurnāliem un GuardDuty. Tas ir nepieciešams, bet nepietiekami.
Uzbrukumi, piemēram, Shai-Hulud un SolarWinds, daļēji izdevās tāpēc, ka kompromitēšana notika jau versijas izveides laikā. pipeline, ilgi pirms kaut kas nonāca ražošanas uzraudzībā. Pilnīgai pārskatāmībai ir nepieciešams pārklājums starp pirmkoda izmaiņām, būvēšanas un artefaktu slāņiem, mākoņa izpildlaiku un API aktivitātēm.
17. Prioritizējiet atklājumus pēc izmantojamības, nevis tikai pēc nopietnības pakāpes
Skeneris, kas nedēļā ģenerē 500 atradumus, apmāca komandas ignorēt atradumus, tostarp kritiskos. Prioritāšu noteikšana ir tas, kas atšķir drošības programmas, kas darbojas, no tām, kas pastāv tikai uz papīra.
Efektīva prioritāšu noteikšana apvieno: sasniedzamību (vai neaizsargātais kods faktiski tiek izpildīts?), atpazīstamību (vai pakalpojums ir pieejams internetā?), EPSS rādītāju (aktīvas izmantošanas varbūtību) un biznesa kontekstu (ražošanas vai izstrādes vide).
Xygeni ASPM apvieno visus atklājumus SAST, SCA, IaC, noslēpumi un pipeline security vienotā riska skatā ar kontekstuālu prioritāšu noteikšanu, kas norāda jūsu komandai tieši to, kas vispirms jālabo. Rezervējiet demonstrāciju →
18. Nosakiet uzvedības bāzes līnijas un brīdiniet par novirzēm
Zināmi slikti signatūru signatūras uztver zināmus draudus. Uzvedības anomāliju noteikšana uztver nezināmus draudus, nulles dienas apdraudējumus, jaunus uzbrukumu modeļus un iekšējos draudus.
Jūsu CI/CD videi specifiski, nosakiet tipiskā būvēšanas ilguma, parasto pakotņu instalēšanas modeļu, paredzamo tīkla galamērķu būvēšanas laikā bāzes līnijas un standard noslēpumu piekļuves modeļi. Novirzes no šīm bāzes līnijām ir jūsu agrākais brīdinājuma signāls un slānis, kurā lielākajai daļai komandu nav nekādas redzamības.
19. Definējiet izpildes grāmatas mākonim specifiskiem incidentu scenārijiem
Vispārīgie incidentu reaģēšanas plāni neņem vērā mākonim specifiskus scenārijus: kompromitētu pakotni, kas jau ir instalēta 40 pakalpojumos, CI palaistāju ar akreditācijas datiem, ko nozadzis ļaunprātīgs pirmsinstalēšanas skripts, būvējuma artefaktu, kas, iespējams, ir manipulēts pēdējo 72 stundu laikā.
Izveidojiet īpašas izpildes grāmatas: apdraudētām atkarībām, pipeline akreditācijas datu zādzība, nepareizas konfigurācijas izraisīta datu izpaušana un ļaunprātīga CI darbplūsmas injekcija. Katrai izpildes grāmatai ir jādefinē, kam pieder atbilde, kas tiek nekavējoties atsaukts un kāda forenzika ir nepieciešama, lai noteiktu sprādziena rādiusu.
20. Skrien galda vingrojumuscises, vismaz divas reizes gadā
Nepārbaudīta izpildes grāmata ir hipotēze. Galda vingrinājumi.cisatklāj jūsu reaģēšanas plāna nepilnības, pirms to izdara uzbrucējs. Mērķis nav perfekti sekot rīcības plānam, bet gan atklāt, kā trūkst.
Skrieniet vismaz divus vingrinājumuscises gadā, simulējot dažādus scenāriju veidus: piegādes ķēdes kompromitēšanu, nepareizas konfigurācijas izraisītu datu noplūdi, kompromitētu CI administrēšanas sistēmu. Iekļaujiet komandas, kas faktiski reaģēs, drošības, DevOps un dežūrējošus izstrādātājus.
Mākoņa drošības padomu kontrolsaraksts: īsa uzziņa
| slānis | Taustiņu vadīklas |
|---|---|
| Identitāte | MFA visur, vismazākās privilēģijas, īslaicīgas akreditācijas, JIT piekļuve |
| Datums | Šifrēšana miera stāvoklī un pārsūtīšanas laikā, slepeno datu skenēšana un automātiska atsaukšana, datu klasifikācija |
| Infrastruktūras | IaC skenēšana ieslēgta commit, politika kā kods, CIS bāzes līnijas izpilde, tīkla segmentācija |
| Piegādes ķēde | SCA ar sasniedzamību un ļaunprogrammatūras atklāšanu, CI/CD sacietēšana, konstrukcijas integritāte un SLSA |
| Atklāšana | Centralizēta reģistrēšana, uz EPSS balstīta prioritāšu noteikšana, uzvedības anomāliju noteikšana |
| Atbilde | Mākonī izmantojamas izpildes grāmatas, galda virsmas vingrinājumicisdokumentēts sprādziena rādiusa novērtējums |
Kā Xygeni palīdz pielietot mākoņa drošības padomus visā pilnā stekā
Mākoņa drošības padomi darbojas tikai tad, ja komandas var tos konsekventi ieviest visā programmatūras piegādes dzīves ciklā. Lielākā daļa rīku aptver vienu slāni: izpildlaiku, kodu, atkarības, noslēpumus vai CI/CDBet īsti uzbrukumi virzās pāri slāņiem.
Xygeni savieno šos slāņus ar integrētu noteikšanu, prioritāšu noteikšanu un labošanu no pirmā git nosūtīšanas uz ražošanas vidi.
| slānis | Xygeni iespējas | Ko tas novērš |
|---|---|---|
| Pirmkods | SAST + Mākslīgā intelekta korekcija | Injekcija, autentifikācijas kļūmes, nedrošs dizains |
| Atkarīgas | SCA + Ļaunprogrammatūras noteikšana + EPSS | Piegādes ķēdes kompromisi, neaizsargāti iepakojumi |
| Noslēpumi | Noslēpumu drošība + automātiska atsaukšana | Akreditācijas datu iedarbība, ilgstošs žetonu risks |
| IaC & Konfigurācija | IaC Security | Nepareizas konfigurācijas pirms to nonākšanas ražošanā |
| CI/CD Pipeline | CI/CD Drošība + anomāliju noteikšana | Pipeline injekcija, skrējēja kompromiss |
| Veidojiet artefaktus | Build Security + SLSA provenance | Sagrozīti artefakti, neparakstīti izdevumi |
| Riska pozīcija | ASPM | Vienots skats, starpslāņu prioritāšu noteikšana |
Rezultāts: drošības komandas saņem signālu, nevis troksni. Izstrādātāji saņem atgriezenisko saiti tur, kur viņi strādā, nevis atsevišķā rīkā, ko viņi nekad neatver. Un drošība kļūst par piegādes procesa daļu, nevis par vārtiem, kas to palēnina.
Final Domas
Mākoņpakalpojumu drošības padomus ir viegli uzskaitīt, bet grūtāk ieviest. Komandas, kas samazina reālu mākoņpakalpojumu risku, nepaļaujas uz manuālām pārskatīšanām, izkliedētiem rīkiem vai prioritāšu noteikšanu tikai pēc nopietnības līmeņa. Tā vietā tās automatizē drošības kontroles iekšienē. pipelines, prioritizējiet pēc izmantojamības un visu programmatūras piegādes ķēdi uzskatiet par daļu no mākoņa uzbrukuma virsmas.
Tas nozīmē vairāk nekā tikai izpildlaika infrastruktūras nodrošināšanu. Tas nozīmē pirmkoda, atkarību, noslēpumu aizsardzību, IaC, CI/CD darbplūsmas, artefaktu veidošana un lietojumprogrammu riska stāvokļa novērtēšana kopā.
Ja jūsu pašreizējie rīki atstāj atstarpes starp šiem slāņiem, Xygeni palīdz tās aizpildīt, izmantojot integrētu noteikšanu, prioritāšu noteikšanu un korekcijas visā ceļā no koda līdz mākonim.
???? Sāciet 7 dienu bezmaksas izmēģinājumu , kredītkarte nav nepieciešama, skenēšanas rezultāti dažu minūšu laikā
???? Kontaktinformācija un skatiet, kā Xygeni atbilst jūsu konkrētajam mākonim un pipeline iestatīšana
par autoru
Līdzdibinātājs un CTO
Fatima Said specializējas izstrādātājiem paredzētā saturā lietotņu drošības, izstrādes drošības un operāciju (AppSec), kā arī drošības un operāciju (DevSecOps) jomās. software supply chain securityViņa pārvērš sarežģītus drošības signālus skaidrās, praktiski izmantojamās vadlīnijās, kas palīdz komandām ātrāk noteikt prioritātes, samazināt troksni un piegādāt drošāku kodu.
