Ipinakilala ng Google ang framework ng SLSA (Supply-chain Levels for Software Artifacts), na nagbubuod sa umiiral nang karanasan sa pagprotekta sa imprastraktura ng pag-unlad mula sa mga pag-atake na isinasagawa sa yugto ng pagsulat ng code, pagsubok, pag-assemble at pamamahagi ng produkto.
Ang mga proseso ng pag-unlad ay nagiging mas kumplikado at umaasa sa mga tool ng third-party, na lumilikha ng mga paborableng kondisyon para sa pagsulong ng mga pag-atake na may kaugnayan hindi sa pagtukoy at pagsasamantala ng mga kahinaan sa panghuling produkto, ngunit sa pagkompromiso sa mismong proseso ng pag-unlad (mga pag-atake sa kadena ng supply, kadalasang naglalayong nagpapakilala ng mga malisyosong pagbabago sa proseso ng pagsulat ng code, pagpapalit ng mga ipinamahagi na bahagi at dependencies).
Isinasaalang-alang ng balangkas ang 8 uri ng mga pag-atake na nauugnay sa banta ng paggawa ng mga nakakahamak na pagbabago sa yugto ng pagbuo ng code, pagpupulong, pagsubok at pamamahagi ng produkto.
- A. Kabilang ang mga pagbabago sa source code na naglalaman ng mga backdoor o mga nakatagong error na humahantong sa mga kahinaan.
Halimbawa ng pag-atake: “Hypocrite Commits” - isang pagtatangka na i-promote ang mga patch na may mga kahinaan sa Linux kernel.
Iminungkahing paraan ng seguridad: independiyenteng pagsusuri ng bawat pagbabago ng dalawang developer.
- B. Pagkompromiso ng source code control platform.
Halimbawa ng pag-atake: pag-iniksyon ng mga malisyosong commit na may backdoor sa Git repository ng isang proyekto sa PHP pagkatapos ma-leak ang mga password ng developer.
Iminungkahing paraan ng proteksyon: Tumaas na seguridad ng platform ng pamamahala ng code (sa kaso ng PHP, ang pag-atake ay isinagawa sa pamamagitan ng isang maliit na ginagamit na interface ng HTTPS, na nagpapahintulot sa mga pagbabago na maipadala kapag nag-log in gamit ang isang password nang hindi sinusuri ang SSH key, sa kabila ng ang katotohanan na ang hindi mapagkakatiwalaang MD5 ay ginamit upang i-hash ang mga password).
- C. Paggawa ng mga pagbabago sa yugto ng paglilipat ng code sa build o tuluy-tuloy na integration system (ang code na hindi tumutugma sa code mula sa repository ay binuo).
Halimbawa ng isang pag-atake: Pag-inject ng backdoor sa Webmin sa pamamagitan ng paggawa ng mga pagbabago sa build infrastructure, na nagreresulta sa paggamit ng mga code file na naiiba sa mga file sa repository.
Iminungkahing paraan ng proteksyon: Sinusuri ang integridad at pagtukoy sa pinagmulan ng code sa server ng pagpupulong.
- D. Kompromiso ng platform ng pagpupulong.
Halimbawa ng pag-atake: ang pag-atake ng SolarWinds, kung saan natiyak ang pag-install ng backdoor sa produkto ng SolarWinds Orion sa yugto ng pagpupulong.
Iminungkahing paraan ng proteksyon: pagpapatupad ng mga advanced na hakbang sa seguridad para sa platform ng pagpupulong.
- E. Pag-promote ng malisyosong code sa pamamagitan ng mababang kalidad na mga dependency.
Isang halimbawa ng pag-atake: ang pagpapakilala ng backdoor sa sikat na event-stream na library sa pamamagitan ng pagdaragdag ng hindi nakakapinsalang dependency at pagkatapos ay pagsasama ng malisyosong code sa isa sa mga update ng dependency na ito (ang malisyosong pagbabago ay hindi ipinakita sa git repository, ngunit ito ay naroroon lamang sa natapos na pakete ng MNP).
Iminungkahing paraan ng proteksyon: recursively ilapat ang mga kinakailangan ng SLSA sa lahat ng dependencies (sa kaso ng event-stream, ipapakita ng check ang assembly ng code na hindi tumutugma sa mga nilalaman ng pangunahing Git repository).
- F. Pag-upload ng mga artifact na hindi nilikha sa CI/CD system.
Halimbawa ng pag-atake: pagdaragdag ng malisyosong code sa CodeCov script, na nagbigay-daan sa mga umaatake na kunin ang impormasyong nakaimbak sa tuluy-tuloy na pagsasama ng mga kapaligiran ng system ng customer.
Iminungkahing paraan ng proteksyon: kontrol sa pinagmulan at integridad ng mga artifact (sa kaso ng CodeCov, maaaring ibunyag na ang script ng Bash Uploader na ipinadala mula sa website ng codecov.io ay hindi tumutugma sa code mula sa repository ng proyekto).
- G. Kompromiso ng imbakan ng package.
Halimbawa ng isang pag-atake: Nagawa ng mga mananaliksik na mag-deploy ng mga salamin ng ilang sikat na mga repository ng package upang maipamahagi ang mga nakakahamak na package sa pamamagitan ng mga ito.
Iminungkahing paraan ng proteksyon: Pag-verify na ang mga ipinamahagi na artifact ay pinagsama-sama mula sa mga ipinahayag na source code.
- H. Nakakalito sa user na mag-install ng maling package.
Halimbawa ng pag-atake: paggamit ng typosquatting (NPM, RubyGems, PyPI) para maglagay ng mga package sa mga repository na katulad ng nakasulat sa mga sikat na application (halimbawa, coffe-script sa halip na coffee-script).
Upang harangan ang mga na-flag na banta, nag-aalok ang SLSA ng isang hanay ng mga rekomendasyon, pati na rin ang mga tool upang i-automate ang paggawa ng metadata ng pag-audit. Binubuod ng SLSA ang mga karaniwang paraan ng pag-atake at ipinakilala ang konsepto ng mga layer ng seguridad. Ang bawat antas ay nagpapataw ng ilang mga kinakailangan sa imprastraktura upang matiyak ang integridad ng mga artifact na ginagamit sa pag-unlad. Kung mas mataas ang sinusuportahang antas ng SLSA, mas maraming proteksyon ang ipinapatupad at mas mahusay na protektado ang imprastraktura mula sa mga karaniwang pag-atake.
- Kinakailangan ng SLSA 1 na ganap na awtomatiko ang proseso ng pagbuo at bumuo ng metadata (“provenance”) tungkol sa kung paano binuo ang mga artifact, kabilang ang impormasyon tungkol sa mga source, dependency, at proseso ng build (isang halimbawang generator ng metadata para sa pag-audit ay ibinibigay para sa GitHub Actions). Ang SLSA 1 ay hindi nagsasama ng mga elemento ng proteksyon laban sa mga nakakahamak na pagbabago, ngunit sa halip ay kinikilala lamang ang code at nagbibigay ng metadata para sa pamamahala ng kahinaan at pagsusuri sa panganib.
- SLSA 2 - pinalawak ang unang antas sa pamamagitan ng pag-aatas ng paggamit ng kontrol sa bersyon at mga serbisyo ng pagpupulong na bumubuo ng napatunayang metadata. Ang paggamit ng SLSA 2 ay nagbibigay-daan sa iyo na masubaybayan ang pinagmulan ng code at maiwasan ang mga hindi awtorisadong pagbabago sa code sa kaso ng mga pinagkakatiwalaang serbisyo ng build.
- SLSA 3 - kinukumpirma na ang source code at ang build platform ay nakakatugon sa mga kinakailangan ng mga pamantayan na ginagarantiyahan ang kakayahang i-audit ang code at matiyak ang integridad ng metadata na ibinigay. Ipinapalagay na maaaring patunayan ng mga auditor ang mga platform laban sa mga kinakailangan ng mga pamantayan.
- Ang SLSA 4 ay ang pinakamataas na antas, na nagdaragdag sa mga nakaraang antas ng mga sumusunod na kinakailangan:
- Mandatoryong pagsusuri ng lahat ng pagbabago ng dalawang magkaibang developer.
- Ang lahat ng mga hakbang sa pagbuo, code, at mga dependency ay dapat na ganap na ipahayag, ang lahat ng mga dependency ay dapat na hiwalay na i-extract at ma-verify, at ang proseso ng pagbuo ay dapat isagawa offline.
- Ang paggamit ng isang paulit-ulit na proseso ng pagbuo ay nagbibigay-daan sa iyong ulitin ang proseso ng pagbuo at tiyaking ang executable ay binuo mula sa ibinigay na source code.
Pinagmulan: opennet.ru