Habang umuusad ang siklo ng buhay ng supply chain ng software mula sa source code hanggang sa mga executable artifact, ang yugto ng pagbuo ay nagsisilbing isang kritikal na saglit. Gayunpaman, ang yugtong ito ng pagbabago ay madaling kapitan din ng iba't ibang banta na maaaring maglagay sa panganib sa integridad at integridad ng software. build securityAng mga bantang ito ay maaaring makapasok sa proseso ng pagtatayo sa pamamagitan ng iba't ibang pamamaraan, kabilang ang pag-iwas sa itinatag na CI/CD pipeline, pagbabago ng code post-source control, pagkompromiso sa mismong proseso ng pagbuo, o pagmamanipula sa mga artifact repository. Sa blog post na ito, susuriin natin nang malaliman ang mga banta na ito at susuriin ang mga pinakakaraniwang pag-atake sa pagbuo ng supply chain ng software. Ang nilalamang ito ay nagpapatuloy sa aming serye ng blog na nagsasaliksik software supply chain security sa buong SDLC.
Ang Yugto ng Pagbuo sa Siklo ng Buhay ng Pag-develop ng Software
Ang yugto ng pagbuo ng lifecycle ng supply chain ng software ay sumasaklaw sa proseso ng pagbabago ng source code sa mga executable software artifact. Kasama sa yugtong ito ang pag-compile, pag-link, at pag-package ng source code, pati na rin ang pagbuo ng mga installation package at configuration file.
Build security Ang mga banta ay mga kahinaan na maaaring magpahintulot sa isang kalaban na magpakilala ng mga hindi awtorisadong pagbabago sa software habang isinasagawa ang proseso ng pagbuo nang hindi binabago ang source code. Ang mga bantang ito ay maaaring maipakilala sa pamamagitan ng iba't ibang mga pamamaraan, tulad ng pagkompromiso sa build environment o pagsasamantala sa mga kahinaan sa mga build tool.
Mga Pinakakaraniwang Banta sa Supply Chain ng Software - Mga Pag-atake sa Pagbuo
pasikut-sikot CI/CD
Ito ay tumutukoy sa kasanayan ng pag-iwas sa itinatag na CI/CD (tuloy-tuloy na integrasyon at patuloy na paghahatid) pipeline direktang bumuo at maglathala ng software nang hindi sumasailalim sa mahigpit na proseso ng pagsubok, beripikasyon, at pag-awdit na karaniwang ipinapatupad ng opisyal pipelineMagagawa ito sa pamamagitan ng manu-manong pagbuo ng software sa labas ng CI/CD kapaligiran o sa pamamagitan ng paggamit ng mga tool o script na nagpapahintulot sa mga hindi awtorisadong pagbabago sa proseso ng pagbuo. Ang isang halimbawa ng ganitong uri ng vector attack ay ang Pag-atake ni JenkinsNoong 2022, nakapasok ang mga hacker sa build pipeline ng isang sikat na open-source software project na tinatawag na Jenkins. Nagpasok ang mga hacker ng malisyosong code sa isang Jenkinsfile, na isang script na tumutukoy sa proseso ng pagbuo. Pinayagan ng malisyosong code ang mga hacker na malampasan ang CI/CD pipelinemga pagsusuri sa seguridad at inilalagay ang kanilang code sa proseso ng pagbuo. Pagkatapos, ang code na ito ay isinasagawa sa mga sistema ng mga organisasyong nag-install ng software.
Baguhin ang code pagkatapos ng source control
Ang kasanayang ito ay kinabibilangan ng paggawa ng mga hindi awtorisadong pagbabago sa source code pagkatapos itong commitnakakonekta sa isang trusted source control system (SCS) at pagkatapos ay binubuo ang software gamit ang binagong code na ito. Magagawa ito sa pamamagitan ng direktang pagbabago ng code sa workstation ng isang developer o sa pamamagitan ng paggamit ng mga panlabas na tool o script upang magpasok ng malisyosong code sa proseso ng pagbuo. Ang isang halimbawa ng vector attack na ito ay ang GitLab Attack noong 2022. Nakapasok ang mga hacker sa build pipeline of GitLabNaglagay ang mga hacker ng malisyosong code sa GitLab CI/CD pipeline, na isang kagamitan na nag-aautomat ng build security proseso. Ang malisyosong code ay nagbigay-daan sa mga hacker na baguhin ang code pagkatapos itong masuri sa source control. Nagbigay-daan ito sa kanila na ipasok ang kanilang code sa software, na pagkatapos ay ipinatupad sa mga sistema ng mga organisasyong nag-install ng software.
Proseso ng pagbuo ng kompromiso
Kabilang dito ang pagmamanipula o pagbabago sa mismong proseso ng pagbuo, alinman sa pamamagitan ng direktang pag-access sa kapaligiran ng pagbuo o sa pamamagitan ng paggamit ng mga kahinaan sa mga tool sa pagbuo o mga dependency ng ikatlong partido. Magagawa ito upang magpasok ng malisyosong code sa output ng pagbuo, pakialaman ang pinagmulan ng pagbuo, o tuluyang guluhin ang proseso ng pagbuo. Ang pinakatanyag na halimbawa ng vector attack na ito ay ang Pag-atake ng SolarWindsIsang attacker ang nakakuha ng hindi awtorisadong access sa build platform ng SolarWinds, isang sistemang ginagamit para i-compile at i-package ang SolarWinds Orion software. Naglagay ang script na ito ng malisyosong code sa na-compile na SolarWinds Orion software. Nang i-install ng mga user ang nakompromisong software, ang malisyosong code ay ipinapatupad sa kanilang mga system, na nagbibigay sa attacker ng hindi awtorisadong access sa kanilang mga system. Nagawa rin ng attacker na nakawin ang sensitibong data mula sa kanilang mga system, tulad ng mga kredensyal, intelektwal na ari-arian, at impormasyon ng customer.
Repositoryo ng artifact na kompromiso
Ito ay tumutukoy sa hindi awtorisadong pag-access o manipulasyon ng isang artifact repository, kung saan ang mga software package at binary ay nakaimbak para sa pamamahagi sa mga internal o external na user. Maaaring samantalahin ng mga attacker ang kahinaang ito upang magpakilala ng malisyosong code, pakialaman ang pagiging tunay ng software, o guluhin ang proseso ng pag-deploy. Ang isang halimbawa ng vector attack na ito ay Ang RubyGems noong 2022Nakapasok nang palihim ang mga hacker sa imbakan ng artifact ng RubyGems. Pinalitan ng mga hacker ang isang lehitimong artifact ng isang malisyosong artifact, na pagkatapos ay na-download ng libu-libong organisasyon na gumagawa ng software gamit ang Ruby on Rails. Ang malisyosong artifact ay nagbigay-daan sa mga hacker na magpatupad ng arbitraryong code sa mga sistema ng mga organisasyong nag-install ng software. Maaari itong magpahintulot sa kanila na magnakaw ng data, mag-install ng malware, o makagambala sa mga operasyon.
Final Remarks
Habang patuloy na niyayakap ng mga organisasyon ang mga kasanayan sa pagbuo ng software na nagbibigay-diin sa automation at patuloy na paghahatid, ang kahalagahan ng pag-secure ng proseso ng pagbuo ng software ay hindi pa kailanman naging ganito kalaki. Sa pamamagitan ng pagpapatupad ng matibay na mga hakbang sa seguridad sa buong yugto ng pagbuo, maaaring mabawasan nang malaki ng mga organisasyon ang kanilang panganib na maging biktima ng mga malisyosong pag-atake na maaaring makompromiso ang integridad at seguridad ng kanilang software.
Ang mga estratehiyang nakabalangkas sa blog post na ito at ang mga halimbawang ibinigay ay nagsisilbing paalala na ang yugto ng pagbuo ay isang mahinang punto sa supply chain ng software. Dapat bigyang-pansin ng mga organisasyon ang mga bantang ito at ipatupad ang mga kinakailangang hakbang sa seguridad upang protektahan ang kanilang software mula sa pag-atake. Sa pamamagitan nito, masisiguro nila ang integridad, seguridad, at pagiging maaasahan ng kanilang software para sa kanilang mga gumagamit at customer.
Samahan ang Aming Paglalakbay Tungo sa Isang Ligtas na Ekosistema ng Software
Huwag palampasin ang pagkakataong ito upang manatiling nangunguna sa pag-iwas sa mga banta sa supply chain ng software. Mag-subscribe sa aming blog ngayon at maging una na makatanggap ng aming mga pinakabagong pananaw, na tinitiyak na ang iyong organisasyon ay mananatiling matatag at ligtas sa gitna ng mga nagbabagong banta. Sama-sama, makakabuo tayo ng isang mas matatag at ligtas na ecosystem ng software para sa lahat.
Panoorin ang aming Video Demo
