AppSec жүйесіндегі автоматты түзету - бұл қолмен араласусыз әзірлеу жұмыс процесінде осалдықтарды автоматты түрде анықтау және түзету процесі. Қазіргі заманғы бағдарламалық жасақтама топтары үшін бұл келесі қадам сияқты көрінеді. Артта қалған жұмыстар көбейе береді, шығарылым циклдары қысқара береді және аз ғана ұйымдар әрбір SAST табу, тәуелділік мәселесі, құпия ақпараттың ағып кетуі немесе IaC дұрыс конфигурацияланбаған, толығымен қолмен түзету кезегіне.
Дегенмен, бір қиындық бар. Командалар қалайды осалдықтарды түзету жылдамырақ, бірақ олар регрессияларды тыныш енгізетін, тәуелділіктерді бұзатын немесе тұрақсыздық тудыратын автоматтандыруды қаламайды CI/CDБұл шиеленіс қазір қолданба қауіпсіздігіндегі негізгі мәселелердің бірі болып табылады. OWASP айқын түрде қарастырады CI/CD өзіндік негізгі тәуекел санаттары бар қауіпсіздік саласы ретінде, ал NIST қауіпсіз бағдарламалық жасақтаманы әзірлеу құрылымы қауіпсіз әзірлеу тәжірибелерін біріктіру қажет екенін анық көрсетеді SDLC соңында бекітілгеннің орнына.
Сондықтан автофикс тек өнімнің ерекшелігі ғана емес. Бұл жұмыс моделі. Нашар орындалған кезде шу, қауіп және бұзылған құрылымдар пайда болады. Жақсы орындалған кезде анықтау мен қалпына келтіру арасындағы алшақтықты жояды, түзету уақытын қысқартады және қауіпсіздікті DevOps жылдамдығына сәйкестендіруге көмектеседі. Бұл нұсқаулықта біз автоматты түзетудің шын мәнінде нені білдіретінін қарастырамыз. AppSec, қай жерде істен шығады, қауіпсіз автоматтандырылған қалпына келтіру қандай болуы керек және оны әзірлеушілер шынымен сенетіндей етіп қалай енгізу керек.
AppSec бағдарламасында автотүзету дегеніміз не?
Негізгі деңгейде, автофикс бағдарламалық жасақтама қауіпсіздік мәселесін анықтаудан да көп нәрсе істейді дегенді білдіреді. Ол түзетуді ұсынады, жасайды немесе қолданады. Басқаша айтқанда, құрал «міне, мәселе осында» дегеннен «міне, шешім осында» дегенге ауысады.
Бұл қарапайым болып көрінгенімен, іс жүзінде ол бірнеше түрлі жұмыс процестерін қамтиды.
In SAST, автотүзету әдетте SQL инъекциясы, сайтаралық скрипттеу, қауіпті десерлиздеу үлгілері, әлсіз енгізу валидациясы немесе қауіпсіз емес аутентификация логикасы сияқты осалдықтарға код деңгейіндегі өзгерістерді жасауды білдіреді. SCA, бұл әдетте тәуелділік жаңартуларын ұсынуды немесе қолдануды, қауіпсіз нұсқаларды бекітуді немесе жасауды білдіреді pull requests пакеттерді патчталған шығарылымдарға жылжытады. Ішінде Құпиялар қауіпсіздігі, автотүзету тіркелгі деректерін тек белгілеу ғана емес, оларды қайтарып алу және бұру дегенді білдіруі мүмкін. IaC, бұл қауіпсіз емес Terraform, Kubernetes немесе бұлттық конфигурация үлгілерін қауіпсіз әдепкі мәндерге қайта жазуды білдіруі мүмкін.
Маңызды айырмашылық мынада: автоматты түзету кеңеспен бірдей емес. Көптеген қауіпсіздік құралдары жалпы түзетуді ұсына алады. Әзірлеушіге дайын өзгерісті жасай алатындар аз. Бұл түзетуді нақты жеткізу жұмыс процесі арқылы іске қосып, тексеріп, әзірлеушіге бастапқы кодты басқарудағы шолуға болатын өзгеріс ретінде ұсына алатындар әлі де аз.
Бұл айырмашылық маңызды, себебі қазіргі заманғы инженерлік топтар PDF файлдары мен билеттерде жұмыс істемейді. Олар жұмыс істейді pull requests, саясаттар, чектер және pipelines.
Неліктен дәстүрлі қалпына келтіру шаралары кең таралмайды
Автоматты түзетудің мәні ауыр шындықтан басталады: дәстүрлі қалпына келтіру процестері заманауи бағдарламалық жасақтама жеткізуіне дейін масштабталмайды.
Көптеген ұйымдарда сканерлеу жеткілікті. Олардың ажыратымдылығы жеткіліксіз. Статикалық талдау, тәуелділікті сканерлеу, құпия анықтау және инфрақұрылымды тексеру үздіксіз нәтижелер береді. Сонымен қатар, инженерлік топтарға мүмкіндіктерді жеткізу, жеткізу уақытын қысқарту және өндірісті тұрақсыздандырудан аулақ болу қысымы бар.
Нәтижесінде, ашылу мен әрекет арасындағы алшақтық пайда болады.
Біріншіден, қарапайым дабыл көлемі бар. AppSec бағдарламасы неғұрлым жетілген болса, соғұрлым көп нәтижелер шығарады. Бұл әрқашан қауіпсіздікті жақсарта бермейді. Көптеген орталарда бұл жай ғана артта қалушылық тудырады. Xygeni өнім материалдары мұны шу мен басымдық мәселесі ретінде көрсетеді, және бұл құрылымдау кеңірек салалық шындыққа сәйкес келеді: көптеген бағдарламалар тек анықтау емес, басымдық беру қиындықтарға тап болады.
Екіншіден, қолмен түзету жоба бойынша баяу. Әзірлеуші мәселені оқып, сканердің шығысын түсіндіріп, қажет болған жағдайда мәселені қайта жасап, түзетуді жобалап, оны іске асырып, сынақтарды іске қосып, ашуы керек. pull request, және шолуды күтіңіз. Бұл бір маңызды мәселе үшін қолайлы болуы мүмкін. Бұл жүздеген орташа ауырлықтағы зерттеулер, қайталанатын тәуелділік жаңартулары немесе бірнеше репозиторийлердегі қайталанатын құпия ақпараттың ағып кетуі үшін қолайлы емес.
Үшіншіден, қауіпсіздік пен инженерия көбінесе әртүрлі нәтижелерге оңтайландырады. Қауіпсіздік тәуекелдің азаюын қалайды. Инженерия өзгерістердің қауіпсіз және болжамды түрде енгізілуін қалайды. Бұл айырмашылықты зерттеу нәтижелері аз болған кезде басқаруға болады. Командалар мәселелерге толы болғанда және тексерілген зерттеу нәтижелерін қауіпсіз, төмен үйкелісті шешімдерге айналдыратын механизм болмаған кезде ол зиянды болады.
Дәл осы жерде автоматтандыру қажет болып көрінеді. Дегенмен, қажеттіліктің өзі автоматтандыруды қауіпсіз етпейді.
Наив автофиксациясының мәселесі
Барлық автотүзету жақсы автотүзету емес. Шын мәнінде, әзірлеушілердің қауіпсіздік автоматизациясына қарсы көптеген қарсылықтары автоматизацияның өзіне қарсылық емес. Олар нашар автоматизацияға қарсылық.
Автоматты түрде түзету қозғалтқышында әдетте төрт мәселенің бірі болады.
Біріншісі, ол әрбір мәселені бірдей түзетуге болатындай қарастырады. Сканер осал тәуелділікті көреді және жай ғана келесі патчталған нұсқаны ұсынады. Код қозғалтқышы қауіпті үлгіні көреді және консервіленген ауыстыруды ауыстырады. Бұл кейбір қарапайым жағдайларда жұмыс істеуі мүмкін. Ол код базасы, архитектура, орындалу уақыты және тәуелділік графигі маңызды болатын нақты жүйелерде тез істен шығады.
Екіншісі, ол орындалу контекстін елемейді. Оқшауланған дұрыс көрінетін түзету нақты код жолдарына қолданылған кезде маңызды емес, жеткіліксіз немесе қауіпті болуы мүмкін. Бұл пайдалану сигналдарының соншалықты маңызды болуының бір себебі. FIRST EPSS бұрыннан барcisсебебі ауырлықтың өзі осалдықтың жақын арада пайдаланылуы мүмкін екендігінің сенімді көрсеткіші емес. EPSS CVE үшін пайдалану белсенділігінің күнделікті ықтималдығын бағалауды ұсынады, бұл командаларға шектеулі қалпына келтіру мүмкіндігін шабуылға ұшырауы мүмкін нәрсеге шоғырландыруға көмектеседі.
Үшіншісі, қарапайым автотүзету өзгеріс қаупін елемейді. Бұл әсіресе қауіпті SCAТәуелділікті жаңарту CVE-ді жоюы мүмкін және API үйлесімсіздіктерін, жойылған әдістерді, атын өзгерткен кластарды, өзгертілген келісімшарттарды немесе орындалу уақытындағы мінез-құлықтың нәзік өзгерістерін тудыруы мүмкін.
Төртіншісі - шамадан тыс автоматтандыру. Құрал төмен құндылықтағы құралдарды ашқан кезде pull requests, олардың көпшілігі сынақтардан өтпейді немесе біріктіру үйкелісін тудырады, әзірлеушілер оны елемеуді үйренеді. Бұл қалпына келтіру үдеуі емес. Бұл қалпына келтіру спамы.
Демек, дұрыс сұрақ - командалар қалпына келтіруді автоматтандыруы керек пе, жоқ па деген сұрақ емес. Дұрыс сұрақ - қандай автоматтандыру операциялық қиындықтарды арттырмай, тәуекелді азайтады.
Үздіксіз өзгерістер - бұл шынайы сенім мәселесі
Әзірлеушілер автотүзетуге сенбейтіндерін айтқанда, олар көбінесе бір нақты нәрсені айтып отыр: олар оның бір нәрсені бұзбайтынына сенбейді.
Сенім мәселесі тәуелділікті қалпына келтіруде ең айқын көрінеді.
Осал пакетте патчталған нұсқасы болуы мүмкін, бірақ бұл жаңарту қауіпсіз дегенді білдірмейді. Патчталған нұсқа қолданбаңыз пайдаланатын әдісті алып тастауы мүмкін. Ол API атауын өзгертуі мүмкін. Ол типтік келісімшартты қатайтуы мүмкін. Ол бірлік сынақтарынан өтетін, бірақ өндірістік регрессияларға әкелетіндей мінез-құлықты өзгертуі мүмкін. Көптеген командаларда қалпына келтірудің нақты құны патчты қолданбау болып табылады. Ол жарылыс радиусын зерттейді.
Java тіліндегі қарапайым мысалды қарастырайық. Код базасы 1.x нұсқасында кең таралған әдіс бар, бірақ 2.x нұсқасында жойылған кітапханаға тәуелді.
Жаңартқаннан кейін, foo() енді жоқ. Осалдық жойылып кетуі мүмкін, бірақ құрастыру бұзылған.
Сондықтан «тек бекітілген нұсқаға жаңарту» инженерлік стратегия емес. Бұл құмар ойын.
OWASP-тар CI/CD нұсқаулық мұнда өзекті, себебі заманауи жеткізу pipelines үдеу механизмдері де, шабуыл беттері де болып табылады. Тұрақсыз немесе бақыланбайтын өзгерістер тудыратын қауіпсіздік басқару элементтері pipeline мінез-құлық бір мәселені шешу арқылы екінші мәселені тудырады. CI/CD Қорғаныс шаралары тек жылдам өзгерістер енгізуді ғана емес, ағынды бақылауды, валидацияны және саясатты орындауды қажет етеді.
Қауіпсіз автоматты түзету осы шындықты құрметтеуі керек. Ол осалдықты түзетуге болатынын ғана емес, сонымен қатар қорғауға арналған бағдарламалық жасақтаманың өмірлік циклін бұзбай түзетуді енгізуге болатынын да түсінуі керек.
Қауіпсіз автотүзету қандай болуы керек
Қауіпсіз автотүзету «автоматты түрде өзгертулер жасау» емес. Қауіпсіз автотүзету бақыланатын автоматтандырылған қалпына келтіру.
Бұл бес нәрсені білдіреді.
Біріншіден, түзетулер контекстке сәйкес келуі керек. Айналадағы кодты, құрылымдық конвенцияларды, деректер ағынын немесе тәуелділік мінез-құлқын елемейтін қауіпсіз ұсыныс жеткіліксіз. Түзету тек осалдық класына ғана емес, қолданбаға да сәйкес келуі керек.
Екіншіден, түзетулер тәуекелді ескеруі керек. Міне, осы жерде қалпына келтіру тәуекелін талдау маңызды. Жақсы автоматты түзету жүйесі өзгеріс ұсынбас бұрын негізгі инженерлік сұраққа жауап бере алуы керек: бұл қалпына келтірудің ықтималдығы қандай күрт өзгерістер?
Үшіншіден, түзетулерге басымдық берілуі керек. Ең жақсы автоматты түзету бағдарламалары бәрін бірден түзетуге тырыспайды. Олар қалпына келтіруді пайдалану мүмкіндігіне, қолжетімділігіне және операциялық әсерге сәйкестендіреді. Бұл жетілген AppSec бағдарламаларының кеңінен дамып келе жатқанына сәйкес келеді. CISA компаниясының белгілі пайдаланылған осалдықтары каталогы бұрыннан барcisұйымдарға пайдалану дәлелдерін қалпына келтіру жұмыстарына қосуға көмектесу үшінcisиондар, тек ауырлық дәрежесін бағалау ғана емес.
Төртіншіден, автоматты түзету нақты жеткізу жұмыс процестерінде орындалуы керек. Егер түзету механизмі жұмыс істей алмаса pull requests, тексерулер, саясаттар және сынақтар, бұл қазіргі заманғы командалардың бағдарламалық жасақтаманы қалай жеткізетініне сәйкес келмейді.
Бесіншіден, әзірлеушілер бақылауда болуы керек. Әзірлеушілер бекіткен өзгерістер автоматты түзетудің әлсіздігі емес. Олар өндірістік инженерлік ортада автоматтандыруды сенімді ететін механизм.
Басқаша айтқанда, қауіпсіз қалпына келтіру тек автоматтандыруды ғана емес, бақылауды да қажет етеді.
Қарапайым автотүзету және қауіпсіз автотүзету
Төменде жұмысты жасайтын автоматтандыру мен оны жоятын автоматтандыру арасындағы практикалық айырмашылық келтірілген.
| Aspect | Қарапайым автотүзету | Қауіпсіз автотүзету |
|---|---|---|
| Түзету стратегиясы | Осалдық анықталғаннан кейін жалпы түзетулерді немесе жаңартуларды қолданады | Кодқа, тәуелділік мінез-құлқына және жұмыс процесін тексеруге негізделген контекстке негізделген түзетулерді жасайды |
| Тәуелділік жаңартулары | Өзгеріс әсерін талдаусыз келесі патчталған нұсқаны ұсынады | Түзетуді ұсынбас бұрын жаңарту жолдарын бағалайды және өзгерістердің бар-жоғын тексереді |
| Басымдылық | Тек ауырлық дәрежесіне қарай әрекет етеді | Ауырлықты пайдалану мүмкіндігімен, қолжетімділікпен және операциялық әсермен біріктіреді |
| Pipeline қауіпсіздік | Құрылымдардан немесе сынақтардан өтпейтін PR-ларды ашуы мүмкін | Түзетулерді тексеру арқылы CI/CD тексерулер және шолу қақпалары |
| Әзірлеуші рөлі | Әзірлеушілер автоматиканың салдарын тазартады | Әзірлеушілер қауіпсіз, біріктіруге дайын қалпына келтіру ұсыныстарын қарап шығады |
| Нәтиже | Шу көбірек, регрессия көбірек, сенім төмендейді | Жылдам қалпына келтіру, аз регрессия, жоғары қабылдау |
Егер сіз осы үстелден бір тағам алғыңыз келсе, ол мынау: автофиксация сапасы оның контексті мен басқару элементтерінің сапасымен анықталады.
Заманауи DevSecOps жүйесінде автотүзету қалай жұмыс істейді Pipeline
Ересек ортада, автотүзету бір әрекет емес. Бұл біріктірілген құрылымдалған қалпына келтіру жұмыс процесі CI/CD.
Қолмен, ажыратылған түзетулердің орнына, заманауи pipelines үздіксіз ағынды бақылайды:
Заманауи DevSecOps жүйесінде автотүзету қалай жұмыс істейді Pipeline
Ересек ортада, автотүзету бір әрекет емес. Бұл біріктірілген құрылымдалған қалпына келтіру жұмыс процесі CI/CD.
Қолмен, ажыратылған түзетулердің орнына, заманауи pipelines үздіксіз ағынды бақылайды:
Автоматты түрде түзету жұмыс процесін кезең-кезеңімен орындау
- Анықтау
Репозиторийлер, pull requests, контейнерлер немесе IaC артефактілер сканерленеді SAST, SCA, Құпиялар немесе инфрақұрылымды тексеру. - Басымдылық
Барлық осалдықтарға бірдей мән берілмейді. Автоматты түзету жүйелері келесілерді пайдалануға басымдық береді:- Қолжетімділікті талдау
- EPSS сияқты пайдалану сигналдары
- Белгілі пайдаланылған осалдықтары (KEV)
- Орналастыру контексті
- Түзету генерациясы
Жүйе мәселенің түріне байланысты келесі түзету әрекеттерін жасайды:- Кодты түзетулер SAST осалдықтар
- Тәуелділікті жаңартулар SCA
- Жасырын түрде қайтарып алу және ротациялау
- IaC конфигурация түзетулері
- Pull Request Жасау
Түзетулер әзірлеушіге тән жұмыс процестеріне, әдетте, келесідей пакеттелген pull requests Бар:- Код айырмашылықтары
- Контекст және негіздеме
- Ұсынылған өзгерістер
- Тексеру уақыты CI/CD
Біріктіру алдында түзетулер автоматты түрде келесі арқылы тексеріледі:- Бірлік және біріктіру тестілері
- Құрылымды тексеру
- Қауіпсіздік саясаты
- Әзірлеуші мақұлдауы және біріктіруі
Әзірлеушілер өндіріске біріктіру алдында өзгерістерді қарап шығады, мақұлдайды немесе қабылдамайды
Нәтижесінде, autofix әзірлеу өмірлік циклін айналып өтпейді, ол оның ішінде жұмыс істейді.
Ол GitHub, GitLab және Azure DevOps сияқты платформалармен үздіксіз интеграцияланады, бұл ... қамтамасыз етеді Осалдықты жою бөлек процесс емес, жеткізу жұмыс процесінің бөлігі болады.
Әртүрлі осалдық кластары үшін автотүзету
Автоматты түзету сұхбатындағы ең көп таралған қателіктердің бірі - барлық түзетулерді бірдей әрекет ететіндей етіп қарастыру. Бірақ олар олай емес.
Автоматты түзету SAST
Код деңгейіндегі автотүзету - көптеген адамдар бұл тұжырымдаманы алғаш рет кездестіретін жер. Сканер SQL инъекциясын, XSS sink-ін немесе қауіпсіз емес валидация үлгісін тауып, қауіпсіз ауыстыруды ұсынады. Бұл көбінесе автотүзетудің ең интуитивті түрі, себебі түзету бастапқы кодта көрінеді және кез келген басқа өзгеріс сияқты қарастырылуы мүмкін.
Xygeni өнім материалдары AI AutoFix жүйесін осы кеңістікте әзірлеушіге дайын түзетулерді жасайтын контекстке бейімделген түзету ретінде орналастырады және pull requests XSS және SQL инъекциясы сияқты мәселелер үшін. Негізгі хабарлама өнім туралы мәлімдемеден тыс маңызды: жақсы SAST autofix тек ережелерді ғана емес, кодты да білуі керек.
Автоматты түзету SCA
Тәуелділікті автоматты түрде түзету операциялық тұрғыдан маңыздырақ, себебі осал пакеттер үнемі пайда болады және тәуелділікті қолмен қолдау масштабталмайды. Бірақ сенімділікке жету ең қиын жер де осы, себебі тәуелділікті жаңартулар дәл сол жерде. күрт өзгерістер ең ауыртпалықты болады.
Сенімді SCA сондықтан автоматты түзету мүмкіндігі патчталған нұсқаны табудан да көп нәрсені істеуі керек. Ол жаңарту қауіпсіздігін, жарылыс радиусын және үйлесімділігін бағалауы керек.
Құпияларды автоматты түрде түзету
Құпияларды қалпына келтіру кодты қайта жазудан гөрі, оны сақтаудан тұрады. Егер нақты құпия ашылып қалса, ең жақсы жауап - келесі аптада біреуден оны ауыстыруды сұрау емес. Ең жақсы жауап - дереу жою, ауыстыру және анық бақылау. Сондықтан құпияларды қорғаудағы автоматты түзету кодты автоматты түзетуден жиі өзгеше көрінеді. Мәні - жылдамдық пен сенімділік.
Автоматты түзету IaC
Инфрақұрылымның дұрыс емес конфигурациялары көбінесе қайталанатын болады. Бұл оларды автоматтандыруға күшті үміткерлер етеді. Егер командалар мұны істей алса standardTerraform, Kubernetes, ARM немесе CloudFormation үшін қауіпсіз үлгілерді орнатыңыз, содан кейін autofix бұл үлгілерді әлдеқайда ертерек қолдана алады pipelineNIST SSDF әрбір қауіпсіздік тәжірибелерін біріктіруге баса назар аударады SDLC енгізу осында тікелей сәйкес келеді: қауіпсіздік жұмыс процесіне енгізілген кезде ең күшті болады, кейінгі кезеңдерге қалдырылмайды.
Автоматты түзету арқылы ғимараттардың бұзылуын қалай болдырмауға болады
Бұл тақырыптың негізгі уәдесі және ол тікелей қарастыруға лайық.
Автоматты түзету арқылы құрастыруларды бұзбау үшін, командалар кез келген басқа өндіріске байланысты өзгерістерді тексерген сияқты түзетуді тексеруі керек. Бұл мынаны білдіреді:
- Өзгерісті қолданар алдында тәуелділік пен кодтың әсерін талдаңыз
- түзетуді растаңыз CI/CD сынақтармен және саясатпен
- жарылыс радиусы жоғары болған кезде автоматтандырылған сәулені шектеу
- материалдық өзгерістер үшін әзірлеушінің шолуын талап етеді
- жоғары әсерлі жаңартулар үшін кезең-кезеңмен енгізуді пайдаланыңыз
Міне, сондықтан қалпына келтіру тәуекелдерін талдау өте құнды. Ол «шешім бар ма?» деген сұрақты «бұл ең қауіпсіз шешім бе?» деп өзгертеді. Бұл әлдеқайда жақсы инженерлік сұрақ.
Сондай-ақ, көптеген автоматтандыру бағдарламалары істен шығады. Олар өнімділікті оңтайландырады және өзгерістер қауіпсіздігін елемейді. Әзірлеушілер мұны бірден байқайды.
Керісінше, сенімді автотүзету жүйесі күшті инженерлік топтар мүмкіндіктерді әзірлеуге қолданатын өзгерістерді басқару тәртібін сақтайды: шолу, тестілеу, тексеру, біріктіру.
Автоматты түзетуді енгізудің ең жақсы тәжірибелері
Егер сіз автоматты түзету бағдарламасын құрып немесе жетілдіріп жатсаңыз, мақсат жаңалық емес, қабылдау болуы керек. Командалар автоматты түзетуді тазалау жұмыстарын жасамай, уақытты үнемі үнемдеген кезде пайдаланады.
Саясаттан бастаңыз. Алдымен қай мәселе кластарын автоматтандыру қауіпсіз екенін шешіңіз. SAST Жақсы түсінікті қайта жазылған үлгілер, анықталған нұсқа диапазондарындағы тәуелділік жаңартулары немесе құпия қайтарып алу жұмыс ағындары көбінесе ерте кезеңде жақсы үміткерлер болып табылады.
Содан кейін ауқымын тарылту. Бір шығарылымда барлығын автоматтандыруға тырыспаңыз. Алдымен кең таралған және жоғары сенімді мәселелерге назар аударыңыз. Бұл әдетте кең ауқымды, бірақ шулы түзету шараларын енгізуден гөрі сенімділікті арттырудың жақсы стратегиясы.
Қалпына келтіруді қолданыстағы әзірлеуші жұмыс процестеріне біріктіріңіз. Егер сіздің инженерлік топтарыңыз тұратын жерде болса pull requests және тармақтарды қорғау, автофикс те болуы керек.
Нәтижелерді өлшеу. Дұрыс көрсеткіштер тек «жасалған түзетулер саны» ғана емес. Олар біріктіру жылдамдығы, регрессия жылдамдығы, үнемделген уақыт, жалған оң нәтижелерді азайту және түзетуге кететін уақыт.
Соңында, маңызды жерде адамның мақұлдау деңгейін сақтаңыз. Қауіпсіз автоматты түзету әзірлеушінің пікірін жоймайды. Ол қайталанатын жұмысты алып тастау және назарды жоғары құнды шолуға шоғырландыру арқылы оны жақсартады.
Анықтаудан қалпына келтіруге дейін: циклды жабу
AppSec құралдарының ескірген нұсқаларының ең үлкен кемшіліктерінің бірі - процесс тым ерте аяқталады. Анықтама пайда болады. Тест жасалады. Содан кейін жүйе күтеді.
Бұл тұйықталған цикл емес. Бұл – ауысу.
Заманауи AppSec бағдарламасы анықтаудан басымдыққа, түзетуге және мүмкіндігінше аз қолмен басқарумен өтуі керек. Бұл автоматты түзетудің нақты уәдесі. Бұл тек түзетуді тездетіп қана қоймайды. Ол түзетудің қай жерде болатынын, қалай енгізілетінін және қайталанатын жұмысты кім орындауы керектігін өзгертеді.
Міне, сондықтан да бұл тақырып тек техникалық тұрғыдан ғана емес, коммерциялық тұрғыдан да маңызды. Сатып алушылар енді тек анықтау сапасын ғана қаламайды. Олар артта қалған жұмыстардың азаюын және мәселені анықтаудан бастап шешуге дейінгі жылдам қозғалысты қалайды.
Xygeni қауіпсіз автотүзетуді қалай қосады
Xygeni материалдары автотүзету мүмкіндігін үш тақырып төңірегінде орналастырады: контекст, автоматтандыру және жеткізу интеграциясы.
Код жағында, Xygeni AI SAST AutoFix әзірлеушіге дайын түзетулерді жасайды, қауіпті үлгілерді қауіпсіз баламалармен ауыстырады және сол түзетулерді жеткізеді pull requests абстрактілі ұсыныстардың орнына. Ол XSS немесе SQL инъекциясы сияқты осалдықтарды бірден түзетеді және қауіпсіз кодтаудың ең жақсы тәжірибелерін әзірлеуші жұмыс процесінде тікелей қолданады.
Дегенмен, Xygeni-дегі автофиксация одан да асып түседі SAST. Оған да кіреді Құпияларды автоматты түрде түзету, ол ағып кеткен тіркелгі деректерін анықтайды және оларды алдын ала орнатылған функцияны пайдаланып автоматты түрде жояды playbooks AWS, GCP немесе GitLab сияқты платформаларда. Бұл дереу оқшаулауға мүмкіндік береді, қолмен жауап беру кідірістерін болдырмайды және тіркелгі деректерін теріс пайдалану қаупін азайтады.
Тәуелділік жағынан, Xygeni's SCA Автоматты түзету осал тәуелділіктерді түзету және оларды ауқымды түрде қолдану арқылы жаппай автоматты түрде қалпына келтіруді қамтамасыз етеді. Командалар автоматтандырылған патчтарды іске қоса алады, жасай алады pull requests жаңартылған нұсқаларымен және қалпына келтіруді тікелей біріктіріңіз CI/CD pipelineжеткізуді үзбей.
Сонымен қатар, бұл мүмкіндіктер мыналарға дейін кеңейтіледі Инфрақұрылым код ретінде (IaC) және pipeline конфигурацияларды, дұрыс емес конфигурациялар мен қауіпті инфрақұрылым үлгілерінің де сол автоматтандырылған жұмыс процесінің бөлігі ретінде түзетілуін қамтамасыз ету.
Бұл стратегиялық мәселе. Қауіпсіз автотүзету оқшауланған түрде жұмыс істемейді. Ол ... қамтиды код (SAST), тәуелділіктер (SCA), құпиялар және инфрақұрылым (IaC), бүкіл бағдарламалық қамтамасыз ету тізбегінде бірізді қалпына келтіруді қамтамасыз етеді. Сонымен қатар, ол пайдалану мүмкіндігіне негізделген басымдық берумен, тәуелділік графигін талдаумен және т.б. үйлескенде жақсы жұмыс істейді. CI/CD валидация, сондықтан түзетулер тек автоматтандырылған ғана емес, сонымен қатар қауіпсіз, өзекті және өндіріске дайын.
Жылдам жауап: Autofix көмегімен осалдықтарды қалай қауіпсіз түрде түзетуге болады?
Автоматты түзету арқылы осалдықтарды қауіпсіз түрде түзету үшін командаларға контекстке негізделген түзетулер, пайдалану мүмкіндігіне негізделген басымдық беру, қалпына келтіру тәуекелдерін талдау қажет. CI/CD біріктіру алдында тексеру және әзірлеушінің мақұлдауы.
Қысқа жауап осы.
Одан аз нәрсе автоматтандыру болуы мүмкін, бірақ бұл өндірісте автоматтандыру әзірлеушілері сенетін нәрсе емес.
FAQ
AppSec бағдарламасында автотүзету дегеніміз не?
AppSec жүйесіндегі Autofix - код кемшіліктері, осал тәуелділіктер, ашық құпиялар немесе инфрақұрылымның дұрыс конфигурацияланбауы сияқты қауіпсіздік мәселелеріне түзету өзгерістерін автоматтандырылған түрде жасау және жеткізу.
Автоматты түрде түзету бұзу құрылымдары бола ма?
Иә. Тәуелділік жаңартулары үйлесімсіз өзгерістер енгізгенде, түзетулер қолданба контекстін елемегенде немесе өзгерістер тексерусіз қолданылғанда, Autofix құрастыруларды бұзуы мүмкін.
Регрессиялар жасамай, осалдықтарды автоматты түрде қалай түзетуге болады?
Басқарылатын жұмыс процесінде автотүзетуді пайдаланыңыз: пайдалану мүмкіндігі және қолжетімділігі бойынша басымдық беріңіз, қалпына келтіру қаупін талдаңыз, өзгерістерді растаңыз CI/CDжәне әзірлеушінің мақұлдау қадамын сақтаңыз.
Қауіпсіз автотүзетуді қарапайым автотүзетуден не ерекшелендіреді?
Қауіпсіз автотүзету контекстке, тәуекелге және pipeline-хабардар. Наив автотүзету үйлесімділікті, орындалу уақытына әсерді немесе жұмыс процесін түсінбестен өзгерістерді ұсынады немесе қолданады.
AI автофиксациясы сенімді ме?
Бұл мүмкін, бірақ сенімділік валидация мен басқаруға байланысты. Gartner жасанды интеллект негізіндегі ұйымдарға нақты кеңес береді code security көмекшілер дәстүрлі AST және кодты шолуды теңдестіру басқару элементтері ретінде пайдалануды жалғастыруда, себебі жасанды интеллект оңтайлаушылары өнімділікке, сенімділікке және код сапасына қатысты мәселелерді асыра түзетуі немесе жіберіп алуы мүмкін.
Қорытынды жол
Autofix енді AppSec-те жаңалық емес. Бұл қызметкерлер санын көбейтпей немесе жеткізуді баяулатпай, жұмыстан шығарылған жұмыстарды азайтуы қажет командалар үшін практикалық талапқа айналуда.
Нағыз қиындық қалпына келтіруді автоматтандыру керек пе, жоқ па, сонда емес. Мәселе, сол автоматтандыру бағдарламалық жасақтаманың қалай жасалғаны мен жеткізілетінін ескере ме, жоқ па, сонда.
Егер сіздің автотүзету стратегияңыз контекстті, басымдықты және валидацияны елемесе, ол құндылықтан гөрі көбірек үйкеліс тудырады. Егер ол әзірлеуші жұмыс процестеріне, қалпына келтіру тәуекеліне және CI/CD басқару нүктелері арқылы қауіпсіздік нәтижелерін де, инженерлік жылдамдықты да айтарлықтай жақсарта алады.
Бұл standard мақсат қоюға тұрарлық.
Автор туралы
Құрылтайшы және техникалық директор
Фатима Said AppSec, DevSecOps және басқа да бағдарламалар үшін әзірлеушіге арналған мазмұнға маманданған. software supply chain securityОл күрделі қауіпсіздік сигналдарын командаларға жылдамырақ басымдық беруге, шуды азайтуға және қауіпсіз кодты жеткізуге көмектесетін анық, іс жүзінде қолдануға болатын нұсқаулыққа айналдырады.
