Google SLSA (бағдарламалық қамтамасыз ету артефактілері үшін жеткізу тізбегі деңгейлері) құрылымын енгізді, ол әзірлеу инфрақұрылымын код жазу, өнімді сынау, құрастыру және тарату сатысында жасалған шабуылдардан қорғаудағы бар тәжірибені қорытындылайды.
Әзірлеу процестері барған сайын күрделене түсуде және үшінші тарап құралдарына тәуелді болып келеді, бұл түпкілікті өнімдегі осалдықтарды анықтауға және пайдалануға емес, әзірлеу процесінің өзіне зиян келтіруге байланысты шабуылдарды ілгерілету үшін қолайлы жағдайлар жасайды (әдетте, жеткізу тізбегі шабуылдары кодты жазу процесіне зиянды өзгерістер енгізу, бөлінген компоненттер мен тәуелділіктерді ауыстыру).
Рамка кодты әзірлеу, құрастыру, сынау және өнімді тарату сатысында зиянды өзгерістер енгізу қаупімен байланысты шабуылдардың 8 түрін ескереді.
- A. осалдықтарға әкелетін бэкдорды немесе жасырын қателерді қамтитын бастапқы кодтағы өзгерістерді қоса.
Шабуылдың мысалы: «Екіжүзділік жасайды» - Linux ядросына осалдықтары бар патчтарды жылжыту әрекеті.
Ұсынылатын қауіпсіздік әдісі: екі әзірлеушінің әрбір өзгертуге тәуелсіз шолуы.
- B. Бастапқы кодты басқару платформасының компромиссі.
Шабуылдың мысалы: әзірлеуші құпия сөздері ағып кеткеннен кейін PHP жобасының Git репозиторийіне бэкдор арқылы зиянды әрекеттерді енгізу.
Ұсынылатын қорғау әдісі: кодты басқару платформасының қауіпсіздігін арттыру (PHP жағдайында шабуыл аз пайдаланылған HTTPS интерфейсі арқылы жүзеге асырылды, бұл SSH кілтін тексермей-ақ құпия сөзді пайдаланып жүйеге кіру кезінде өзгертулерді жіберуге мүмкіндік берді. құпия сөздерді хэштеу үшін сенімсіз MD5 пайдаланылғаны).
- C. Құрылымға немесе үздіксіз интеграциялық жүйеге кодты тасымалдау сатысында өзгертулер енгізу (репозиторийден кодқа сәйкес келмейтін код құрастырылған).
Шабуылдың мысалы: құрастыру инфрақұрылымына өзгерістер енгізу арқылы Webmin ішіне бэкдорды енгізу, нәтижесінде репозиторийдегі файлдардан ерекшеленетін код файлдары қолданылады.
Ұсынылған қорғау әдісі: Тұтастығын тексеру және құрастыру серверіндегі код көзін анықтау.
- D. Құрастыру платформасының ымыраға келуі.
Шабуылдың мысалы: SolarWinds шабуылы, оның барысында құрастыру кезеңінде SolarWinds Orion өніміне бэкдор орнату қамтамасыз етілді.
Ұсынылған қорғау әдісі: құрастыру платформасы үшін кеңейтілген қауіпсіздік шараларын енгізу.
- E. Төмен сапалы тәуелділіктер арқылы зиянды кодты жылжыту.
Шабуылдың мысалы: зиянсыз тәуелділікті қосу және содан кейін осы тәуелділіктің жаңартуларының біріне зиянды кодты қосу арқылы танымал оқиғалар ағыны кітапханасына бэкдорды енгізу (зиянды өзгерту git репозиторийінде көрсетілмеді, бірақ болды. дайын MNP пакетінде ғана бар).
Ұсынылатын қорғау әдісі: барлық тәуелділіктерге SLSA талаптарын рекурсивті түрде қолданыңыз (оқиғалар ағыны жағдайында тексеру негізгі Git репозиторийінің мазмұнына сәйкес келмейтін кодтың жинағын анықтайды).
- F. CI/CD жүйесінде жасалмаған артефактілерді жүктеп салу.
Шабуылдың мысалы: CodeCov сценарийіне зиянды кодты қосу, ол шабуылдаушыларға тұтынушылардың үздіксіз интеграциялық жүйе орталарында сақталған ақпаратты шығаруға мүмкіндік берді.
Ұсынылған қорғау әдісі: артефактілердің көзі мен тұтастығын бақылау (CodeCov жағдайында codecov.io веб-сайтынан жіберілген Bash Uploader сценарийі жоба репозиторийіндегі кодқа сәйкес келмейтіні анықталуы мүмкін).
- G. Пакет репозиторийінің компромиссі.
Шабуылдың мысалы: зерттеушілер зиянды бумаларды тарату үшін кейбір танымал бума репозиторийлерінің айналарын орналастыра алды.
Ұсынылатын қорғау әдісі: таратылған артефактілердің жарияланған бастапқы кодтардан құрастырылғанын тексеру.
- H. Қате буманы орнату үшін пайдаланушыны шатастыру.
Шабуылдың мысалы: жазбаша түрде танымал қолданбаларға ұқсас репозитарийлерге пакеттерді орналастыру үшін typosquatting (NPM, RubyGems, PyPI) пайдалану (мысалы, кофе сценарийінің орнына кофе-скрипт).
Белгіленген қауіптерді блоктау үшін SLSA ұсыныстар жинағын, сонымен қатар аудит метадеректерін жасауды автоматтандыру құралдарын ұсынады. SLSA жалпы шабуыл әдістерін қорытындылайды және қауіпсіздік деңгейлері тұжырымдамасын енгізеді. Әрбір деңгей әзірлеу кезінде пайдаланылатын артефактілердің тұтастығын қамтамасыз ету үшін белгілі бір инфрақұрылымдық талаптарды қояды. Қолдау көрсетілетін SLSA деңгейі неғұрлым жоғары болса, соғұрлым көп қорғаулар орындалады және инфрақұрылым жалпы шабуылдардан жақсырақ қорғалады.
- SLSA 1 құрастыру процесінің толық автоматтандырылуын және көздер, тәуелділіктер және құрастыру процесі туралы ақпаратты қоса, артефактілер қалай құрастырылатыны туралы метадеректерді («дәлелділік») жасауды талап етеді (тексеруге арналған мысал метадеректер генераторы GitHub әрекеттері үшін берілген). SLSA 1 зиянды модификациялардан қорғау элементтерін қамтымайды, бірақ жай ғана кодты анықтайды және осалдықты басқару және тәуекелді талдау үшін метадеректерді береді.
- SLSA 2 - түпнұсқалығы расталған метадеректерді жасайтын нұсқаларды басқару және құрастыру қызметтерін пайдалануды талап ету арқылы бірінші деңгейді кеңейтеді. SLSA 2 пайдалану кодтың шығу тегін қадағалауға мүмкіндік береді және сенімді құрастыру қызметтері жағдайында кодқа рұқсатсыз өзгертулерді болдырмайды.
- SLSA 3 - бастапқы код пен құрастыру платформасының кодты тексеру мүмкіндігіне кепілдік беретін және ұсынылған метадеректердің тұтастығын қамтамасыз ететін стандарттар талаптарына сәйкес келетінін растайды. Аудиторлар платформаларды стандарттар талаптарына сәйкес сертификаттай алады деп болжанады.
- SLSA 4 алдыңғы деңгейлерді келесі талаптармен толықтыратын ең жоғары деңгей болып табылады:
- Барлық өзгертулерді екі түрлі әзірлеушілермен міндетті түрде қарау.
- Барлық құрастыру қадамдары, код және тәуелділіктер толығымен жариялануы керек, барлық тәуелділіктер бөлек шығарылып, тексерілуі керек және құрастыру процесі офлайн режимде орындалуы керек.
- Қайталанатын құрастыру процесін пайдалану құрастыру процесін өзіңіз қайталауға және орындалатын файлдың берілген бастапқы кодтан құрастырылғанына көз жеткізуге мүмкіндік береді.
Ақпарат көзі: opennet.ru