TL; DR
Shai-Hulud 3.0 ແມ່ນວິວັດທະນາການລ່າສຸດຂອງມັນແວ shai-hulud npm, ເຊິ່ງເປັນ ໜອນລະບົບຕ່ອງໂສ້ການສະໜອງທີ່ຂະຫຍາຍພັນດ້ວຍຕົນເອງ ການໃຊ້ແພັກເກດ npm ໃນທາງທີ່ຜິດເພື່ອລັກຂໍ້ມູນປະຈຳຕົວ, ແຜ່ລາມໂດຍອັດຕະໂນມັດ ແລະ ປະນີປະນອມ CI/CD ສະພາບແວດລ້ອມ. ບໍ່ເຫມືອນກັບຄື້ນກ່ອນໜ້ານີ້, Shai-Hulud 3.0 ໄດ້ປັບປຸງເຫດຜົນການແຜ່ກະຈາຍຂອງມັນ, ແນໃສ່ຫ້ອງສະໝຸດ frontend ທີ່ໄດ້ຮັບຄວາມນິຍົມ, ແລະເລັ່ງການຕິດເຊື້ອຜ່ານການລ່ວງລະເມີດໂທເຄັນຂອງຜູ້ຮັກສາ.
ດັ່ງນັ້ນ, ມັນແວ shai-hulud ນີ້ພິສູດອີກເທື່ອໜຶ່ງວ່າການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ npm ທີ່ທັນສະໄໝບໍ່ໄດ້ອີງໃສ່ zero-day ອີກຕໍ່ໄປ, ແຕ່ອີງໃສ່ລະບົບອັດຕະໂນມັດ, ການລ່ວງລະເມີດຄວາມໄວ້ວາງໃຈ, ແລະ ຂະບວນການເຮັດວຽກຂອງນັກພັດທະນາ.
Shai-Hulud 3.0 ແມ່ນຫຍັງ?
Shai-Hulud 3.0 ເປັນຄື້ນທີສາມທີ່ຢືນຢັນແລ້ວຂອງການໂຄສະນາມັນແວ npm shai-hulud, ຫຼັງຈາກໜອນ Shai-Hulud ຕົ້ນສະບັບ ແລະ ການລະບາດຂອງ Shai-Hulud 2.0 ໃນຂອບເຂດກວ້າງ.
ເຖິງຢ່າງໃດກໍ່ຕາມ, ເວີຊັນນີ້ບໍ່ໄດ້ນຳສະເໜີຊ່ອງໂຫວ່ໃໝ່ທີ່ຮຸນແຮງ. ແທນທີ່ຈະ, ມັນປັບປຸງປະສິດທິພາບ, ການລັກລອບ, ແລະ ການກຳນົດເປົ້າໝາຍ. ເວົ້າອີກຢ່າງໜຶ່ງ, Shai-Hulud 3.0 ເພີ່ມປະສິດທິພາບຮູບແບບການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງແທນທີ່ຈະປະດິດມັນຂຶ້ນມາໃໝ່.
ສິ່ງທີ່ສຳຄັນທີ່ສຸດ, ມັນແວຍັງສືບຕໍ່ເຮັດວຽກຄືກັບໜອນ, ບໍ່ແມ່ນເປັນແພັກເກດທີ່ເປັນອັນຕະລາຍຄັ້ງດຽວ.
ເປັນຫຍັງ Shai-Hulud 3.0 ຈຶ່ງມີຄວາມສຳຄັນຕໍ່ຄວາມປອດໄພຂອງ npm
ເມື່ອເບິ່ງໃນເບື້ອງຕົ້ນ, Shai-Hulud 3.0 ອາດເບິ່ງຄືວ່າ "ເປັນພຽງແພັກເກດ npm ທີ່ເປັນອັນຕະລາຍອີກອັນໜຶ່ງ." ເຖິງຢ່າງໃດກໍ່ຕາມ, ສົມມຸດຕິຖານນັ້ນແມ່ນເຫດຜົນທີ່ແຄມເປນນີ້ປະສົບຜົນສຳເລັດ.
ເນື່ອງຈາກວ່າລະບົບນິເວດ npm ແມ່ນອີງໃສ່ຫຼາຍຢ່າງ:
- ຄວາມໄວ້ວາງໃຈໂດຍທາງອ້ອມ
- ການຕິດຕັ້ງອັດຕະໂນມັດ
- ຂໍ້ມູນປະຈຳຕົວຂອງຜູ້ຮັກສາ
- CI/CD pipelines
ໂທເຄັນທີ່ຖືກລະເມີດອັນດຽວສາມາດເຮັດໃຫ້ເກີດການລະບາດຂອງມັລແວລະບົບຕ່ອງໂສ້ການສະໜອງ npm ຢ່າງເຕັມຮູບແບບໄດ້ຢ່າງໄວວາ.
ດັ່ງນັ້ນ, ມັນແວ shai-hulud ຈຶ່ງບໍ່ຕ້ອງການຊ່ອງໂຫວ່. ມັນໃຊ້ເປັນອາວຸດໃນຂະບວນການເຮັດວຽກປົກກະຕິ.
ເວັກເຕີໂຈມຕີ Shai-Hulud 3.0: ວິທີການທີ່ມັນແວ npm ແຜ່ລາມ
ການຕິດເຊື້ອເບື້ອງຕົ້ນຜ່ານແພັກເກດ npm ທີ່ມີອັນຕະລາຍ
ມັນແວ shai-hulud npm ເຂົ້າສູ່ລະບົບນິເວດຜ່ານແພັກເກດທີ່ຖືກໂທຣຈັນທີ່ເຜີຍແຜ່ພາຍໃຕ້ບັນຊີຜູ້ຮັກສາທີ່ຖືກຕ້ອງຕາມກົດໝາຍ ຫຼື ຖືກລະເມີດ.
ໃນຄື້ນ Shai-Hulud 3.0, ນັກຄົ້ນຄວ້າໄດ້ສັງເກດເຫັນການຕິດເຊື້ອຜ່ານ dependencies ທີ່ນິຍົມ, ລວມທັງແພັກເກດທີ່ມຸ່ງເນັ້ນໃສ່ frontend ເຊັ່ນ:
ເນື່ອງຈາກແພັກເກດເຫຼົ່ານີ້ຢູ່ໃນລະດັບສູງໃນກຣາຟການເພິ່ງພາອາໄສ, ການຕິດຕັ້ງຄັ້ງດຽວຈຶ່ງແຜ່ລາມໄປຢ່າງໄວວາໃນທົ່ວໂຄງການຕ່າງໆ.
ການເກັບກ່ຽວຂໍ້ມູນປະຈຳຕົວ ແລະ ການຂະຫຍາຍພັນຂອງໜອນ
ເມື່ອຕິດຕັ້ງແລ້ວ, Shai-Hulud 3.0 ຈະປະຕິບັດສະຄຣິບວົງຈອນຊີວິດທີ່ເປັນອັນຕະລາຍໃນລະຫວ່າງ install or postinstall.
ໃນຂັ້ນຕອນນີ້, ມັນແວ:
- ສະແກນໄຟລ໌ທ້ອງຖິ່ນ ແລະ ຕົວແປສະພາບແວດລ້ອມ
- ສະກັດເອົາໂທເຄັນ npm ແລະຂໍ້ມູນປະຈຳຕົວ GitHub
- ລະບຸບ່ອນເກັບມ້ຽນ ແລະ ແພັກເກດທີ່ສາມາດເຂົ້າເຖິງໄດ້
ດັ່ງນັ້ນ, ການຕິດເຊື້ອຈຶ່ງປ່ຽນໄປທັນທີ ການປະນີປະນອມໃນທ້ອງຖິ່ນ to ການຂະຫຍາຍຕົວທົ່ວລະບົບນິເວດ.
ເຜີຍແຜ່ຄືນໃໝ່ໂດຍອັດຕະໂນມັດໃນທົ່ວບັນດາຜົນງານຂອງຜູ້ຮັກສາ
ຫຼັງຈາກເກັບກຳຂໍ້ມູນຫຼັກຖານແລ້ວ, shai-hulud npm ມັລແວ ລະບຸແພັກເກັດທັງໝົດທີ່ເປັນເຈົ້າຂອງໂດຍຜູ້ຮັກສາທີ່ຖືກໂຈມຕີໂດຍທາງໂປຣແກຣມ.
ຫຼັງຈາກນັ້ນ, ມັນ:
- ສັກລະຫັດທີ່ເປັນອັນຕະລາຍເຂົ້າໄປໃນລຸ້ນໃໝ່
- ເຜີຍແຜ່ເວີຊັນເຫຼົ່ານັ້ນຄືນໃໝ່ໂດຍອັດຕະໂນມັດ
- ປ່ຽນຜູ້ເຄາະຮ້າຍແຕ່ລະຄົນໃຫ້ເປັນຈຸດແຈກຢາຍໃໝ່
ດັ່ງນັ້ນ, ໂທເຄັນທີ່ຖືກລັກອັນດຽວສາມາດຕິດເຊື້ອແພັກເກດ npm ຫຼາຍສິບ ຫຼື ຫຼາຍຮ້ອຍອັນພາຍໃນຊົ່ວໂມງ.
Shai-Hulud 3.0 ທຽບກັບຄື້ນກ່ອນໜ້ານີ້
ມີຫຍັງປ່ຽນແປງໃນ Shai-Hulud 3.0?
ເຖິງແມ່ນວ່າກົນໄກຫຼັກຍັງຄົງຄຸ້ນເຄີຍ, ໄຊ-ຮູລຸດ 3.0 ແນະນຳການປັບປຸງທີ່ສຳຄັນຫຼາຍຢ່າງ.
ໂດຍສະເພາະແມ່ນ:
- ເຫດຜົນຂອງການຂະຫຍາຍພັນທີ່ໄວຂຶ້ນ
- ໂຄງສ້າງການໂຫຼດທີ່ສະອາດກວ່າ
- ການປະສົມປະສານທີ່ດີກວ່າກັບການອັບເດດແພັກເກດທີ່ຖືກຕ້ອງຕາມກົດໝາຍ
- ສຽງລົບກວນຫຼຸດລົງເມື່ອທຽບກັບ Shai-Hulud 2.0
ດັ່ງນັ້ນ, ການກວດຫາໂດຍອີງໃສ່ຊື່ສຽງ ຫຼື CVEs ຢ່າງດຽວຈຶ່ງຈະບໍ່ມີປະສິດທິພາບ.
| ລັກສະນະ | ໄຊ-ຮູລຸດ 2.0 | ໄຊ-ຮູລຸດ 3.0 |
|---|---|---|
| ເວັກເຕີການຕິດເຊື້ອເບື້ອງຕົ້ນ | ແພັກເກດ npm ທີ່ເປັນອັນຕະລາຍພ້ອມດ້ວຍສະຄຣິບວົງຈອນຊີວິດທີ່ຕິດຕັ້ງລ່ວງໜ້າ | ແພັກເກດ npm ທີ່ເປັນອັນຕະລາຍໃຊ້ຫ້ອງສະໝຸດທີ່ມີຄວາມຊັດເຈນສູງ ແລະ ເສັ້ນທາງການອັບເດດທີ່ເຊື່ອຖືໄດ້ໃນທາງທີ່ຜິດ |
| ເປົ້າຫມາຍຕົ້ນຕໍ | ລະບົບນິເວດ npm ແລະ CI/CD pipelines | ລະບົບນິເວດ npm ໂດຍສຸມໃສ່ເຄື່ອງຈັກຂອງນັກພັດທະນາ ແລະ ຜູ້ບໍລິໂພກຊັ້ນລຸ່ມ |
| ກົນໄກການຂະຫຍາຍພັນ | ການລັກຂໍ້ມູນປະຈຳຕົວ ຕິດຕາມດ້ວຍການເຜີຍແຜ່ແພັກເກດຄືນໃໝ່ໂດຍອັດຕະໂນມັດ | ການນຳໃຊ້ຂໍ້ມູນປະຈຳຕົວຄືນໃໝ່ ບວກກັບການລ່ວງລະເມີດຄວາມໄວ້ວາງໃຈໃນການເພິ່ງພາອາໄສ ເພື່ອຂະຫຍາຍການເຂົ້າເຖິງໄດ້ໄວຂຶ້ນ |
| ການໃຊ້ໃນທາງທີ່ຜິດໃນເວລາແລ່ນ | ການຕິດຕັ້ງ Bun runtime ທັນທີ | ການນຳໃຊ້ຄືນເວລາແລ່ນ Node.js ທີ່ມີຢູ່ແລ້ວ ແລະ ເສັ້ນທາງການປະຕິບັດທີ່ເຊື່ອຖືໄດ້ |
| CI/CD ການລ່ວງລະເມີດ | ຂັ້ນຕອນການເຮັດວຽກ GitHub Actions ທີ່ເຊື່ອງໄວ້ ແລະ ຜູ້ແລ່ນທີ່ໂຮດດ້ວຍຕົນເອງ | ຫຼຸດລົງ CI/CD ສຽງລົບກວນ, ເນັ້ນໜັກໃສ່ການປະຕິບັດລະດັບແພັກເກດທີ່ລັບໆ |
| ພຶດຕິກຳການໂຫຼດ | payload JavaScript ຂະໜາດໃຫຍ່ທີ່ຖືກສັບສົນ ແລະ ການສະແກນສະພາບແວດລ້ອມ | ປະລິມານການໂຫຼດທີ່ນ້ອຍກວ່າ ແລະ ມີເປົ້າໝາຍຫຼາຍກວ່າ ໂດຍສຸມໃສ່ການຄົງຕົວ ແລະ ການແຜ່ຂະຫຍາຍ |
| ການກຳນົດເປົ້າໝາຍຂໍ້ມູນປະຈຳຕົວ | ໂທເຄັນ GitHub, ໂທເຄັນ npm, ຂໍ້ມູນປະຈຳຕົວຄລາວ, ຄວາມລັບ CI | ເປົ້າໝາຍຂໍ້ມູນປະຈຳຕົວດຽວກັນ, ມີການນຳໃຊ້ຄືນໃໝ່ໄວຂຶ້ນ ແລະ ການກັ່ນຕອງທີ່ເຫັນໄດ້ຊັດເຈນໜ້ອຍລົງ |
| ສິ່ງລົບກວນປະຕິບັດງານ | ມີສຽງດັງຫຼາຍ: ການສ້າງ repo ຈຳນວນຫຼາຍ, ການສີດ workflow, ການອັບໂຫຼດຈຳນວນຫຼາຍ | ສຽງລົບກວນຕ່ຳກວ່າ: ສິ່ງປະດິດທີ່ເຫັນໄດ້ໜ້ອຍລົງ, ຍາກທີ່ຈະສັງເກດເຫັນຜ່ານການກວດສອບດ້ວຍຕົນເອງ |
| ຜົນກະທົບ Radius | ໃຫຍ່ແຕ່ສາມາດກວດພົບໄດ້ຍ້ອນຂະໜາດ ແລະ ສິ່ງປະດິດ | ອາດຈະໃຫຍ່ກວ່າຍ້ອນການລັກລອບ ແລະ ການລ່ວງລະເມີດແພັກເກດທີ່ເຊື່ອຖືໄດ້ |
| ສິ່ງທ້າທາຍດ້ານການປ້ອງກັນ | ການຢຸດ CI/CD ການລ່ວງລະເມີດ ແລະ ການຮົ່ວໄຫຼຂອງຂໍ້ມູນປະຈຳຕົວ | ການກວດຫາພຶດຕິກຳທີ່ເປັນອັນຕະລາຍພາຍໃນແພັກເກດທີ່ຖືກຕ້ອງຕາມກົດໝາຍ |
ເປັນຫຍັງອັນນີ້ຍັງເປັນໜອນຄືເກົ່າ
ເຖິງວ່າຈະມີການປ່ຽນແປງເຫຼົ່ານັ້ນ, Shai-Hulud 3.0 ຍັງເປັນໜອນລະບົບຕ່ອງໂສ້ການສະໜອງ npm ຊັ້ນດຽວກັນ.
ມັນອີງໃສ່:
- ການນຳໃຊ້ຂໍ້ມູນປະຈຳຕົວຄືນໃໝ່
- ການເຜີຍແຜ່ຄືນໃໝ່ໂດຍອັດຕະໂນມັດ
- ຄວາມໄວ້ວາງໃຈໃນການເພິ່ງພາອາໄສ
- CI/CD ການປະຕິບັດ
ດັ່ງນັ້ນ, ສະພາບແວດລ້ອມໃດໆທີ່ຕິດຕັ້ງແພັກເກດ npm ໂດຍບໍ່ມີການຄວບຄຸມພຶດຕິກຳຍັງຄົງຖືກເປີດເຜີຍ.
ຕົວຊີ້ວັດຂອງການປະນີປະນອມ
ທີມງານຮັກສາຄວາມປອດໄພທີ່ກຳລັງສືບສວນມັນແວ shai-hulud ຄວນຊອກຫາສັນຍານຕໍ່ໄປນີ້:
- ການຂັດຂວາງເວີຊັນແພັກເກດທີ່ບໍ່ຄາດຄິດ
- ສະຄຣິບວົງຈອນຊີວິດຖືກເພີ່ມເຂົ້າໂດຍບໍ່ມີເຫດຜົນ
- ບລັອກ JavaScript ທີ່ຖືກເຮັດໃຫ້ສັບສົນ
- ການຮ້ອງຂໍເຄືອຂ່າຍອອກໃນລະຫວ່າງການຕິດຕັ້ງ
- npm ຫຼື GitHub ໂທເຄັນທີ່ເຂົ້າເຖິງໃນເວລາຕິດຕັ້ງ
- CI/CD ວຽກທີ່ມີພຶດຕິກຳຜິດປົກກະຕິຫຼັງຈາກອັບເດດການເພິ່ງພາອາໄສ
ສິ່ງສຳຄັນ, ບໍ່ມີສິ່ງໃດໃນນີ້ທີ່ຕ້ອງການ CVE.
ເປັນຫຍັງຕ້ອງໃຊ້ເຄື່ອງມືຄວາມປອດໄພ npm ແບບດັ້ງເດີມ Miss Shai-Hulud 3.0
ການກວດສອບທີ່ອີງໃສ່ CVE ລົ້ມເຫຼວ
ເນື່ອງຈາກ Shai-Hulud 3.0 ໃຊ້ຂະບວນການເຮັດວຽກທີ່ຖືກຕ້ອງຕາມກົດໝາຍ, ເຄື່ອງສະແກນທີ່ສຸມໃສ່ພຽງແຕ່ຊ່ອງໂຫວ່ທີ່ຮູ້ຈັກເທົ່ານັ້ນຈຶ່ງບໍ່ເຫັນວ່າມີຫຍັງຜິດປົກກະຕິ.
ມີ:
- ບໍ່ມີໜ້າທີ່ທີ່ມີຄວາມສ່ຽງ
- ບໍ່ມີ API ທີ່ບໍ່ປອດໄພ
- ບໍ່ມີການເສຍຫາຍຂອງໜ່ວຍຄວາມຈຳ
ແທນທີ່ຈະ, ມັນມີເຈດຕະນາຮ້າຍທີ່ຝັງຢູ່ໃນ JavaScript ປົກກະຕິ.
SBOM ການເບິ່ງເຫັນບໍ່ພຽງພໍ
ເຊັ່ນດຽວກັນ, SBOMs ສາມາດບອກທ່ານ ແມ່ນຫຍັງ ເຈົ້າຂຶ້ນກັບ, ແຕ່ບໍ່ແມ່ນ ມັນເຮັດຫຍັງໃນເວລາຕິດຕັ້ງ.
ດັ່ງນັ້ນ, ການເບິ່ງເຫັນໂດຍບໍ່ມີການບັງຄັບໃຊ້ຈຶ່ງບໍ່ສາມາດຢຸດໜອນລະບົບຕ່ອງໂສ້ການສະໜອງໄດ້.
ວິທີທີ່ Xygeni ປ້ອງກັນການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ Shai-Hulud 3.0 npm
ນີ້ແມ່ນບ່ອນທີ່ສະຖາປັດຕະຍະກຳຂອງ Xygeni ມີຄວາມສຳຄັນ.
ຄຳເຕືອນລ່ວງໜ້າກ່ຽວກັບມັລແວ (MEW): ຢຸດມັລແວ npm ໃນເວລາທີ່ເຜີຍແຜ່
ຄຳເຕືອນລ່ວງໜ້າກ່ຽວກັບມັນແວ (MEW) ຂອງ Xygeni ສະແກນແພັກເກດ npm ທີ່ເຜີຍແຜ່ໃໝ່ຢ່າງຕໍ່ເນື່ອງໃນເວລາຈິງ.
MEW ກວດພົບ:
- ນ້ຳໜັກທີ່ສັບສົນ
- ສະຄຣິບວົງຈອນຊີວິດທີ່ໜ້າສົງໄສ
- ພຶດຕິກຳການເກັບກ່ຽວຂໍ້ມູນປະຈຳຕົວ
- ລະບົບໄຟລ໌ຂຽນຜິດປົກກະຕິ
- ກິດຈະກຳເຄືອຂ່າຍທີ່ບໍ່ຄາດຄິດ
ສິ່ງທີ່ສຳຄັນທີ່ສຸດ, MEW ສາມາດບລັອກການສ້າງໄດ້ໂດຍອັດຕະໂນມັດ, ປ້ອງກັນບໍ່ໃຫ້ມັນແວ shai-hulud npm ເຂົ້າມາໄດ້. CI/CD.
Guardrails: ບັງຄັບໃຊ້ພຶດຕິກຳການເພິ່ງພາອາໄສທີ່ປອດໄພ
ຊີເກນີ Guardrails ບັງຄັບໃຊ້ນະໂຍບາຍທີ່ເຂັ້ມງວດພາຍໃນ pipelines.
ພວກເຂົາ:
- ບລັອກແພັກເກດ npm ທີ່ເປັນອັນຕະລາຍ ຫຼື ໜ້າສົງໄສ
- ປ້ອງກັນບໍ່ໃຫ້ສະຄຣິບຕິດຕັ້ງທີ່ເຊື່ອງໄວ້ເຮັດວຽກ
- ຢຸດການດາວໂຫຼດແບບ runtime ໃນລະຫວ່າງການສ້າງ
- ບັງຄັບໃຊ້ຄວາມສົມບູນຂອງໄຟລ໌ລັອກ
ດັ່ງນັ້ນ, ໄດ້ pipeline ຢຸດກ່ອນທີ່ໜອນຈະຂ້າຕົວຕາຍ.
CI/CD ຄວາມປອດໄພ: ປົກປ້ອງ Pipelines ຈາກການລ່ວງລະເມີດ
ເນື່ອງຈາກວ່າ Shai-Hulud 3.0 ມັກຈະຫັນໄປເປັນ CI/CD, ຈໍພາບ Xygeni pipelines ສໍາລັບ:
- ການປ່ຽນແປງຂັ້ນຕອນການເຮັດວຽກທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ
- ຮູບແບບການປະຕິບັດທີ່ຜິດປົກກະຕິ
- ການໃຊ້ສິດອະນຸຍາດໃນທາງທີ່ຜິດ
- ການສີດກະແສວຽກທີ່ເກີດຈາກການເພິ່ງພາອາໄສ
ຖ້າພຶດຕິກຳທີ່ມີຄວາມສ່ຽງປະກົດຂຶ້ນ, Xygeni ຈະສະກັດກັ້ນ pipeline ທັນທີ, ຕັດການເຄື່ອນໄຫວຂ້າງຕົວ.
ການປົກປ້ອງຄວາມລັບ: ຫຼຸດຜ່ອນລັດສະໝີການລະເບີດ
ເນື່ອງຈາກມັນແວ shai-hulud ລັກຂໍ້ມູນປະຈຳຕົວຢ່າງຮຸກຮານ, Xygeni ຍັງສຸມໃສ່ຄວາມລັບ.
ຊີເຈນີ:
- ກວດພົບຄວາມລັບທີ່ຖືກເປີດເຜີຍທົ່ວ SDLC
- ໝູນວຽນຂໍ້ມູນປະຈຳຕົວທີ່ມີຄວາມສ່ຽງສູງໂດຍອັດຕະໂນມັດ
- ບັງຄັບໃຊ້ການປະຕິບັດໂທເຄັນທີ່ປອດໄພກວ່າ
ດັ່ງນັ້ນ, ເຖິງແມ່ນວ່າມັນແວຈະເຮັດວຽກ, ຄວາມລັບທີ່ຖືກລັກກໍ່ສູນເສຍມູນຄ່າຢ່າງໄວວາ.
ເປັນຫຍັງ Shai-Hulud 3.0 ຈຶ່ງຢືນຢັນແນວໂນ້ມໄລຍະຍາວ
ໃນທີ່ສຸດ, Shai-Hulud 3.0 ຢືນຢັນຄວາມເປັນຈິງທີ່ກວ້າງຂວາງກວ່າ.
ການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ npm ທີ່ທັນສະໄໝ:
- ແຜ່ລາມໂດຍອັດຕະໂນມັດ
- ເຄື່ອນໄຫວໄວກວ່າການກວດສອບຂອງມະນຸດ
- ໃຊ້ປະໂຫຍດຈາກຄວາມໄວ້ວາງໃຈ, ບໍ່ແມ່ນຊ່ອງໂຫວ່
- ເປົ້າຫມາຍ pipelines, ບໍ່ພຽງແຕ່ລະຫັດເທົ່ານັ້ນ
ດັ່ງນັ້ນ, ການປ້ອງກັນມັນແວ shai-hulud npm ຈຶ່ງຮຽກຮ້ອງໃຫ້ມີການກວດຈັບ ແລະ ການບັງຄັບໃຊ້ພຶດຕິກຳ, ບໍ່ພຽງແຕ່ການສະແກນເທົ່ານັ້ນ.
ໝາຍເຫດສຸດທ້າຍ: ເປັນຫຍັງ Shai-Hulud 3.0 ຍັງມີຄວາມສຳຄັນ
ເຖິງແມ່ນວ່າ Shai-Hulud 3.0 ບໍ່ໄດ້ນຳສະເໜີຊ່ອງໂຫວ່ໃໝ່ທີ່ໜ້າຕື່ນເຕັ້ນ, ແຕ່ມັນເປັນຕົວແທນຂອງຮູບແບບການໂຈມຕີທີ່ເຕີບໃຫຍ່ເຕັມທີ່, ເຮັດຊ້ຳໄດ້ ແລະ ສາມາດຂະຫຍາຍໄດ້.
ເວົ້າອີກຢ່າງໜຶ່ງ, ນີ້ຈະບໍ່ແມ່ນຄື້ນສຸດທ້າຍ.
ທີມທີ່ອີງໃສ່ຄວາມປອດໄພແບບຕອບໂຕ້ຈະສືບຕໍ່ໄລ່ລ່າການຕິດເຊື້ອ. ທີມທີ່ສະກັດກັ້ນພຶດຕິກຳທີ່ເປັນອັນຕະລາຍແຕ່ຫົວທີຈະຢຸດໜອນໄດ້ຢ່າງສິ້ນເຊີງ.
ນັ້ນແມ່ນຄວາມແຕກຕ່າງ.
