Уводзіны ў абарону ланцужкоў паставак праграмнага забеспячэння з NIST SP 800-204D

Build SecurityПрактычнае кіраўніцтва па абароне ланцужкоў паставак праграмнага забеспячэння з выкарыстаннем NIST SP 800-204D

Змест

Воблачныя праграмы, якія складаюцца з розных незалежных кампанентаў, вядомых як мікрасэрвісы, ствараюцца з выкарыстаннем гнуткага падыходу да распрацоўкі праграмнага забеспячэння пад назвай DevSecOps, які робіць акцэнт на супрацоўніцтве і бяспецы на працягу ўсяго працэсу.

Адным з найважнейшых аспектаў распрацоўкі воблачных прыкладанняў з'яўляецца выкарыстанне бесперапыннай інтэграцыі/бесперапыннай дастаўкі (CI/CD) pipelineс. Гэтыя pipelineдазваляюць распрацоўшчыкам бесперашкодна інтэграваць новыя змены ў код і пастаянна выпускаць абнаўленні для праграмы. Аднак нядаўнія даследаванні падкрэслілі важнасць уліку ўсяго жыццёвага цыклу распрацоўкі праграмнага забеспячэння (SDLC), вядомая як ланцужок паставак праграмнага забеспячэння (SSC), адносна бяспекі.

У пастаянна зменлівым ландшафце распрацоўкі праграмнага забеспячэння і бяспекі вельмі важна апярэджваць патэнцыйныя пагрозы. Вось чаму Нацыянальны інстытут StandardНацыянальны інстытут стандартаў і тэхналогій (NIST) зрабіў значны крок, апублікаваўшы NIST SP 800-204D, уключаючы software supply chain security (SSCS) меры ў CI/CD pipelineГэты дакумент заснаваны на падмурку структуры бяспечнай распрацоўкі праграмнага забеспячэння (SSDF), таксама выпушчанай NIST.

Для арганізацый, якія імкнуцца палепшыць бяспеку сваіх ланцужкоў паставак, гэты новы рэсурс ад NIST з'яўляецца своечасовым і каштоўным актывам. У апошнія гады мы сталі сведкамі шматлікіх складаных спробаў узламаць ланцужкі паставак праграмнага забеспячэння, што падкрэслівае вострую неабходнасць паляпшэння мер бяспекі. Ашаламляльныя 82% кіраўнікоў інфармацыйных службаў выказалі занепакоенасць з нагоды ўразлівасці сваіх ланцужкоў паставак праграмнага забеспячэння да патэнцыйных нападаў.

Калі вы турбуецеся аб бяспецы вашага ланцужка паставак, важна памятаць, што многія арганізацыі падзяляюць гэтыя праблемы і шукаюць спосабы зніжэння рызык і ўмацавання сваіх ланцужкоў паставак праграмнага забеспячэння. Давайце больш падрабязна разгледзім стратэгіі і меркаванні па інтэграцыі. SSCS меры ў вашу штодзённую дзейнасць DevOps.

Перш за ўсё, вельмі важна вызначыць атаку на ланцужок паставак і канкрэтныя Software Supply Chain Security Пагрозы, якія ўзнікаюць на этапе крыніцы.

SSCS і CI/CD Pipelines: Сэрца DevSecOps

Бесперапынная інтэграцыя і бесперапыннае разгортванне (CI/CD) Pipelineрэвалюцыянізавалі працэс распрацоўкі праграмнага забеспячэння, выступаючы ў якасці асновы гнуткай парадыгмы DevSecOps. Гэтыя pipeline— гэта складаныя сістэмы, якія апрацоўваюць код з розных крыніц, у тым ліку з уласных рэпазіторыяў і старонніх рэпазіторыяў з адкрытым зыходным кодам або камерцыйных. 

Працэс будаўніцтва ўнутры гэтых pipelines — гэта складаны танец залежнасцей, кіраваных логікай прыкладання, які генеруе зборкі з мноства асобных артэфактаў зыходнага кода. Пасля стварэння гэтых артэфактаў яны захоўваюцца ў спецыяльных рэпазітарыях зборак, праходзяць дбайнае тэставанне перад упакоўкай. Гэтыя пакеты захоўваюцца ў пэўных рэпазітарыях, правяраюцца на наяўнасць уразлівасцей і, нарэшце, разгортваюцца ў тэставых або прадукцыйных асяроддзях. Такія платформы, як працоўныя працэсы GitHub Actions, GitLab Runners і Buildcloud, падтрымліваюць гэтыя працоўныя працэсы.

Для бяспекі SSC у гэтых працоўных працэсах вельмі важна стварыць шырокія дадзеныя аб паходжанні. Гэтыя дадзеныя забяспечваюць адсочванне і падсправаздачнасць на працягу ўсяго працэсу. pipeline, выступаючы ў якасці маяка празрыстасці. Важна ўлічваць як унутраныя практыкі бяспекі SSC для праграмнага забеспячэння ўласнага вытворцы, так і практыкі бяспекі адносна праграмных модуляў трэціх бакоў. Асноўныя мэты дзве: 

  • Укараняць ахоўныя меры для прадухілення ўмяшання ў працэсы вытворчасці праграмнага забеспячэння і стрымлівання ўвядзення абнаўленняў шкоднаснага праграмнага забеспячэння.
  • Захоўваць цэласнасць CI/CD pipeline артэфакты і дзеянні, вызначаючы ролі і паўнамоцтвы для ўсіх удзельнікаў, якія ўдзельнічаюць у pipeline.

Інфраструктура DevOps: аснова CI/CD

Інструменты і тэхналогіі, якія ляжаць у аснове аперацый DevOps, з'яўляюцца ціхімі рабочымі конямі бесперапыннай інтэграцыі. Іх канфігурацыя і абслугоўванне маюць першараднае значэнне для бяспекі і цэласнасці ўсёй сістэмы. CI/CD працэс. Рэгулярныя аўдыты і абнаўленні гэтых інструментаў не падлягаюць абмеркаванню, каб гарантаваць праактыўнае ўхіленне ўразлівасцей.

Аўтаматызаваныя сканеры ўразлівасцяў сталі неацэннымі саюзнікамі ў гэтай справе. Дзякуючы пастаяннаму маніторынгу інструментаў і канфігурацый DevOps яны могуць выяўляць патэнцыйныя ўразлівасці або няправільныя канфігурацыі ў рэжыме рэальнага часу. Гэты праактыўны падыход дае ўяўленне аб агульным стане бяспекі асяроддзя DevOps, што дазваляе своечасова прымаць меры па выпраўленні наступстваў.

Акрамя таго, выбар плагінаў у наборы інструментаў DevOps можа істотна паўплываць на бяспеку. Хоць плагіны паляпшаюць функцыянальнасць, яны таксама могуць унесці ўразлівасці, калі іх належным чынам не праверыць. Вельмі важна ацэньваць плагіны на аснове іх рэпутацыі, гісторыі бяспекі і падтрымкі супольнасці. Рэгулярныя агляды і абнаўленні гэтых плагінаў могуць яшчэ больш умацаваць ландшафт бяспекі.

 

Ахова ў CI/CD Pipelines: Не падлягае абмеркаванню

Кожны этап CI/CD pipelineад стварэння кода да яго апрацоўкі commitаперацыі тыпу «pull-push» патрабуюць строгіх мер бяспекі. Бяспечны код commitскладаюць аснову гэтых pipelineс. Забеспячэнне праверкі кода, выяўленне шкоднаснага кода і выкананне рэкамендацый па бяспецы могуць значна знізіць уразлівасці.

Аперацыі pull-push, якія ўключаюць змены кода, павінны быць узмоцнены бяспечнымі механізмамі аўтэнтыфікацыі, такімі як шматфактарная аўтэнтыфікацыя (MFA), каб прадухіліць несанкцыянаваны доступ. Працэсы пабудовы ўнутры pipelineпавінны праводзіцца ў ізаляваных, бяспечных асяроддзях. Выкарыстанне бяспечных агентаў зборкі, рэгулярнае абнаўленне інструментаў зборкі і залежнасцей, а таксама забеспячэнне цэласнасці працэсу зборкі — усё гэта ключавыя крокі ў гэтым кірунку.

Акрамя таго, цэласнасць сертыфікацый і доказаў у сістэмах абнаўлення праграмнага забеспячэння мае вырашальнае значэнне. Праверка сапраўднасці і цэласнасці абнаўленняў праграмнага забеспячэння гарантуе, што яны застануцца непашкоджанымі падчас працэсу разгортвання.

Build Attestations: Вартаўнік CI/CD Працэс

Атэстацыі — гэта незаўважаныя героі ў забеспячэнні бяспекі ланцужка паставак праграмнага забеспячэння. Гэтыя аўтэнтыфікаваныя наборы метададзеных, згенераваныя пэўнымі працэсамі, могуць быць правераны спажыўцамі, што забяспечвае ўзровень даверу і празрыстасці. Паколькі арганізацыі надаюць прыярытэт абароне свайго ланцужка паставак праграмнага забеспячэння, збор метададзеных, звязаных з працэсам зборкі і стварэння праграм, становіцца першарадным.

Метададзеныя працэсу зборкі даюць уяўленне аб інструментах, версіях, канфігурацыях і залежнасцях, якія выкарыстоўваюцца, выступаючы ў якасці плана для зборкі. Падобным чынам, метададзеныя аб стварэнні праграмы даюць звесткі аб выкарыстаных фрэймворках распрацоўкі, бібліятэках і залежнасцях трэціх бакоў. Гэты поўны збор дадзеных прапануе беспрэцэдэнтную бачнасць паходжання і цэласнасці кодавай базы.

Выкарыстоўваючы атэстацыі і старанна збіраючы метададзеныя, арганізацыі могуць значна палепшыць свае software supply chain securityГэты падыход не толькі забяспечвае празрыстасць і праверку, але і закладвае аснову для эфектыўнага маніторынгу, аўдыту і аналізу бяспекі на працягу ўсяго жыццёвага цыклу распрацоўкі праграмнага забеспячэння.

Заключныя заўвагі і наступныя крокі

Нядаўнія аналізы ўразлівасцяў і атак на праграмнае забеспячэнне выявілі актуальную праблему для кампаній, якія распрацоўваюць праграмнае забеспячэнне ў адпаведнасці з парадыгмай гнуткай мадэлі DevSecOps, якая выкарыстоўвае бесперапынную інтэграцыю/бесперапынную пастаўку (CI/CD) pipelineс. Як дзяржаўныя, так і прыватныя арганізацыі цяпер сканцэнтраваны на дзейнасці, якая ахоплівае ўвесь SDLC, якія ў сукупнасці называюць ланцужком паставак праграмнага забеспячэння (SSC).

Цэласнасць кожнай аперацыі ў межах SSC мае першараднае значэнне для яе агульнай бяспекі. Пагрозы гэтай цэласнасці могуць узнікаць з-за злоўжыванняў, якія выкарыстоўваюць уразлівасці, або з-за недаглядаў і недахопаў належнай абачлівасці падчас SDLCУсведамляючы сур'ёзнасць гэтай праблемы, такія ініцыятывы, як Выканаўчы загад (EO) 14028, платформа для распрацоўкі бяспечнага праграмнага забеспячэння (SSDF) NIST і розныя галіновыя форумы, паглыбіліся ў бяспеку SSC, імкнучыся ўзмацніць бяспеку ўсяго разгорнутага праграмнага забеспячэння.

Гэтая павышаная ўвага падкрэслівае неабходнасць прыняцця практычных мер па інтэграцыі гарантый бяспекі SSC у CI/CD pipelineбез праблем. Такая інтэграцыя жыццёва важная для арганізацый, якія эфектыўна вырашаюць пытанні бяспекі SSC пры распрацоўцы і разгортванні воблачных прыкладанняў. Стварэнне магутнай інфраструктуры бяспекі SSC патрабуе ўключэння розных артэфактаў, у тым ліку праграмнага забеспячэння (SBOM) і структуры для атэстацыі праграмных кампанентаў. Паколькі гэтыя спецыфікацыі і патрабаванні працягваюць развівацца дзякуючы сумесным намаганням урадавых і галіновых форумаў, яны застаюцца ключавымі ў фарміраванні будучыні бяспекі SSC.

Гатовы даследаваць тонкасці інтэграцыі SSCS меры ў DevOps? Запампуйце падрабязную працу Xygeni сёння. Паглыбіцеся ў падрабязныя аналітычныя дадзеныя, перадавыя практыкі і практычныя стратэгіі для ўмацавання вашых працэсаў DevOps. Забяспечце сваю каманду ведамі, неабходнымі для іх выкарыстання. SSCS вымярае бездакорна і пракладае шлях software supply chain security. Не прапусціце -Загрузіць зараз.

інструменты-для-аналізу-складання-праграмнага ...
Прыярытэзуйце, ліквідуйце і абараняйце свае праграмныя рызыкі
Атрымайце свой бясплатны рахунак.
Не патрабуецца крэдытная карта.

Забяспечце распрацоўку і пастаўку праграмнага забеспячэння

з пакетам прадуктаў Xygeni