Google ສະເໜີ SLSA ເພື່ອປ້ອງກັນການປ່ຽນແປງທີ່ເປັນອັນຕະລາຍໃນລະຫວ່າງການພັດທະນາ

Google ໄດ້ນໍາສະເຫນີກອບຂອງ SLSA (ລະດັບລະບົບຕ່ອງໂສ້ການສະຫນອງສໍາລັບ Software Artifacts), ເຊິ່ງສະຫຼຸບປະສົບການທີ່ມີຢູ່ແລ້ວໃນການປົກປ້ອງໂຄງສ້າງພື້ນຖານການພັດທະນາຈາກການໂຈມຕີທີ່ດໍາເນີນຢູ່ໃນຂັ້ນຕອນຂອງການຂຽນລະຫັດ, ການທົດສອບ, ການປະກອບແລະການແຈກຢາຍຜະລິດຕະພັນ.

ຂະບວນການພັດທະນາແມ່ນນັບມື້ນັບສັບສົນ ແລະຂຶ້ນກັບເຄື່ອງມືຂອງພາກສ່ວນທີສາມ, ເຊິ່ງສ້າງເງື່ອນໄຂທີ່ເອື້ອອໍານວຍໃຫ້ແກ່ຄວາມກ້າວໜ້າຂອງການໂຈມຕີທີ່ກ່ຽວຂ້ອງກັບການບໍ່ລະບຸ ແລະ ຂູດຮີດຊ່ອງໂຫວ່ໃນຜະລິດຕະພັນສຸດທ້າຍ, ແຕ່ເປັນການປະນີປະນອມຂະບວນການພັດທະນາຕົວມັນເອງ (ການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງ, ປົກກະຕິແລ້ວແມ່ນແນໃສ່. ແນະນໍາການປ່ຽນແປງທີ່ເປັນອັນຕະລາຍໃນຂະບວນການຂຽນລະຫັດ, ການທົດແທນອົງປະກອບທີ່ແຈກຢາຍແລະການຂຶ້ນກັບ).

ກອບໃຊ້ເວລາເຂົ້າໄປໃນບັນຊີ 8 ປະເພດຂອງການໂຈມຕີທີ່ກ່ຽວຂ້ອງກັບໄພຂົ່ມຂູ່ຕໍ່ການປ່ຽນແປງທີ່ເປັນອັນຕະລາຍໃນຂັ້ນຕອນຂອງການພັດທະນາລະຫັດ, ການປະກອບ, ການທົດສອບແລະການແຈກຢາຍຜະລິດຕະພັນ.

• A. ລວມທັງການປ່ຽນແປງໃນລະຫັດແຫຼ່ງທີ່ມີ backdoors ຫຼືຄວາມຜິດພາດທີ່ເຊື່ອງໄວ້ທີ່ນໍາໄປສູ່ຄວາມອ່ອນແອ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: "Hypocrite Commits" - ຄວາມພະຍາຍາມທີ່ຈະສົ່ງເສີມ patches ທີ່ມີຊ່ອງໂຫວ່ເຂົ້າໄປໃນ Linux kernel.

  ວິທີການຄວາມປອດໄພທີ່ແນະນໍາ: ການທົບທວນຄືນເອກະລາດຂອງແຕ່ລະການປ່ຽນແປງໂດຍຜູ້ພັດທະນາສອງຄົນ.

• B. ການປະນີປະນອມຂອງເວທີການຄວບຄຸມລະຫັດແຫຼ່ງ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການສັກຢາທີ່ເປັນອັນຕະລາຍເຮັດກັບ backdoor ເຂົ້າໄປໃນບ່ອນເກັບມ້ຽນ Git ຂອງໂຄງການ PHP ຫຼັງຈາກລະຫັດຜ່ານຂອງຜູ້ພັດທະນາຖືກຮົ່ວໄຫຼ.

  ວິທີການປ້ອງກັນທີ່ແນະນໍາ: ຄວາມປອດໄພທີ່ເພີ່ມຂຶ້ນຂອງແພລະຕະຟອມການຄຸ້ມຄອງລະຫັດ (ໃນກໍລະນີຂອງ PHP, ການໂຈມຕີໄດ້ຖືກດໍາເນີນໂດຍຜ່ານການໂຕ້ຕອບ HTTPS ທີ່ໃຊ້ພຽງເລັກນ້ອຍ, ເຊິ່ງອະນຸຍາດໃຫ້ມີການປ່ຽນແປງທີ່ຈະສົ່ງໃນເວລາທີ່ເຂົ້າສູ່ລະບົບໂດຍໃຊ້ລະຫັດຜ່ານໂດຍບໍ່ມີການກວດສອບລະຫັດ SSH, ເຖິງແມ່ນວ່າ. ຄວາມຈິງທີ່ວ່າ MD5 ທີ່ບໍ່ຫນ້າເຊື່ອຖືໄດ້ຖືກນໍາໃຊ້ເພື່ອ hash ລະຫັດຜ່ານ).

• C. ການປ່ຽນແປງໃນຂັ້ນຕອນຂອງການໂອນລະຫັດກັບລະບົບການກໍ່ສ້າງຫຼືການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງ (ລະຫັດທີ່ບໍ່ກົງກັບລະຫັດຈາກ repository ແມ່ນສ້າງຂຶ້ນ).

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການໃສ່ backdoor ເຂົ້າໄປໃນ Webmin ໂດຍການປ່ຽນແປງໂຄງສ້າງໂຄງສ້າງ, ສົ່ງຜົນໃຫ້ການນໍາໃຊ້ໄຟລ໌ລະຫັດທີ່ແຕກຕ່າງຈາກໄຟລ໌ໃນ repository.

  ວິທີການປ້ອງກັນທີ່ສະເຫນີ: ການກວດສອບຄວາມສົມບູນແລະການກໍານົດແຫຼ່ງຂອງລະຫັດໃນເຄື່ອງແມ່ຂ່າຍການປະກອບ.

• D. ການປະນີປະນອມຂອງເວທີການປະກອບ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການໂຈມຕີ SolarWinds, ໃນໄລຍະທີ່ການຕິດຕັ້ງ backdoor ເຂົ້າໄປໃນຜະລິດຕະພັນ SolarWinds Orion ໄດ້ຖືກຮັບປະກັນໃນລະຫວ່າງຂັ້ນຕອນການປະກອບ.

  ວິທີການປ້ອງກັນທີ່ສະເຫນີ: ການປະຕິບັດມາດຕະການຄວາມປອດໄພຂັ້ນສູງສໍາລັບເວທີການປະກອບ.

• E. ການສົ່ງເສີມລະຫັດທີ່ເປັນອັນຕະລາຍໂດຍຜ່ານການເພິ່ງພາອາໄສທີ່ມີຄຸນນະພາບຕ່ໍາ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການນໍາ backdoor ເຂົ້າໄປໃນຫ້ອງສະຫມຸດເຫດການທີ່ນິຍົມໂດຍການເພີ່ມການເພິ່ງພາອາໄສທີ່ບໍ່ເປັນອັນຕະລາຍແລະຫຼັງຈາກນັ້ນລວມທັງລະຫັດທີ່ເປັນອັນຕະລາຍໃນຫນຶ່ງໃນການປັບປຸງການເພິ່ງພາອາໄສນີ້ (ການປ່ຽນແປງທີ່ເປັນອັນຕະລາຍບໍ່ໄດ້ສະທ້ອນຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ git, ແຕ່ແມ່ນ ນໍາສະເຫນີຢູ່ໃນຊຸດ MNP ສໍາເລັດຮູບເທົ່ານັ້ນ).

  ວິທີການປ້ອງກັນທີ່ແນະນໍາ: ນໍາໃຊ້ຄວາມຕ້ອງການ SLSA ຊໍ້າຄືນກັບທຸກ dependencies (ໃນກໍລະນີຂອງ event-stream, ການກວດສອບຈະເປີດເຜີຍການປະກອບຂອງລະຫັດທີ່ບໍ່ກົງກັນກັບເນື້ອໃນຂອງ repository Git ຕົ້ນຕໍ).

• F. ການອັບໂຫລດສິ່ງປະດິດທີ່ບໍ່ໄດ້ສ້າງຂຶ້ນໃນລະບົບ CI/CD.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການເພີ່ມລະຫັດອັນຕະລາຍໃສ່ສະຄິບ CodeCov, ເຊິ່ງອະນຸຍາດໃຫ້ຜູ້ໂຈມຕີສາມາດສະກັດຂໍ້ມູນທີ່ເກັບໄວ້ໃນສະພາບແວດລ້ອມຂອງລະບົບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງຂອງລູກຄ້າ.

  ວິທີການປ້ອງກັນທີ່ສະເຫນີ: ການຄວບຄຸມແຫຼ່ງແລະຄວາມສົມບູນຂອງປອມ (ໃນກໍລະນີຂອງ CodeCov, ມັນສາມາດເປີດເຜີຍໄດ້ວ່າ script Bash Uploader ທີ່ສົ່ງມາຈາກເວັບໄຊທ໌ codecov.io ບໍ່ກົງກັບລະຫັດຈາກບ່ອນເກັບຂໍ້ມູນໂຄງການ).

• G. ການປະນີປະນອມຂອງຄັງເກັບຊຸດ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ນັກຄົ້ນຄວ້າສາມາດນຳໃຊ້ກະຈົກຂອງບາງບ່ອນເກັບມ້ຽນຊຸດທີ່ນິຍົມເພື່ອແຈກຢາຍແພັກເກັດທີ່ເປັນອັນຕະລາຍຜ່ານພວກມັນ.

  ວິທີການປ້ອງກັນທີ່ແນະນໍາ: ການກວດສອບວ່າສິ່ງປະດິດທີ່ແຈກຢາຍໄດ້ຖືກລວບລວມຈາກລະຫັດແຫຼ່ງທີ່ປະກາດ.

• H. ເຮັດໃຫ້ຜູ້ໃຊ້ສັບສົນໃນການຕິດຕັ້ງແພັກເກັດທີ່ບໍ່ຖືກຕ້ອງ.

  ຕົວຢ່າງຂອງການໂຈມຕີ: ການໃຊ້ typosquatting (NPM, RubyGems, PyPI) ເພື່ອວາງແພັກເກັດຢູ່ໃນບ່ອນເກັບມ້ຽນທີ່ຄ້າຍຄືກັບການຂຽນໂປຼແກຼມທີ່ນິຍົມ (ຕົວຢ່າງ, coffe-script ແທນທີ່ຈະເປັນ coffee-script).

ເພື່ອສະກັດໄພຂົ່ມຂູ່ທີ່ຖືກທຸງ, SLSA ສະເຫນີຊຸດຄໍາແນະນໍາ, ເຊັ່ນດຽວກັນກັບເຄື່ອງມືທີ່ຈະອັດຕະໂນມັດການສ້າງ metadata ການກວດສອບ. SLSA ສະຫຼຸບວິທີການໂຈມຕີທົ່ວໄປແລະແນະນໍາແນວຄວາມຄິດຂອງຊັ້ນຄວາມປອດໄພ. ແຕ່​ລະ​ຂັ້ນ​ວາງ​ຂໍ້​ກຳ​ນົດ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ສະ​ເພາະ​ເພື່ອ​ຮັບ​ປະ​ກັນ​ຄວາມ​ສົມ​ບູນ​ຂອງ​ວັດ​ຖຸ​ບູ​ຮານ​ທີ່​ນຳ​ໃຊ້​ໃນ​ການ​ພັດ​ທະ​ນາ. ລະດັບ SLSA ທີ່ໄດ້ຮັບການສະຫນັບສະຫນູນສູງກວ່າ, ການປົກປ້ອງໄດ້ຖືກປະຕິບັດຫຼາຍຂຶ້ນແລະໂຄງສ້າງພື້ນຖານທີ່ດີຂຶ້ນແມ່ນໄດ້ຮັບການປົກປ້ອງຈາກການໂຈມຕີທົ່ວໄປ.

• SLSA 1 ຮຽກຮ້ອງໃຫ້ຂະບວນການສ້າງແມ່ນອັດຕະໂນມັດຢ່າງເຕັມສ່ວນແລະສ້າງ metadata ("ຫຼັກຖານສະແດງ") ກ່ຽວກັບວິທີການສ້າງ artifacts, ລວມທັງຂໍ້ມູນກ່ຽວກັບແຫຼ່ງຂໍ້ມູນ, ການເພິ່ງພາອາໄສ, ແລະຂະບວນການສ້າງ (ຕົວຢ່າງ metadata generator ສໍາລັບການກວດສອບແມ່ນສະຫນອງໃຫ້ສໍາລັບ GitHub Actions). SLSA 1 ບໍ່ໄດ້ລວມເອົາອົງປະກອບຂອງການປົກປ້ອງຕໍ່ກັບການດັດແກ້ທີ່ເປັນອັນຕະລາຍ, ແຕ່ພຽງແຕ່ກໍານົດລະຫັດ ແລະໃຫ້ metadata ສໍາລັບການຄຸ້ມຄອງຄວາມສ່ຽງ ແລະການວິເຄາະຄວາມສ່ຽງ.
• SLSA 2 - ຂະຫຍາຍລະດັບທໍາອິດໂດຍການຮຽກຮ້ອງໃຫ້ມີການນໍາໃຊ້ການຄວບຄຸມເວີຊັນແລະການບໍລິການປະກອບທີ່ສ້າງ metadata ທີ່ຖືກຕ້ອງ. ການນໍາໃຊ້ SLSA 2 ຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕາມຕົ້ນກໍາເນີດຂອງລະຫັດແລະປ້ອງກັນການປ່ຽນແປງລະຫັດທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດໃນກໍລະນີຂອງການບໍລິການສ້າງທີ່ເຊື່ອຖືໄດ້.
• SLSA 3 - ຢືນຢັນວ່າລະຫັດແຫຼ່ງແລະແພລະຕະຟອມການກໍ່ສ້າງຕອບສະຫນອງຄວາມຕ້ອງການຂອງມາດຕະຖານທີ່ຮັບປະກັນຄວາມສາມາດໃນການກວດສອບລະຫັດແລະຮັບປະກັນຄວາມສົມບູນຂອງ metadata ທີ່ສະຫນອງໃຫ້. ມັນສົມມຸດວ່າຜູ້ກວດສອບສາມາດຢັ້ງຢືນເວທີຕໍ່ກັບຄວາມຕ້ອງການຂອງມາດຕະຖານ.
• SLSA 4 ແມ່ນ​ລະ​ດັບ​ທີ່​ສູງ​ທີ່​ສຸດ​, ເສີມ​ລະ​ດັບ​ທີ່​ຜ່ານ​ມາ​ທີ່​ມີ​ຄວາມ​ຕ້ອງ​ການ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:
  • ການທົບທວນຄືນບັງຄັບຂອງການປ່ຽນແປງທັງຫມົດໂດຍສອງນັກພັດທະນາທີ່ແຕກຕ່າງກັນ.
  • ຂັ້ນຕອນການກໍ່ສ້າງທັງໝົດ, ລະຫັດ, ແລະການຂຶ້ນກັບຕ້ອງຖືກປະກາດຢ່າງຄົບຖ້ວນ, ການຂຶ້ນກັບທັງໝົດຈະຕ້ອງຖືກແຍກອອກ ແລະກວດສອບການແຍກກັນ, ແລະຂະບວນການສ້າງຈະຕ້ອງຖືກປະຕິບັດແບບອອບໄລນ໌.
  • ການນໍາໃຊ້ຂະບວນການສ້າງຊ້ໍາຊ້ອນຊ່ວຍໃຫ້ທ່ານສາມາດເຮັດຊ້ໍາຂະບວນການສ້າງຕົວທ່ານເອງແລະຮັບປະກັນວ່າການປະຕິບັດແມ່ນສ້າງຂຶ້ນຈາກລະຫັດແຫຼ່ງທີ່ສະຫນອງໃຫ້.
  
  
  ແຫຼ່ງຂໍ້ມູນ: opennet.ru