ນີ້ແມ່ນຕອນທີສາມໃນ ບົດຄວາມຊຸດ ກ່ຽວກັບການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງຊອບແວທີ່ແຜ່ຫຼາຍທີ່ສຸດ: ການໂຈມຕີທີ່ລ່ວງລະເມີດການລົງທະບຽນສາທາລະນະຂອງ ເປີດເຜີຍແຫຼ່ງ ອົງປະກອບຊອບແວ. ຫຼັງຈາກການວິເຄາະໃນຕອນກ່ອນໜ້ານີ້ “ການວິພາກຂອງແພັກເກດທີ່ເປັນອັນຕະລາຍ: ແນວໂນ້ມແມ່ນຫຍັງ?"ວິທີທີ່ຜູ້ກະທຳທີ່ບໍ່ດີສັກພຶດຕິກຳທີ່ເປັນອັນຕະລາຍເຂົ້າໃນອົງປະກອບໃໝ່ ຫຼື ອົງປະກອບທີ່ມີຢູ່ແລ້ວ, ພວກເຮົາພ້ອມແລ້ວທີ່ຈະໃສ່ເສື້ອກັນໄຟ ແລະ ກວດສອບວິທີທີ່ພວກເຮົາສາມາດບລັອກຊອບແວທີ່ເປັນອັນຕະລາຍທີ່ສົ່ງມາດ້ວຍວິທີນີ້ຢ່າງສຳເລັດຜົນ, ຫຼື ອີກທາງເລືອກໜຶ່ງ, ຈັດການກັບເຫດການທາງໄຊເບີທີ່ຮ້າຍແຮງທີ່ອາດຈະເກີດຂຶ້ນເພາະວ່າພວກເຮົາໄດ້ໃຊ້ວິທີການທີ່ຜິດ."
ຜູ້ຊ່ຽວຊານສ່ວນໃຫຍ່ທີ່ມີຄວາມຮູ້ກ່ຽວກັບຄວາມປອດໄພມີແນວຄວາມຄິດກ່ຽວກັບວິທີການຈັດການກັບໄພຂົ່ມຂູ່ນີ້. ພວກເຮົາໄດ້ຍິນຜູ້ຈັດການດ້ານຄວາມປອດໄພເວົ້າໂດຍບໍ່ລັງເລໃຈວ່າ SCA ເຄື່ອງມືບອກທ່ານແລ້ວວ່າເວລາໃດທີ່ລຸ້ນແພັກເກດເປັນມັລແວ. ຫຼືວ່າພວກມັນຂຶ້ນກັບອົງປະກອບຊອບແວທີ່ຮູ້ຈັກກັນດີ ແລະ ໄດ້ຮັບການທົບທວນຄືນສູງ, ບ່ອນທີ່ມັລແວໃດໆຈະຖືກກວດພົບ ແລະ ລຶບອອກຢ່າງວ່ອງໄວ. ພວກມັນໃຊ້ລຸ້ນເປີດ/ແພັດຊ໌ເລັກນ້ອຍເພື່ອແກ້ໄຂຄວາມສ່ຽງໂດຍອັດຕະໂນມັດ, ແລະນັ້ນແມ່ນວິທີທີ່ເໝາະສົມ ແລະ ແນະນຳເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງໃນການເພິ່ງພາອາໄສແຫຼ່ງເປີດ, ໂດຍປະຕິບັດຕາມ “ແກ້ໄຂແຕ່ຫົວທີ, ແກ້ໄຂເລື້ອຍໆ” ຫຼັກການ.
ໃນຕອນນີ້, ພວກເຮົາຈະທົບທວນຄືນວ່າເປັນຫຍັງແນວຄວາມຄິດເຫຼົ່ານີ້ຈຶ່ງຜິດ, ແລະຄວາມເຂົ້າໃຈຜິດດັ່ງກ່າວປະກອບສ່ວນເຂົ້າໃນຄວາມນິຍົມຂອງກົນໄກການໂຈມຕີນີ້ແນວໃດ, ແລະຕໍ່ຄວາມສ່ຽງອັນໃຫຍ່ຫຼວງທີ່ອົງກອນຕ່າງໆກຳລັງປະສົບຢູ່. ພວກເຮົາຈະສິ້ນສຸດດ້ວຍສິ່ງທີ່ໄດ້ຜົນ, ແລະອັນໃດແມ່ນຄວາມພະຍາຍາມ ແລະຊັບພະຍາກອນທີ່ກ່ຽວຂ້ອງ.
ຄວາມເຂົ້າໃຈຜິດທົ່ວໄປ
ໃນລະຫວ່າງການເດີນທາງຂອງພວກເຮົາກັບຄວາມປອດໄພຂອງຊອບແວ, ພວກເຮົາໄດ້ເຫັນເຕັກນິກການໂຈມຕີພັດທະນາ ແລະ ແນວຄວາມຄິດທີ່ຫຼາກຫຼາຍຈາກຄົນທີ່ມີສະຕິລະວັງຄວາມປອດໄພ. ອົງກອນຕ່າງໆມັກເຂົ້າໃຈຜິດວ່າສິ່ງໃດເຮັດວຽກໄດ້ຜົນຕໍ່ກັບໄພຂົ່ມຂູ່ນີ້, ສະນັ້ນກ່ອນອື່ນໝົດພວກເຮົາຈະກວດສອບສິ່ງທີ່ບໍ່ໄດ້ຜົນ, ເຊິ່ງຫຍໍ້ລົງໃນບັນຊີລາຍຊື່ຄວາມເຂົ້າໃຈຜິດຕໍ່ໄປນີ້, ບໍ່ແມ່ນທັງໝົດ.
ຄວາມເຂົ້າໃຈຜິດ #1: SCA ເຄື່ອງມືລາຍງານອົງປະກອບທີ່ເປັນອັນຕະລາຍແລ້ວ
ຢ່າງແທ້ຈິງ! ແຕ່ຫຼັງຈາກຄວາມຈິງ... ເມື່ອມັນອາດຈະຊ້າເກີນໄປຖ້າອົງປະກອບດັ່ງກ່າວຖືກນໍາໃຊ້ໃນການສ້າງຊອບແວ, ແລະຜູ້ກະທຳທີ່ບໍ່ດີໄດ້ຮັບບ່ອນຢືນໃນນັກພັດທະນາຫຼືຜູ້ພັດທະນາແລ້ວ CI/CD ໂຮດ. ຄວາມລັບອາດຈະຖືກກັ່ນຕອງອອກ, ມີການດາວໂຫຼດ ແລະ ຕິດຕັ້ງມັນແວເພີ່ມເຕີມ, ແລະ ບາງທີສັດຕູອາດຈະຍ້າຍໄປທາງຂ້າງ ແລະ ສາມາດເຂົ້າເຖິງບ່ອນອື່ນໄດ້ແລ້ວ.
ການວິເຄາະອົງປະກອບຊອບແວ (SCA) ເຄື່ອງມືໄດ້ຖືກອອກແບບມາເພື່ອລະບຸຊ່ອງໂຫວ່ທີ່ອາດຮູ້. ເຄື່ອງມືທີ່ທັນສະໄໝເຮັດວຽກໄດ້ດີຫຼາຍໂດຍການເພີ່ມອັດຕາສ່ວນສັນຍານຕໍ່ສຽງລົບກວນ, ກຳນົດວ່າຊ່ອງໂຫວ່ດັ່ງກ່າວສາມາດເຂົ້າເຖິງໄດ້ ຫຼື ສາມາດນຳໃຊ້ໄດ້ແທ້. ແຕ່ພວກມັນບໍ່ມີປະໂຫຍດຕໍ່ກັບມັນແວໃໝ່. ໃຫ້ຄິດວ່າອົງປະກອບທີ່ເປັນອັນຕະລາຍເປັນຊ່ອງໂຫວ່ zero-day: ເມື່ອກວດພົບພຶດຕິກຳທີ່ເປັນອັນຕະລາຍເທົ່ານັ້ນ, ອົງປະກອບດັ່ງກ່າວຈະຖືກລາຍງານໄປຍັງທະບຽນທີ່ຖືຄອງ, ເຊິ່ງຫຼັງຈາກການທົບທວນຄືນໂດຍທີມງານຄວາມປອດໄພແລ້ວຈະຖືກຢືນຢັນວ່າເປັນອັນຕະລາຍ ແລະ ຖືກລຶບອອກຈາກທະບຽນ. [1].
ໃນຈຸດນັ້ນ, ໂລກ (ລວມທັງ SCAs) ຮູ້ວ່າການຕິດຕັ້ງ ຫຼື ການໃຊ້ອົງປະກອບ (ຫຼື ບາງລຸ້ນຂອງອົງປະກອບທີ່ມີຢູ່ແລ້ວ) ບໍ່ແມ່ນສິ່ງທີ່ດີ. ແຕ່ນີ້ແມ່ນເວລາທີ່ອົງປະກອບບໍ່ສາມາດໃຊ້ໄດ້ຈາກ registryການຮູ້ວ່າຂ້ອຍມີຊ່ອງໂຫວ່ໃນອົງປະກອບຂອງພາກສ່ວນທີສາມ, ຫຼືແມ່ນແຕ່ອົງປະກອບທີ່ຖືກຈັດປະເພດເປັນອັນຕະລາຍໂດຍການລົງທະບຽນແມ່ນດີ, ແຕ່ຫນ້າເສຍດາຍ SCA ຫຼື ເຄື່ອງມືການກວດສອບທົ່ວໄປບໍ່ໄດ້ຊ່ວຍໃນສະພາບການນີ້. ເວັ້ນເສຍແຕ່ວ່າ SCAເຄື່ອງມື /audit ສາມາດຮູ້ລ່ວງໜ້າໄດ້ແທ້ໆວ່າອົງປະກອບໃດໜຶ່ງເປັນອັນຕະລາຍກ່ອນທີ່ມັນຈະຖືກນຳໃຊ້ຢູ່ໃນອົງກອນຂອງທ່ານ.
ຈື່ໄວ້ວ່າ, ວິທີແກ້ໄຂໃດໆຕໍ່ກັບອົງປະກອບແຫຼ່ງເປີດທີ່ເປັນອັນຕະລາຍຕ້ອງກວດພົບພວກມັນ ສຸດບິນ, ລະຫວ່າງເວລາທີ່ອົງປະກອບຖືກເຜີຍແຜ່ໃນ registry ແລະເວລາທີ່ອົງປະກອບ (ເວີຊັນ) ຖືກນຳໃຊ້ຄັ້ງທຳອິດຢູ່ໃນອົງກອນຂອງທ່ານ. ແລະນັ້ນລວມທັງອົງປະກອບ transitive.
ຄວາມເຂົ້າໃຈຜິດ #2: ການຄວບຄຸມສະຄຣິບຕິດຕັ້ງໃນເວລາສ້າງປ້ອງກັນພຶດຕິກຳທີ່ເປັນອັນຕະລາຍຈາກອົງປະກອບແຫຼ່ງເປີດ
ຜູ້ຈັດການແພັກເກດຕ່າງໆສະເໜີຄວາມສາມາດໃນການໃຊ້ສະຄຣິບ (ລວມຢູ່ໃນ tarball ຂອງອົງປະກອບ) [2]), ດ້ວຍເຫດຜົນທີ່ຖືກຕ້ອງ, ເຊັ່ນ: ການລວບລວມລາຍການທີ່ຕ້ອງການໃນແພລດຟອມຕ່າງໆ, ການສ້າງລະຫັດ, ຫຼື ການແລ່ນການທົດສອບ, ແລະ ພວກເຮົາທຸກຄົນຄວນຮູ້ວ່າພວກມັນສາມາດຖືກໃຊ້ໃນທາງທີ່ຜິດໂດຍຜູ້ກະທຳທີ່ບໍ່ດີ ຖ້າສະຄຣິບທີ່ເປັນອັນຕະລາຍຖືກລວມຢູ່ໃນ tarball, ຫຼື ຖ້າຜູ້ໂຈມຕີສາມາດເຮັດໃຫ້ສະຄຣິບທີ່ເປັນອັນຕະລາຍເຮັດວຽກແທນທີ່ຈະເປັນສະຄຣິບທີ່ດີ.
ໂດຍຮູ້ເລື່ອງນີ້, ພວກເຮົາສາມາດຕັ້ງຄ່າຕົວຈັດການແພັກເກດໃຫ້ບໍ່ສົນໃຈສະຄຣິບ. ຕົວຢ່າງ, ດ້ວຍ NPM – ບໍ່ສົນໃຈສະຄິບ ທຸງ (ຫຼື ຄຸນສົມບັດການຕັ້ງຄ່າໃນ .npmrc ໄຟລ໌) ຂ້າມສະຄຣິບໃນລະຫວ່າງການຕິດຕັ້ງ. ອັນນີ້ອາດຈະເຮັດໃຫ້ເກີດບັນຫາບາງຢ່າງເພາະວ່າການແລ່ນສະຄຣິບແມ່ນພົບເລື້ອຍໃນຫຼາຍລະບົບນິເວດ: ບາງຕົວຈັດການແພັກເກດບໍ່ອະນຸຍາດໃຫ້ປິດການໃຊ້ງານການປະຕິບັດສະຄຣິບ (ຄຳແນະນຳ: prompt “ຜູ້ຈັດການແພັກເກດໃດທີ່ບໍ່ອະນຸຍາດໃຫ້ປິດການໃຊ້ງານການປະຕິບັດສະຄຣິບຕິດຕັ້ງ?” ໃນ AI ທີ່ທ່ານມັກ). ແຕ່ສິ່ງນີ້ບໍ່ໄດ້ປົກປ້ອງໂດຍທົ່ວໄປ (ພວກເຮົາຈຳເປັນຕ້ອງບັງຄັບໃຊ້ການຕັ້ງຄ່າການປິດການໃຊ້ງານຂ້າມຢູ່ທົ່ວທຸກແຫ່ງ).
ແລະເມື່ອພຶດຕິກຳທີ່ເປັນອັນຕະລາຍບໍ່ໄດ້ຢູ່ໃນສະຄຣິບຕິດຕັ້ງແຕ່ຢູ່ໃນຊອບແວທີ່ຈະປະຕິບັດໃນເວລາແລ່ນ, ຕົວເລືອກນີ້ຢ່າງດຽວບໍ່ໄດ້ປົກປ້ອງພວກເຮົາ.
ຄວາມເຂົ້າໃຈຜິດ #3: ການປັກໝຸດເວີຊັນປ້ອງກັນບໍ່ໃຫ້ຕິດຕັ້ງອົງປະກອບທີ່ເປັນອັນຕະລາຍ
ມີການແລກປ່ຽນລະຫວ່າງການແກ້ໄຂໄວ ແລະ ເລື້ອຍໆດ້ວຍ ລຸ້ນເປີດ (ໃຫ້ຜູ້ຈັດການແພັກເກດຕິດຕັ້ງການອັບເດດໃໝ່ໂດຍອັດຕະໂນມັດເມື່ອມີໃຫ້ສຳລັບການແກ້ໄຂຄວາມປອດໄພ) ແລະ ການປັກໝຸດເວີຊັນ (ມີການເພິ່ງພາອາໄສໂດຍກົງ ແລະ ການຫັນປ່ຽນທັງໝົດສຳລັບຊອບແວໃນເວີຊັນທີ່ຄົງທີ່). ຫຼັກການຄວາມປອດໄພແມ່ນແຂງກະດ້າງ ແລະ ບາງຄັ້ງກໍ່ຂັດແຍ້ງກັນ, ດັ່ງທີ່ເກີດຂຶ້ນກັບ "ການແກ້ໄຂໄວ, ການແກ້ໄຂເລື້ອຍໆ" ແລະ "ການຍົກລະດັບບໍ່ຄວນຖືກປະຕິບັດຢ່າງເບົາບາງ"ຜູ້ຈັດການແພັກເກດບາງຄົນເຮັດການອັບເດດອັດຕະໂນມັດດ້ວຍລະດັບເຊີບເວີຕາມວິທີທີ່ແນະນຳ. ດີຫຼາຍຖ້າທ່ານຍັງຕ້ອງການຮັບການອັບເດດທີ່ເປັນອັນຕະລາຍ! ແມ່ນແລ້ວ, ອົງປະກອບຕ່າງໆຕ້ອງໄດ້ຮັບການອັບເດດເພື່ອຮັບການແກ້ໄຂຄວາມປອດໄພທີ່ປິດຊ່ອງໂຫວ່ໄວເທົ່າທີ່ຈະໄວໄດ້, ແຕ່ ... ຢ່າປ່ອຍໃຫ້ຜູ້ຈັດການແພັກເກດເຮັດສິ່ງນີ້ໂດຍອັດຕະໂນມັດ.
ຄວາມເຂົ້າໃຈຜິດ #4: ການໃຊ້ອົງປະກອບທີ່ເຊື່ອຖືໄດ້ແມ່ນປອດໄພ. ເວີຊັນທີ່ເປັນອັນຕະລາຍໃດໆຈະຖືກພົບເຫັນ, ເປີດເຜີຍ ແລະ ລຶບອອກຢ່າງວ່ອງໄວ.
ເປັນຫຍັງອົງປະກອບຈຶ່ງເຊື່ອຖືໄດ້? ອາດຈະເປັນຍ້ອນວ່າມັນເປັນທີ່ນິຍົມຫຼາຍ, ໂດຍມີຫຼາຍສາຍຕາທີ່ຊອກຫາຊ່ອງໂຫວ່, ມີຜູ້ປະກອບສ່ວນຈຳນວນຫຼວງຫຼາຍສຳລັບການບຳລຸງຮັກສາ, ໂດຍມີຜູ້ຮັກສາຫຼັກຫຼາຍຄົນທີ່ກວດສອບທຸກຢ່າງຢ່າງພາກພຽນ. pull requestsຄວາມເປັນຈິງແມ່ນແຕກຕ່າງກັນຫຼາຍ. ອົງປະກອບທີ່ສຳຄັນບາງຢ່າງແມ່ນຮັກສາໄວ້ໂດຍນັກພັດທະນາຄົນດຽວທີ່ບໍ່ໄດ້ຮັບຄ່າຈ້າງ. ເຟຣມເວີກທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງມີ ຜູ້ປະກອບສ່ວນປະຈຳຈຳນວນໜຶ່ງ, ດ້ວຍຈຳນວນທີ່ຫຼຸດລົງຢ່າງໄວວາຂອງ commitຕໍ່ຜູ້ຮັກສາ (ໂຄງການທີ່ໄດ້ຮັບຄວາມນິຍົມມີຜູ້ປະກອບສ່ວນຫຼາຍຄົນທີ່ປະຕິບັດການ drive-by ບາງຢ່າງ commit ແລະຢ່າກັບມາອີກ). ແລະໂຄງການທີ່ໄດ້ຮັບຄວາມນິຍົມກັບຜູ້ຮັກສາຄົນດຽວກໍ່ມີຢູ່ຢ່າງຫຼວງຫຼາຍ.
ລອງນຶກພາບຕົວເອງວ່າ "ໂອ້, ພວກເຮົາກຳລັງໃຊ້ຮູບພາບ Spring Boot / Angular / React / PyTorch / ຖານ Docker ຢ່າງເປັນທາງການ, ສະນັ້ນຄວາມສ່ຽງທີ່ເຈົ້າກຳລັງເວົ້າເຖິງແມ່ນຂ້ອນຂ້າງຕໍ່າ." ບາງທີນັ້ນອາດເປັນຄວາມຈິງ, ພວກເຮົາຜູ້ຂາຍຄວາມປອດໄພເຮັດໃຫ້ຢ້ານກົວຕະຫຼອດເວລາ, ແລະ ການແຊກແຊງທີມງານພັດທະນາເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງທີ່ໂຕ້ຖຽງກັນແມ່ນເລື່ອງໄຮ້ສາລະ. ເຈົ້າອາດຈະຖືກລໍ້ລວງໃຫ້ຂ້າມໄປຫາວັກຍອມຮັບຄວາມສ່ຽງ (ໃນພາກຕໍ່ໄປ) ແລະ ທຸກຢ່າງກໍ່ສຳເລັດແລ້ວ. ແຕ່ຫນ້າເສຍດາຍ, ອົງປະກອບທີ່ນິຍົມທີ່ສຸດແມ່ນເປົ້າໝາຍຂອງຜູ້ກະທຳທີ່ບໍ່ດີ, ແລະ ຕົວຢ່າງ, ທີ່ນິຍົມ ຫ້ອງສະໝຸດ PyTorch ຖືກໂຈມຕີ ໃນອະດີດ.
"ພົບເຫັນ, ເປີດເຜີຍ, ແລະ ລຶບອອກຢ່າງວ່ອງໄວ". ມັນໃຊ້ເວລາຫຼາຍມື້ເພື່ອໃຫ້ອົງປະກອບທີ່ເປັນອັນຕະລາຍໃໝ່ຖືກລຶບອອກຈາກທະບຽນສາທາລະນະ. ທະບຽນມີຄວາມລະມັດລະວັງກ່ຽວກັບການລຶບລຸ້ນອົງປະກອບອອກ. ປະສົບການຂອງພວກເຮົາແມ່ນວ່າເມື່ອລາຍງານຈາກຝ່າຍພວກເຮົາ, ເວລາສະເລ່ຍສຳລັບທະບຽນເພື່ອລຶບລຸ້ນທີ່ໄດ້ຮັບຜົນກະທົບແມ່ນ 39 ຊົ່ວໂມງ, ຫຼາຍກວ່າມື້ເຄິ່ງ. ມີອົງປະກອບທີ່ເປັນອັນຕະລາຍທີ່ຢູ່ໜຶ່ງອາທິດຫຼັງຈາກການລາຍງານເບື້ອງຕົ້ນຂອງພວກເຮົາໃນທະບຽນກ່ອນການລຶບອອກ. ແລະໃນບາງກໍລະນີ, ອົງປະກອບດັ່ງກ່າວຈະຖືກລຶບອອກຫຼັງຈາກຜູ້ເຄາະຮ້າຍ ຫຼື ບໍລິສັດຕອບສະໜອງເຫດການລາຍງານເຫດການທີ່ກ່ຽວຂ້ອງກັບອົງປະກອບດັ່ງກ່າວ.
ສິ່ງທີ່ບໍ່ໄດ້ຜົນຕໍ່ກັບອົງປະກອບທີ່ເປັນອັນຕະລາຍ
ວິທີການໃດໆທີ່ບໍ່ແນ່ນອນຈະລົ້ມເຫຼວຢ່າງໜ້າເສົ້າໃຈ. ນີ້ແມ່ນສິ່ງທີ່ແນ່ນອນ, ທ່ານບໍ່ໄດ້ໃຫ້ມາດຕະການຕ້ານການທີ່ມີປະສິດທິພາບສຳລັບຄວາມສ່ຽງທີ່ກ່ຽວຂ້ອງກັບໄພຂົ່ມຂູ່ນີ້.
ແບບດັ້ງເດີມ SCA ເຄື່ອງມືຕ່າງໆບອກທ່ານກ່ຽວກັບມັນແວທີ່ຮູ້ຈັກແຕ່ມີປ່ອງຢ້ຽມການເປີດເຜີຍຂະໜາດໃຫຍ່. ເວັ້ນເສຍແຕ່ວ່າພວກມັນປະຕິບັດການກວດຈັບມັນແວຢ່າງຕັ້ງໜ້າດ້ວຍການບັງຄັບໃຊ້ການບລັອກອົງປະກອບທີ່ເປັນອັນຕະລາຍ, ພວກມັນບໍ່ໄດ້ເຮັດວຽກຕໍ່ຕ້ານໄພຂົ່ມຂູ່ນີ້.
ການປິດການໃຊ້ງານສະຄຣິບການຕິດຕັ້ງສາມາດຊ່ວຍໄດ້ ແຕ່ຈຳເປັນຕ້ອງມີການບັງຄັບໃຊ້ຢູ່ທຸກບ່ອນທີ່ຕ້ອງການຕິດຕັ້ງອົງປະກອບ. ເຊັ່ນດຽວກັນກັບການປັກໝຸດເວີຊັນ, ຍ້ອນວ່າເວີຊັນຕ່າງໆບໍ່ສາມາດຖືກປັກໝຸດຈາກສະຖານະເລີ່ມຕົ້ນທີ່ປອດໄພຕະຫຼອດໄປ.
ການສົມມຸດວ່າອົງປະກອບທີ່ໄດ້ຮັບຄວາມນິຍົມໄດ້ຮັບຄວາມສົນໃຈພຽງພໍຈົນບໍ່ສາມາດສີດພຶດຕິກຳທີ່ບໍ່ຕັ້ງໃຈໃສ່ໃນການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງໄດ້ໂດຍບໍ່ມີການກວດພົບທັນທີທັນໃດເພື່ອປ້ອງກັນຄວາມເສຍຫາຍໃດໆນັ້ນ ເປັນເລື່ອງທີ່ໂງ່ຈ້າ ແລະ ມີຄວາມສ່ຽງ. ເຈົ້າບໍ່ຢາກອາໄສຢູ່ໃນຂອບເຂດ, ແມ່ນບໍ?
ຖ້າຢຸດຢູ່ຈຸດນີ້ກໍ່ພໍແລ້ວ ການຍອມຮັບຄວາມສ່ຽງ ເປັນສິ່ງດຽວທີ່ເຈົ້າສາມາດເຮັດໄດ້: ນີ້ແມ່ນ decisສິ່ງທີ່ຕ້ອງໄດ້ບັນທຶກໄວ້ໃນຮູບແບບໄພຂົ່ມຂູ່/ການປະເມີນຄວາມສ່ຽງຂອງທ່ານ, ລວມທັງເຫດຜົນໃນການຍອມຮັບຄວາມສ່ຽງ ແລະ ຜົນສະທ້ອນທີ່ອາດເກີດຂຶ້ນ. ຍົກສູງຄວາມຮັບຮູ້ໂດຍການສື່ສານກັບຝ່າຍຄຸ້ມຄອງ ແລະ ພາກສ່ວນທີ່ກ່ຽວຂ້ອງອື່ນໆ. ບາງ ຂຶ້ນຢູ່ກັບ ສາມາດວາງແຜນໄດ້ເມື່ອມີການຕິດຕັ້ງອົງປະກອບທີ່ເປັນອັນຕະລາຍ ຫຼື ລວມຢູ່ໃນຊອບແວຂອງທ່ານ, ແຕ່ສິ່ງນີ້ເປັນເລື່ອງຍາກເພາະວ່າຜູ້ໂຈມຕີມີຫຼາຍເສັ້ນທາງທີ່ຕ້ອງຕິດຕາມ. ລາຍລະອຽດຂອງການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງໂດຍອີງໃສ່ການນຳໃຊ້ອົງປະກອບທີ່ເປັນອັນຕະລາຍຈະປ່ຽນແປງການເປີດເຜີຍຕໍ່ສາທາລະນະກ່ຽວກັບເຫດການດັ່ງກ່າວຢ່າງຫຼວງຫຼາຍ, ເຊິ່ງອາດຈະເປັນຂໍ້ບັງຄັບພາຍໃຕ້ຂອບກົດລະບຽບຂອງອົງກອນຂອງທ່ານ. ທ່ານອາດຈະແກ້ໄຂ ການຄວບຄຸມການຊົດເຊີຍ or ຄວາມສ່ຽງໃນການໂອນຍ້າຍ ຕົວຢ່າງເຊັ່ນ ດ້ວຍການປະກັນໄພ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ມີການຄວບຄຸມທີ່ແກ້ໄຂໄພຂົ່ມຂູ່ ແລະ ຄວນພິຈາລະນາຖ້າທ່ານບໍ່ພໍໃຈກັບການຍອມຮັບຄວາມສ່ຽງ. ກະລຸນາອ່ານຕໍ່ໄປ.
ສິ່ງທີ່ເຮັດວຽກຕໍ່ຕ້ານການໂຈມຕີໂດຍໃຊ້ອົງປະກອບທີ່ເປັນອັນຕະລາຍ
ການຈັດການລຸ້ນແຂງ
ການປັກໝຸດເວີຊັນດ້ວຍການຂັດຂວາງເວີຊັນທີ່ຄວບຄຸມ ແລະ ໄດ້ຮັບຂໍ້ມູນແມ່ນວິທີທີ່ຄວນເຮັດ, ເພື່ອດຸ່ນດ່ຽງຄວາມຕ້ອງການໃນການລຶບຊ່ອງໂຫວ່ໂດຍບໍ່ໄດ້ຮັບມັລແວ. ແຕ່ຈົ່ງຈື່ໄວ້ວ່າຄວາມເຂົ້າໃຈຜິດ #3: ການປັກໝຸດເວີຊັນຢ່າງດຽວບໍ່ພຽງພໍທີ່ຈະບລັອກລະຫັດທີ່ເປັນອັນຕະລາຍທີ່ມາຈາກເວີຊັນໃໝ່, ເພາະວ່າໃນອະນາຄົດທ່ານຈະຕ້ອງອັບເດດເວີຊັນຕ່າງໆໃນການເພິ່ງພາອາໄສໂດຍກົງ ຫຼື ໂດຍທາງອ້ອມ. ໃນເວລານັ້ນທ່ານຕ້ອງການຫຼັກຖານທີ່ເຂັ້ມແຂງພຽງພໍວ່າເວີຊັນທີ່ຖືກດັດແກ້ທັງໝົດບໍ່ມີມັລແວ.
ຄຳ ເຕືອນກ່ອນໄວອັນຄວນ
ວິທີການໜຶ່ງໃນການແກ້ໄຂບັນຫາຂອງອົງປະກອບທີ່ເປັນອັນຕະລາຍແມ່ນລະບົບເຕືອນໄພລ່ວງໜ້າ (ຕັ້ງຊື່ຢູ່ທີ່ນີ້ວ່າ ຄຳເຕືອນລ່ວງໜ້າກ່ຽວກັບມັລແວ ຫຼື MEW), ບ່ອນທີ່ລຸ້ນໃໝ່ທີ່ເຜີຍແຜ່ (ສຳລັບອົງປະກອບໃໝ່ ຫຼື ທີ່ມີຢູ່ແລ້ວ) ຖືກວິເຄາະໂດຍເຄື່ອງຈັກກວດຈັບ, ເຊິ່ງເມື່ອພົບຫຼັກຖານພຽງພໍອາດຈະຈັດປະເພດລຸ້ນໃໝ່ວ່າເປັນອັນຕະລາຍ.
ການເຮັດວຽກອັດຕະໂນມັດແມ່ນມີຄວາມຈຳເປັນຢູ່ທີ່ນີ້, ຍ້ອນວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກວດສອບອົງປະກອບໃໝ່ທັງໝົດດ້ວຍຕົນເອງໃນອັດຕາການເຜີຍແຜ່ໃນປະຈຸບັນ. ດັ່ງນັ້ນ, ເຄື່ອງຈັກກວດສອບຈຶ່ງຈຳເປັນຕ້ອງລວມເອົາເຕັກນິກທີ່ຫຼາກຫຼາຍ, ບາງທີອາດຈະລວມທັງການວິເຄາະແບບຄົງທີ່, ແບບເຄື່ອນໄຫວ, ແລະ ຄວາມສາມາດ, ຊື່ສຽງຂອງຜູ້ໃຊ້, ແລະ ຫຼັກຖານທີ່ມາຈາກຄວາມແຕກຕ່າງລະຫວ່າງ metadata ຂອງອົງປະກອບ ແລະ ເນື້ອໃນຂອງ tarball, ຫຼື ລະຫວ່າງ tarball ແລະ ບ່ອນເກັບມ້ຽນແຫຼ່ງຂໍ້ມູນບ່ອນທີ່ອົງປະກອບດັ່ງກ່າວມາຈາກ.
ມີ ເຂດມືດ ລະຫວ່າງເວລາເຜີຍແຜ່ ແລະ ເວລາທີ່ເຄື່ອງຈັກວິເຄາະເນື້ອໃນຂອງອົງປະກອບ, ແຕ່ມັນບໍ່ຄວນເກີນສອງສາມນາທີ. ຮູບແບບສາມາດດັດແປງໄດ້, ຕົວຢ່າງເຊັ່ນ ໂດຍການລໍຖ້າໃຫ້ອົງປະກອບໃໝ່ຖືກວິເຄາະກ່ອນທີ່ຈະອະນຸຍາດໃຫ້ຕິດຕັ້ງ ແລະ ນຳໃຊ້ໃນຊອບແວຣ໌ build. pipelineຫຼືວິເຄາະພວກມັນຕາມຄວາມຕ້ອງການເມື່ອຕ້ອງການ. ອົງປະກອບຢູ່ໃນເວີຊັນທີ່ກຳນົດໃຫ້ແມ່ນບໍ່ປ່ຽນແປງ [3], ສະນັ້ນມັນຈຳເປັນຕ້ອງໄດ້ວິເຄາະພຽງຄັ້ງດຽວ.
ການອັດຕະໂນມັດຢ່າງເຕັມຮູບແບບແມ່ນເປັນໄປບໍ່ໄດ້, ແລະ ການທົບທວນຄວາມປອດໄພສຳລັບອົງປະກອບທີ່ອາດຈະເປັນອັນຕະລາຍແມ່ນມີຄວາມຈຳເປັນ. ຈົ່ງລະວັງຜູ້ສະໜັບສະໜຸນຢາແກ້ປວດດິຈິຕອນປັນຍາປະດິດ ແລະ ການຮຽນຮູ້ຂອງເຄື່ອງຈັກຍັງບໍ່ທັນໄດ້ຮັບການພັດທະນາພຽງພໍທີ່ຈະຢືນຢັນໄດ້ວ່າອົງປະກອບທີ່ໜ້າສົງໄສມີມັນແວຫຼືບໍ່. ແນ່ນອນ, ການຮຽນຮູ້ຂອງເຄື່ອງຈັກມີບົດບາດສຳຄັນໃນເຄື່ອງຈັກກວດຈັບໃນການຈັດປະເພດອົງປະກອບການປ້ອນຂໍ້ມູນຈາກຫຼັກຖານດິບທີ່ຈັບໄດ້, ແຕ່ເມື່ອອົງປະກອບດັ່ງກ່າວຖືກ "ກັກກັນ" ແລ້ວ, ຄຳສຸດທ້າຍແມ່ນຢູ່ໃນການທົບທວນດ້ວຍຕົນເອງໂດຍທີມງານຄວາມປອດໄພທີ່ມີປະສົບການໃນອົງປະກອບທີ່ເປັນອັນຕະລາຍ. ສິ່ງນີ້ຢືນຢັນມັນແວທີ່ອາດເກີດຂຶ້ນ ຫຼື ຈັດປະເພດຄືນໃໝ່ວ່າປອດໄພ. ແລະໄລຍະເວລາແມ່ນຢູ່ໃນຊ່ວງຊົ່ວໂມງ.
ສຳນັກງານທະບຽນຈະລາຍງານກ່ຽວກັບລຸ້ນ/ອົງປະກອບທີ່ເປັນອັນຕະລາຍ; ຫຼັງຈາກນັ້ນ, ສຳນັກງານທະບຽນຈະດຳເນີນການທົບທວນຄືນເພື່ອຢືນຢັນ ແລະ ດຳເນີນການເປີດເຜີຍຕໍ່ສາທາລະນະ ແລະ ລຶບອອກຈາກສຳນັກງານທະບຽນ. ບາງສຳນັກງານທະບຽນຮັກສາຊຸດການຖືຄອງຄວາມປອດໄພ. ຊ່ວງເວລາຢູ່ທີ່ນີ້ແມ່ນມື້ ຫຼື ອາທິດນັບຕັ້ງແຕ່ການເຜີຍແຜ່, ເຊິ່ງເປັນ 'ໃຊ້ເວລາ'ຫຼື'ປ່ອງຢ້ຽມການຮັບແສງ' ສຳລັບອົງປະກອບທີ່ເປັນອັນຕະລາຍສ່ວນໃຫຍ່.
ມັນເປັນໄປໄດ້ບໍທີ່ຈະຮູ້ໄດ້ວ່າລຸ້ນຂອງອົງປະກອບນັ້ນເປັນອັນຕະລາຍ?
ສະນັ້ນ, ສຳລັບການແຈ້ງເຕືອນລ່ວງໜ້າ, ພວກເຮົາຈຳເປັນຕ້ອງໃຫ້ຄຳຕອບທີ່ໜ້າພໍໃຈຕໍ່ຄຳຖາມນີ້: ຂ້ອຍຈະຮູ້ໄດ້ແນວໃດວ່າຫ້ອງສະໝຸດ ຫຼື ແພັກເກດໃດໜຶ່ງ (ບໍ່) ເປັນອັນຕະລາຍ? ວິທີການເກັບກຳຫຼັກຖານທີ່ພຽງພໍຂອງພຶດຕິກຳທີ່ເປັນອັນຕະລາຍ? ເປັນໄປໄດ້, ແຕ່ຍາກ, ຍ້ອນວ່າສັດຕູໃຊ້ຄວາມສະຫຼາດຫຼາຍເພື່ອຫຼີກລ່ຽງການກວດພົບ. ມີວິທີການທີ່ແຕກຕ່າງກັນ, ແຕ່ລະວິທີມີຂໍ້ດີ ແລະ ຂໍ້ເສຍ.
ການວິເຄາະຄົງທີ່ ສາມາດກວດສອບເສັ້ນທາງການປະຕິບັດທັງໝົດ ກວດສອບເຕັກນິກທີ່ໃຊ້ໂດຍຜູ້ໂຈມຕີໂດຍບໍ່ຕ້ອງໃຊ້ອົງປະກອບ, ແລະປະຕິບັດໜ້າວຽກປະມວນຜົນກ່ອນເຊັ່ນ: ການລຶບລ້າງການປິດບັງ ຫຼື ການຖອດລະຫັດ. ໃນຂະນະທີ່ຜູ້ໂຈມຕີພະຍາຍາມເຊື່ອງຄວາມຊົ່ວຮ້າຍຂອງເຂົາເຈົ້າ, ຄວາມພະຍາຍາມໃນການປິດບັງແມ່ນຫຼັກຖານຂອງມັນແວ (ແຕ່ໃຫ້ສັງເກດວ່າອົງປະກອບທີ່ຖືກຕ້ອງຕາມກົດໝາຍເຮັດໃຫ້ລະຫັດຖືກປິດບັງເພື່ອຮັກສາຊັບສິນທາງປັນຍາ, ເຊິ່ງຂັດແຍ້ງກັບ "Open source”). ມີພຽງແຕ່ສ່ວນໜ້ອຍຂອງການໂຈມຕີທີ່ມີຄວາມຊັບຊ້ອນສູງທີ່ມີການປິດບັງທີ່ເຂັ້ມແຂງເທົ່ານັ້ນທີ່ຕ້ອງການ sandboxing, ແຕ່ການປິດບັງທີ່ເຂັ້ມແຂງດັ່ງກ່າວແມ່ນສັນຍານທີ່ບອກເຖິງຄວາມຊົ່ວຮ້າຍ. ກະລຸນາຮັບຊາບວ່າການທຳມະດາ SAST ເຄື່ອງມືຕ່າງໆໄດ້ຖືກອອກແບບມາສຳລັບຊ່ອງໂຫວ່ທີ່ບໍ່ຕັ້ງໃຈ, ບໍ່ແມ່ນສຳລັບເຈດຕະນາຮ້າຍເຊັ່ນ: ປະຕູຫຼັງ.
ການວິເຄາະແບບເຄື່ອນໄຫວ ດໍາເນີນການອົງປະກອບ ແລະ ກວດສອບການຕອບສະໜອງໂດຍການວັດແທກເວລາແລ່ນ, ໂດຍປົກກະຕິແລ້ວໂດຍການສະໜອງສະພາບແວດລ້ອມແບບ sandbox. ພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍທີ່ເກີດຂຶ້ນພາຍໃຕ້ເງື່ອນໄຂບາງຢ່າງອາດຈະບໍ່ຖືກກວດພົບ: ກະລຸນາຮັບຊາບວ່າມັນແວອາດຈະໃຊ້ເຕັກນິກການຫຼີກລ່ຽງເຊັ່ນ: ການຫຼີກລ່ຽງການຈຳລອງແບບເສມືນ/Sandbox ເພື່ອເປີດໃຊ້ງານພຽງແຕ່ເມື່ອບໍ່ໄດ້ຢູ່ພາຍໃຕ້ການກວດສອບຢ່າງລະອຽດ, ແລະຍັງເປັນສັນຍານບອກເລົ່າເຖິງກິດຈະກຳທີ່ເປັນອັນຕະລາຍສຳລັບເຄື່ອງຈັກວິເຄາະແບບຄົງທີ່ໃດໆ.
ການວິເຄາະຄວາມສາມາດ ພິຈາລະນາສິ່ງທີ່ອົງປະກອບເຮັດ: ບ່ອນທີ່ມັນເຊື່ອມຕໍ່ກັບ, ໄຟລ໌ໃດທີ່ມັນເຂົ້າເຖິງ, ຄຳສັ່ງ ຫຼື ໂປຣແກຣມໃດທີ່ເຮັດວຽກ, terminal ຫຼື ອຸປະກອນ I/O ທີ່ປະຕິບັດ, ຫຼື ການເອີ້ນລະບົບໃດທີ່ຖືກເອີ້ນ. ການກວດຈັບລາຍນິ້ວມືຂອງພຶດຕິກຳນີ້ສາມາດປຽບທຽບໄດ້ (ສຳລັບອົງປະກອບທີ່ມີຢູ່ແລ້ວ) ໃນທົ່ວລຸ້ນຕ່າງໆ, ດັ່ງນັ້ນເມື່ອກວດພົບພຶດຕິກຳທີ່ບໍ່ຄາດຄິດ, ຫຼັກຖານນັ້ນອາດຈະເຮັດໃຫ້ເກີດຄວາມສົງໄສກ່ຽວກັບກິດຈະກຳທີ່ເປັນອັນຕະລາຍທີ່ອາດຈະເກີດຂຶ້ນໃນລຸ້ນໃໝ່. ວິທີການນີ້ປະຕິບັດຕາມຂັ້ນຕອນການຄັດເລືອກທີ່ນັກວິເຄາະຄວາມປອດໄພປະຕິບັດຕາມເມື່ອປະເຊີນກັບມັນແວທີ່ອາດເກີດຂຶ້ນ: ການກວດກາໂດຍໃຊ້ strings ຫຼືເຄື່ອງມືທີ່ຄ້າຍຄືກັນ. ວິທີການນີ້ກວດຫາພຶດຕິກຳທີ່ເປັນອັນຕະລາຍໂດຍບໍ່ຄຳນຶງເຖິງເງື່ອນໄຂທີ່ກະຕຸ້ນ ແລະ ເຮັດວຽກເມື່ອບໍ່ມີລະຫັດແຫຼ່ງຂໍ້ມູນ.
ການວິເຄາະບໍລິບົດ ເກັບກຳຂໍ້ມູນກ່ຽວກັບວ່າອົງປະກອບດັ່ງກ່າວຖືກເຜີຍແຜ່ແນວໃດ ແລະ ໂດຍໃຜ. ແຄມເປນຂອງຜູ້ກະທຳທີ່ບໍ່ດີມັກຈະໃຊ້ບັນຊີຜູ້ໃຊ້ໃໝ່ທີ່ບໍ່ໄດ້ຢູ່ພາຍໃຕ້ຂະບວນການກວດສອບທີ່ເຂັ້ມງວດ. ການຕິດຕາມກິດຈະກຳໃນອະດີດອາດຈະໃຫ້ຂໍ້ມູນເຊີງລຶກກ່ຽວກັບຜູ້ໃຊ້ທີ່ຢູ່ເບື້ອງຫຼັງ, ສ່ວນໃຫຍ່ແມ່ນສຳລັບຄວາມຜິດປົກກະຕິທີ່ອາດຈະບົ່ງບອກເຖິງການປະນີປະນອມທີ່ອາດເກີດຂຶ້ນ. ຊື່ສຽງຍາກທີ່ຈະໄດ້ຮັບ ແລະ ງ່າຍທີ່ຈະສູນເສຍ! ຜູ້ໃຊ້ທີ່ບໍ່ມີກິດຈະກຳໃນອະດີດແມ່ນເປັນກາງ, ແຕ່ກຳມະຈະຕິດຕາມຜູ້ທີ່ເປັນອັນຕະລາຍ. ຜູ້ທີ່ໃຊ້ແຮກເກີ ຫຼື ຜູ້ໃຊ້ປົກກະຕິທີ່ຖືກລັກຂໍ້ມູນປະຈຳຕົວການເຜີຍແຜ່ຂອງເຂົາເຈົ້າຄວນຖືກຕິດຕາມຢ່າງລະມັດລະວັງ.
ຂໍ້ມູນສະພາບການອີກອັນໜຶ່ງແມ່ນຄວາມແຕກຕ່າງລະຫວ່າງບ່ອນເກັບມ້ຽນແຫຼ່ງຂໍ້ມູນທີ່ຄາດວ່າຈະໃຊ້ເພື່ອສ້າງອົງປະກອບ tarball ແລະເນື້ອໃນຂອງ tarball ເອງ. ແລະຍັງປະຕິບັດຕາມການປະຕິບັດທີ່ດີ, ເຊັ່ນການສ້າງແທັກ ຫຼື ການປ່ອຍໃນບ່ອນເກັບມ້ຽນແຫຼ່ງຂໍ້ມູນທີ່ກົງກັບລຸ້ນຂອງອົງປະກອບທີ່ເຜີຍແຜ່ໃນທະບຽນສາທາລະນະ. ເມື່ອບ່ອນເກັບມ້ຽນແຫຼ່ງຂໍ້ມູນຢູ່ທີ່ສະເພາະ commit ຖືກຕິດແທັກດ້ວຍການປ່ອຍ, ແລະຫຼັງຈາກນັ້ນທັນໃດນັ້ນລຸ້ນໜຶ່ງກໍ່ບໍ່ສາມາດຕິດຕາມມັນໄດ້, ນັ້ນຄືຫຼັກຖານທີ່ເຂັ້ມແຂງທີ່ວ່າອົງປະກອບອາດຈະເປິເປື້ອນ: ຜູ້ກະທຳທີ່ບໍ່ດີອາດຈະໄດ້ລະເມີດບັນຊີທີ່ໃຊ້ສຳລັບການເຜີຍແຜ່ອົງປະກອບ, ແຕ່ບໍ່ມີສິດໃນການຂຽນໃນບ່ອນເກັບມ້ຽນລະຫັດແຫຼ່ງ). ການໂຈມຕີຫຼາຍໆຄັ້ງຖືກກວດພົບເປັນປະຈຳໂດຍໃຊ້ກົດລະບຽບເຫຼົ່ານີ້: ຕົວຢ່າງ, ການໂຈມຕີບັນຊີ ສາມາດກວດພົບໄດ້ງ່າຍຕາມແນວທາງເຫຼົ່ານີ້. ດັ່ງນັ້ນ, ການວິເຄາະສະພາບການຈຶ່ງລະບຸຄວາມຜິດປົກກະຕິດັ່ງກ່າວໃນຂະບວນການເຜີຍແຜ່.
ໄຟວໍລ໌ດ໌ທີ່ຂຶ້ນກັບ
ວິທີການທີ່ແຕກຕ່າງແມ່ນການມີບັນຊີລາຍຊື່ຂາວທີ່ສົມບູນແບບຂອງອົງປະກອບສຳລັບກຣາຟການເພິ່ງພາອາໄສທັງໝົດທີ່ໃຊ້ໃນຊອບແວຂອງທ່ານ, ສະນັ້ນໃນການສ້າງໃດໆ pipeline ເຮັດວຽກຢູ່ໃນອົງກອນຂອງທ່ານ, ພຽງແຕ່ລຸ້ນອົງປະກອບທີ່ໄດ້ຮັບການອະນຸມັດເທົ່ານັ້ນທີ່ສາມາດຕິດຕັ້ງ ແລະ ນຳໃຊ້ໄດ້.ໂຄງການ” ຖືກບັງຄັບໃຊ້ໂດຍໃຊ້ registry ພາຍໃນບ່ອນທີ່ tarballs ສຳລັບລຸ້ນອົງປະກອບທີ່ອະນຸຍາດຖືກຮັບໃຊ້ (ເກັບໄວ້ ຫຼື proxied). ກະລຸນາຮັບຊາບວ່າ whitelist ໃດໆຈະບໍ່ເຮັດວຽກ ເວັ້ນເສຍແຕ່ວ່າທ່ານມີເທັກໂນໂລຢີສຳລັບການຈັດປະເພດລຸ້ນໃໝ່ໃດໆວ່າປອດໄພພໍສົມຄວນ ເພື່ອໃຫ້ມັນສາມາດຖືກເພີ່ມເຂົ້າໃນ whitelist ໄດ້.
ກະລຸນາຮັບຊາບວ່າການເຕືອນລ່ວງໜ້າ (ການກວດພົບໄວເທົ່າທີ່ຈະໄວໄດ້ຫຼັງຈາກການເຜີຍແຜ່ເວີຊັນໃໝ່) ຈຳເປັນຕ້ອງໄດ້ລວມເຂົ້າກັບວິທີການນຳໃຊ້ຂໍ້ມູນນັ້ນຢ່າງມີປະສິດທິພາບເພື່ອສະກັດກັ້ນອົງປະກອບທີ່ມີຜົນກະທົບຕໍ່ການສ້າງ. pipelineຫຼື ເຄື່ອງຈັກຂອງນັກພັດທະນາ [4]ພວກເຮົາເອີ້ນສິ່ງນີ້ວ່າ "firewall ການເພິ່ງພາອາໄສ”: ກົນໄກການກັກກັນສຳລັບປົກປ້ອງການສ້າງອັດຕະໂນມັດຈາກແພັກເກດທີ່ເປັນອັນຕະລາຍ. ແພັກເກດພາຍໃນ ແລະ ການລົງທະບຽນຮູບພາບແມ່ນດີເພື່ອປ້ອງກັນອົງກອນຈາກຄວາມຊົ່ວຮ້າຍພາຍນອກ, ແຕ່ຫຼັກຖານທີ່ເຂັ້ມແຂງພຽງພໍແມ່ນມີຄວາມຈຳເປັນເພື່ອເຮັດໃຫ້ການກັກກັນມີປະສິດທິພາບ.
ການສະແກນແບບແລ່ນເວລາແລ່ນ
ວິທີການທາງເລືອກອື່ນສຳລັບການກວດຈັບໃນເວລາເຜີຍແຜ່ແມ່ນການວິເຄາະພຶດຕິກຳໃນເວລາແລ່ນ. ແນວຄວາມຄິດແມ່ນເພື່ອຈັບພຶດຕິກຳທີ່ຄາດໄວ້ຈາກຊອບແວ ແລະ ກວດຫາ (ຫຼື ບລັອກ) ຄວາມຜິດປົກກະຕິໃດໆທີ່ພົບ. ແນວທາງການປະຕິບັດນີ້ມີບັນຫາໃນການຕ້ອງມີເຄື່ອງມືໃນເວລາແລ່ນສຳລັບການຕິດຕາມກວດກາ ຫຼື ການບລັອກ, ແລະ ມັນເປັນແນວຄວາມຄິດທີ່ມີຄວາມຫວັງທີ່ຈະຖືກເພີ່ມເຂົ້າໃນຄັງອາວຸດຂອງກົນໄກການປົກປ້ອງຕໍ່ກັບສັດຕູພືດສ່ວນປະກອບທີ່ເປັນອັນຕະລາຍ.
ການກຳນົດຍຸດທະສາດທີ່ສົມບູນແບບ
ຍຸດທະສາດທີ່ແນະນຳຈຳເປັນຕ້ອງລວມເອົາເຕັກນິກທີ່ແຕກຕ່າງກັນໃນຂະບວນການພັດທະນາຊອບແວ, ຄວບຄຸມການອັບເດດເວີຊັນເພື່ອບລັອກອົງປະກອບທີ່ເປັນອັນຕະລາຍທີ່ເຂົ້າມາ. ພວກເຮົາຕ້ອງຮອງຮັບການປັກໝຸດເວີຊັນເພື່ອຫຼີກເວັ້ນການຕິດເຊື້ອໂດຍອັດຕະໂນມັດກັບການອັບເດດເວີຊັນເພື່ອແກ້ໄຂຊ່ອງໂຫວ່ທີ່ສຳຄັນ; ການປະເມີນຢ່າງວ່ອງໄວ ແລະ ມີປະສິດທິພາບຂອງການເພິ່ງພາອາໄສໂດຍກົງ ແລະ ທາງອ້ອມໃນລະຫວ່າງການອັບເດດເວີຊັນເພື່ອໃຫ້ມີຫຼັກຖານພຽງພໍວ່າພວກມັນບໍ່ມີມັລແວ. ການສ້າງຊອບແວທີ່ອາໄສອົງປະກອບທີ່ເປັນອັນຕະລາຍທີ່ຮູ້ຈັກຕ້ອງຖືກບລັອກ. ແລະ ທັງໝົດຕ້ອງໄດ້ຮັບການບັງຄັບໃຊ້.
ໃຊ້ການປັກໝຸດເວີຊັນເມື່ອເປັນໄປໄດ້ ເພາະມັນເຮັດໃຫ້ການສ້າງສາມາດສຳເນົາໄດ້ງ່າຍຂຶ້ນ. ການປັກໝຸດເວີຊັນດ້ວຍການຍູ້ເວີຊັນທີ່ຖືກຄວບຄຸມ ແລະ ອະນຸມັດດ້ວຍຕົນເອງ, ແລະ ໄດ້ຮັບການຊ່ວຍເຫຼືອຈາກເທັກໂນໂລຢີຊ່ວຍເຫຼືອຄວນປະເມີນວ່າການອັບເດດນຳມາເຊິ່ງມັນແວ ຫຼື ເຮັດໃຫ້ຊອບແວເສຍຫາຍ, ແລະ ປະສານງານການອັບເດດເພື່ອແກ້ໄຂຊ່ອງໂຫວ່ກັບການຫຼີກລ່ຽງການຕິດເຊື້ອມັນແວ. ເຄື່ອງມືສາມາດຊ່ວຍໄດ້ໃນທີ່ນີ້, ໂດຍ (1) ຈັດລຳດັບຄວາມສຳຄັນຂອງຊ່ອງໂຫວ່ທີ່ສຳຄັນແທ້ໆ (ສາມາດເຂົ້າເຖິງໄດ້ ແລະ ສາມາດໃຊ້ປະໂຫຍດໄດ້, ມີຄວາມສ່ຽງສູງທີ່ຈະຖືກເປົ້າໝາຍໂດຍຜູ້ໂຈມຕີ), (2) ເລືອກລຸ້ນເປົ້າໝາຍທີ່ເຂົ້າກັນໄດ້ກັບການນຳໃຊ້ອົງປະກອບໃນປະຈຸບັນ ແລະ ບໍ່ເຮັດໃຫ້ຊອບແວເສຍຫາຍ, (3) ເລືອກລຸ້ນເປົ້າໝາຍທີ່ບໍ່ມີພຶດຕິກຳທີ່ເປັນອັນຕະລາຍ, ແລະ (4) ເຮັດໃຫ້ການອັບເດດລຸ້ນສຳລັບການເພິ່ງພາອາໄສໂດຍກົງ ແລະ ໂດຍທາງອ້ອມເປັນເລື່ອງໄວ, ໂດຍການແນະນຳການປ່ຽນແປງໃນໄຟລ໌ manifest ທີ່ສາມາດໄດ້ຮັບການອະນຸມັດຢ່າງໄວວາ. ຂັ້ນຕອນ (3) ຕ້ອງການຂໍ້ມູນສະເພາະກ່ຽວກັບອົງປະກອບທີ່ເປັນອັນຕະລາຍໃຫ້ໃກ້ຄຽງກັບເວລາເຜີຍແຜ່ຂອງມັນເທົ່າທີ່ຈະເປັນໄປໄດ້.
ຂະບວນການອັບເດດ dependencies ນີ້ຕ້ອງເປັນ ບັງຄັບໃຊ້ ແລະ ຢືນຢັນ ໃນທຸກສະຖານທີ່. ຂະບວນການຕ້ອງໄດ້ຮັບການບັນທຶກໄວ້, ແລະ ທຸກພາກສ່ວນທີ່ກ່ຽວຂ້ອງຄວນໄດ້ຮັບການຝຶກອົບຮົມ, ຍ້ອນວ່າການພັດທະນາ ແລະ ການສ້າງ/ການນຳໃຊ້ຊອບແວມັກຈະຖືກສົ່ງອອກພາຍນອກ. CI/CD pipelines ຄວນໄດ້ຮັບການດັດແປງຕາມຄວາມເໝາະສົມ, ດັ່ງນັ້ນການເຮັດວຽກແບບອັດຕະໂນມັດຈະບໍ່ອະນຸຍາດໃຫ້ການເພິ່ງພາອາໄສທາງອ້ອມທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນ build: guardrails ການບລັອກການສ້າງຖ້າມີຫຼັກຖານພຽງພໍຂອງມັນແວທີ່ອາດເກີດຂຶ້ນໃນການເພິ່ງພາອາໄສແມ່ນວິທີທີ່ແນະນຳ.
ຖ້າອົງກອນຂອງທ່ານມີທະບຽນພາຍໃນທີ່ເຮັດໜ້າທີ່ເປັນຕົວແທນຄວາມປອດໄພສຳລັບການເກັບຮັກສາລຸ້ນອົງປະກອບທີ່ໄດ້ຮັບອະນຸຍາດ, ທ່ານຕ້ອງໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບອົງປະກອບທີ່ເປັນອັນຕະລາຍ (ນອກເໜືອໄປຈາກເງື່ອນໄຂອື່ນໆ) ສຳລັບການກວດສອບອົງປະກອບທີ່ຮ້ອງຂໍກ່ອນທີ່ຈະເພີ່ມມັນໃສ່ລາຍຊື່ການອະນຸຍາດ.
ການບໍລິໂພກຊອບແວແຫຼ່ງເປີດດ້ວຍຄວາມປອດໄພບໍ່ແມ່ນເລື່ອງງ່າຍ, ແລະປັດໄຈຂອງມັນແວຕ້ອງໄດ້ຮັບການພິຈາລະນາຢ່າງຄົບຖ້ວນ, ໂດຍມີຄວາມພະຍາຍາມທີ່ຄ້າຍຄືກັນໃນການຈັດການຄວາມສ່ຽງ.
ໝາຍ ເຫດສຸດທ້າຍ: ຕົ້ນກຳເນີດ, ໃນຮູບແບບຂອງການຢັ້ງຢືນຊອບແວ, ທີ່ສ້າງຂຶ້ນໃນເວລາສ້າງຂອງອົງປະກອບ, ແມ່ນອີກສ່ວນໜຶ່ງທີ່ສຳຄັນໃນຄວາມພະຍາຍາມທີ່ຈະຕິດຕາມສິ່ງປະດິດ (tarball ຂອງອົງປະກອບ) ກັບແຫຼ່ງຂໍ້ມູນ ແລະ ຂະບວນການສ້າງທີ່ຜະລິດມັນ. ໃຫ້ສັງເກດວ່າການເຊື່ອມໂຍງລະຫວ່າງ snapshot ແຫຼ່ງຂໍ້ມູນ + ສະພາບແວດລ້ອມການສ້າງ ແລະ ສິ່ງປະດິດຊອບແວທີ່ກ່ຽວຂ້ອງ (ເຊັນໂດຍລະບົບການສ້າງທີ່ເຊື່ອຖືໄດ້) ບໍ່ໄດ້ປ້ອງກັນຕົວເອງວ່າອົງປະກອບດັ່ງກ່າວບໍ່ມີພຶດຕິກຳທີ່ເປັນອັນຕະລາຍ, ແຕ່ເຮັດໃຫ້ມັນຍາກຂຶ້ນສຳລັບຄົນບໍ່ດີທີ່ຈະສັກມັນແວ. ແລະ ການເຮັດໃຫ້ການກວດສອບແຫຼ່ງທີ່ມາເປັນຄວາມຕ້ອງການທົ່ວໄປສຳລັບການບໍລິໂພກອົງປະກອບແຫຼ່ງເປີດຈະໃຊ້ເວລາດົນ, ແລະ ພຽງແຕ່ ບໍ່ດົນມານີ້ໄດ້ເພີ່ມເຂົ້າໃນ NPMການເຮັດໃຫ້ລະບົບການສ້າງ ແລະ ການນຳໃຊ້ທີ່ເຊື່ອຖືໄດ້ເຫຼົ່ານັ້ນທົນທານຕໍ່ການແຊກແຊງ, ຫຼື ການເຮັດໃຫ້ສາມາດກວດພົບການແຊກແຊງໃດໆໃນການກໍ່ສ້າງແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນ, ເຊິ່ງຢູ່ນອກຂອບເຂດຂອງໂພສນີ້.
ອ່ານເພີ່ມເຕີມ
ຕອນຕໍ່ໄປ ແພັກເກດອັນຕະລາຍແບບເປີດ: ວິທີການ Xygeni ຈະນຳສະເໜີຍຸດທະສາດທີ່ພວກເຮົາປະຕິບັດຕາມຢູ່ທີ່ Xygeni ສຳລັບພວກເຮົາ ຄຳເຕືອນລ່ວງໜ້າກ່ຽວກັບມັລແວ (MEW). ຮຸ່ນແພັກເກດໃໝ່ໃນແພັກເກດສາທາລະນະ ແລະ ການລົງທະບຽນຮູບພາບຖືກສະແກນ ແລະ ຫຼັກຖານໄດ້ຮັບໂດຍໃຊ້ການປະສົມປະສານຂອງການວິເຄາະແບບຄົງທີ່, ແບບໄດນາມິກ, ຄວາມສາມາດ ແລະ ການວິເຄາະສະພາບການ. ຫຼັກຖານ, ບວກກັບຊື່ສຽງຂອງຜູ້ໃຊ້ ແລະ ປະຫວັດການປ່ຽນແປງໃນບ່ອນເກັບມ້ຽນລະຫັດແຫຼ່ງ, ອະນຸຍາດໃຫ້ມີການຈັດປະເພດອັດຕະໂນມັດທັງໝົດຂອງອົງປະກອບອອກເປັນໝວດໝູ່ທີ່ມີຄວາມສ່ຽງສູງ ແລະ ອາດຈະເປັນອັນຕະລາຍ. ລະບົບຮຽນຮູ້ຈາກຫຼັກຖານທີ່ຜ່ານມາທີ່ເກັບມາຈາກແພັກເກດເພື່ອຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງໃຫ້ໜ້ອຍທີ່ສຸດ.
ອົງກອນທີ່ສະໝັກຮັບຂໍ້ມູນຈະໄດ້ຮັບການແຈ້ງເຕືອນສຳລັບອົງປະກອບຕ່າງໆທີ່ພວກເຂົາກຳລັງໃຊ້, ໂດຍກົງ ຫຼື ໂດຍທາງອ້ອມ, ເມື່ອມີການຈັດປະເພດລຸ້ນທີ່ເປັນອັນຕະລາຍ. ຫຼັງຈາກນັ້ນ, ນັກວິເຄາະຂອງພວກເຮົາຈະເຮັດການວິເຄາະດ້ວຍຕົນເອງ, ເຊິ່ງຢືນຢັນ ຫຼື ປະຕິເສດການຈັດປະເພດ. ສຳລັບມັນແວທີ່ຖືກຢືນຢັນແລ້ວ, ທະບຽນສາທາລະນະຈະໄດ້ຮັບການແຈ້ງເຕືອນເພື່ອໃຫ້ມັນສາມາດດຳເນີນການວິເຄາະຂອງຕົນເອງ ແລະ ໂດຍປົກກະຕິແລ້ວຈະລຶບລຸ້ນທີ່ເປັນອັນຕະລາຍອອກ ຫຼື ດຳເນີນການເພີ່ມເຕີມ, ເຊັ່ນ: ການບລັອກ ຫຼື ການລຶບບັນຊີຜູ້ໃຊ້ທີ່ກ່ຽວຂ້ອງ.
ພວກເຮົາຈະອະທິບາຍວິທີທີ່ພວກເຮົາກຳລັງຊ່ວຍ NPM, PyPI, GitHub ແລະ ໂຄງສ້າງພື້ນຖານທີ່ສຳຄັນອື່ນໆໃນລະບົບນິເວດແຫຼ່ງເປີດເພື່ອຫຼຸດຜ່ອນເວລາການໃຊ້ງານຂອງອົງປະກອບທີ່ເປັນອັນຕະລາຍໃໝ່ທີ່ເຜີຍແຜ່ຍັງຄົງເຄື່ອນໄຫວຢູ່ຈົນກວ່າມັນຈະຖືກຢືນຢັນມັນແວ ແລະ ຖືກລຶບອອກຈາກທະບຽນ. ແລະ ວິທີທີ່ອົງກອນຕ່າງໆອາດຈະໄດ້ຮັບຜົນປະໂຫຍດຈາກລະບົບ MEW ເພື່ອໃຫ້ມີການປົກປ້ອງທີ່ດີກວ່າຕໍ່ກັບການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງຊອບແວທີ່ກ່ຽວຂ້ອງກັບອົງປະກອບແຫຼ່ງເປີດ.
- [1] ເຖິງຢ່າງໃດກໍ່ຕາມ, ຜູ້ໃຊ້ຂອງອົງປະກອບຕ້ອງກວດສອບວ່າ tarball ຂອງອົງປະກອບຖືກເກັບໄວ້ ຫຼື ລົງທະບຽນຢູ່ບ່ອນໃດບ່ອນໜຶ່ງແລ້ວ, ຕົວຢ່າງເຊັ່ນໃນ registry ພາຍໃນ, ດັ່ງນັ້ນພະຍາດດັ່ງກ່າວຈຶ່ງຖືກກຳຈັດອອກ.
- [2] ອົງປະກອບທີ່ຫຸ້ມຫໍ່ປະກອບມີ manifest ທີ່ປະກາດເນື້ອໃນ ແລະ metadata, ລະຫັດແຫຼ່ງຂໍ້ມູນ ຫຼື ລະຫັດທີ່ລວບລວມແລ້ວ, ສະຄຣິບການຕິດຕັ້ງ ແລະ ລາຍການເພີ່ມເຕີມເຊັ່ນ: ຊຸດການທົດສອບ, ຕາມຮູບແບບການຫຸ້ມຫໍ່ ແລະ ໂດຍປົກກະຕິແລ້ວຈະຢູ່ໃນຮູບແບບບີບອັດ. ອັນນີ້ເອີ້ນວ່າ "component tarball".
- [3] ເຖິງແມ່ນວ່າຜູ້ກະທຳທີ່ເປັນອັນຕະລາຍສາມາດດັດແປງອົງປະກອບທີ່ເຜີຍແຜ່ໄດ້ຍ້ອນການລະເມີດໃນ registry ເອງ, ການສັງລວມລະຫັດລັບແບບທຳມະດາສາມາດກວດພົບການປ່ຽນແປງໃດໆໃນ tarball ຫຼັງຈາກການວິເຄາະສຳເລັດແລ້ວ.
- [4] ຈື່ໄວ້ວ່າອົງປະກອບທີ່ເປັນອັນຕະລາຍບາງອັນຈະເຮັດວຽກໃນເວລາຕິດຕັ້ງ, ສະນັ້ນມັນສາມາດສົ່ງຜົນກະທົບຕໍ່ໂຫນດນັກພັດທະນາທີ່ເຮັດວຽກ "npm install X" ໂດຍບໍ່ຮູ້ຕົວດ້ວຍ X ເປັນອົງປະກອບທີ່ເປັນອັນຕະລາຍ.
