ການຮົ່ວໄຫຼຂອງຄວາມລັບບໍ່ແມ່ນກ່ຽວກັບລະຫັດທີ່ບໍ່ດີ ຫຼື ຫ້ອງສະໝຸດທີ່ມີຄວາມສ່ຽງສະເໝີໄປ. ບາງຄັ້ງ, ມັນຂຶ້ນກັບວິທີທີ່ພວກເຮົາຈັດການຄວາມລັບໃນລະຫວ່າງການແລ່ນ CI, ແລະ CVE‑2025‑30066 ແມ່ນຕົວຢ່າງຂອງປຶ້ມແບບຮຽນກ່ຽວກັບວິທີທີ່ມັນສາມາດໄປຂ້າງໆໄດ້. GitHub Action tj‑actions/changed‑files, ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງເພື່ອກວດຫາໄຟລ໌ທີ່ປ່ຽນແປງໃນ pull requests, ໄດ້ກາຍເປັນຊ່ອງທາງທີ່ງຽບສະຫງົບສຳລັບການຮົ່ວໄຫຼລັບ. ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນ ແລະ ວິທີທີ່ເຈົ້າສາມາດລັອກຕົວເອງໄດ້ CI/CD ຄວາມລັບ pipeline.
ມີຫຍັງເກີດຂຶ້ນໃນ CVE‑2025‑30066?
ໃນກາງເດືອນມີນາ 2025, ໄຟລ໌ tj-actions/changed-files ໄດ້ຖືກໂຈມຕີ. ຜູ້ໂຈມຕີໄດ້ຂຽນແທັກເວີຊັນທີ່ມີຢູ່ແລ້ວຄືນໃໝ່ (ສູງເຖິງ v45.0.7) ເພື່ອຊີ້ໄປຫາໂປຣແກຣມທີ່ເປັນອັນຕະລາຍ. commitສິ່ງນີ້ປ່ຽນແປງພຶດຕິກຳຂອງການກະທຳໂດຍທີ່ນັກພັດທະນາບໍ່ສັງເກດເຫັນ; ບໍ່ມີລຸ້ນໃໝ່ຖືກປ່ອຍອອກມາ, ພຽງແຕ່ການແຊກແຊງແທັກທີ່ເບິ່ງບໍ່ເຫັນເທົ່ານັ້ນ.
ຂໍ້ມູນດັ່ງກ່າວແມ່ນງ່າຍດາຍແຕ່ເປັນອັນຕະລາຍ: ມັນໄດ້ດຶງເອົາສະຄຣິບ Python ທີ່ເຂົ້າລະຫັດ Base64 ຈາກໄລຍະໄກທີ່ສະແກນໜ່ວຍຄວາມຈຳຂອງ runner ເພື່ອຫາຂໍ້ມູນປະຈຳຕົວ, ຖິ້ມຂໍ້ມູນເຫຼົ່ານັ້ນເຂົ້າໃນບັນທຶກ ຫຼື ກັ່ນຕອງຂໍ້ມູນເຫຼົ່ານັ້ນອອກ. ນີ້ບໍ່ແມ່ນຂໍ້ບົກຜ່ອງຂອງລະຫັດທີ່ມີເຫດຜົນໃນໄຟລ໌ tj-actions/changed-files; ມັນເປັນການລ່ວງລະເມີດວິທີການຮົ່ວໄຫຼຂອງຄວາມລັບສາມາດເກີດຂຶ້ນພາຍໃນຂະບວນການເຮັດວຽກ CI ໂດຍໃຊ້ການກະທຳທີ່ນຳໃຊ້ຄືນໄດ້ນັ້ນ. CVE-2025-30066 ບໍ່ແມ່ນກ່ຽວກັບການລົ້ນຂອງບັຟເຟີ; ມັນກ່ຽວກັບຄວາມລົ້ມເຫຼວຂອງການອອກແບບ CI ທີ່ເຮັດໃຫ້ຄວາມລັບຮົ່ວໄຫຼ.
ຜົນກະທົບ: repo ໃດໆທີ່ໃຊ້ tj-actions/changed-files ເວີຊັນທີ່ໄດ້ຮັບຜົນກະທົບມີຄວາມສ່ຽງທີ່ຈະຮົ່ວໄຫຼຄວາມລັບ, ໂດຍສະເພາະຖ້າໂທເຄັນ ຫຼື ໄຟລ໌ທີ່ລະອຽດອ່ອນຖືກຈັດການຢ່າງບໍ່ປອດໄພໃນຮູບແບບໄຟລ໌ ຫຼື ຜົນຜະລິດ CI.
ເປັນຫຍັງສິ່ງນີ້ຈຶ່ງສົ່ງຜົນກະທົບຕໍ່ຂະບວນການເຮັດວຽກໂດຍອີງໃສ່ການກະທຳທີ່ນຳໃຊ້ຄືນໄດ້
ຂັ້ນຕອນການເຮັດວຽກ DevSecOps ອີງໃສ່ tj-actions/changed-files ຢ່າງຫຼວງຫຼາຍເພື່ອ:
- ອັດຕະໂນມັດ pull request checks
- ລະບຸໄຟລ໌ທີ່ປ່ຽນແປງໃນເສັ້ນທາງສະເພາະ
- ຫຼີກລ່ຽງວຽກງານ CI ທີ່ຊໍ້າຊ້ອນ
ແຕ່ຂັ້ນຕອນການເຮັດວຽກເຫຼົ່ານີ້ມັກຈະມອງຂ້າມສິ່ງໜຶ່ງຄື: ຮູບແບບ glob ອາດຈະປະກອບມີຂໍ້ມູນທີ່ລະອຽດອ່ອນແນວໃດ. ນັກພັດທະນາສົມມຸດວ່າ tj-actions/changed-files ເຮັດວຽກຢ່າງປອດໄພຕາມຄ່າເລີ່ມຕົ້ນ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານ glob ການຕັ້ງຄ່າ/** ແລະຄວາມລັບຕ່າງໆຖືກເກັບໄວ້ໃນ configs/secrets.env, ທ່ານຫາກໍ່ເພີ່ມໄຟລ໌ລັບເຂົ້າໃນຜົນຜະລິດ CI ຫຼືບັນທຶກ. ນັ້ນບໍ່ແມ່ນຂໍ້ຜິດພາດໃນການກະທຳ; ມັນແມ່ນ CI/CD ຄວາມລົ້ມເຫຼວຂອງການອອກແບບທີ່ນໍາໄປສູ່ການຮົ່ວໄຫຼລັບ. CVE‑2025‑30066 ແມ່ນຕົວຢ່າງທີ່ຊັດເຈນຂອງເລື່ອງນີ້.
ການຮົ່ວໄຫຼລັບເກີດຂຶ້ນໄດ້ແນວໃດ (ການວິເຄາະຊ່ອງໂຫວ່)
ລອງມາກວດສອບຄວາມລົ້ມເຫຼວຫຼັກທີ່ຢູ່ເບື້ອງຫຼັງ CVE‑2025‑30066:
- ຮູບແບບ Globing ເຊັ່ນ **/*.env ຈັບຄູ່ໄຟລ໌ລັບໂດຍບໍ່ໄດ້ຕັ້ງໃຈ
- tj‑actions/changed‑files ໄດ້ປະຕິບັດຕໍ່ຄວາມລັບເຫຼົ່ານັ້ນເປັນໄຟລ໌ທີ່ຖືກປ່ຽນແປງ
- ຄວາມລັບສິ້ນສຸດລົງໃນຜົນຜະລິດຂັ້ນຕອນ, ບັນທຶກ, ຫຼືວຽກຕໍ່ໄປ
ສິ່ງນີ້ເກີດຂຶ້ນຍ້ອນວ່າຄວາມລັບຖືກເກັບໄວ້ໃນເສັ້ນທາງທີ່ຄວບຄຸມໂດຍເວີຊັນ (ເປັນຄວາມຄິດທີ່ບໍ່ດີ), ແລະການຕັ້ງຄ່າ CI ບໍ່ໄດ້ຍົກເວັ້ນພວກມັນຢ່າງຊັດເຈນຈາກການລວມເຂົ້າກັນ (ກໍ່ບໍ່ດີເຊັ່ນກັນ). ສະນັ້ນມັນບໍ່ແມ່ນຂໍ້ຜິດພາດຂອງລະຫັດ, ມັນແມ່ນການອອກແບບ CI ທີ່ບໍ່ດີເຊິ່ງເຮັດໃຫ້ເກີດການຮົ່ວໄຫຼຄວາມລັບດ້ວຍຜົນຜະລິດຂອງ tj-actions/changed-files.
ເສັ້ນທາງການຂຸດຄົ້ນຕົວຈິງ: ຈາກວຽກ CI ໄປສູ່ການເປີດເຜີຍຂໍ້ມູນປະຈຳຕົວ
ຕົວຢ່າງການຕັ້ງຄ່າ CI ທີ່ເຮັດໃຫ້ເກີດການຮົ່ວໄຫຼລັບຜ່ານ tj‑actions/changed‑files:
If configs/secrets.env ປ່ຽນ:
- ມັນຖືກໝາຍໂດຍ tj‑actions/changed‑files
- ມັນໄດ້ລວມຢູ່ໃນ ຂັ້ນຕອນ.ການປ່ຽນແປງ.ຜົນຜະລິດ.ໄຟລ໌ທີ່ປ່ຽນແປງທັງໝົດ
- ຂັ້ນຕອນຕໍ່ມາໄດ້ບັນທຶກມັນໄວ້ ຫຼື ສົ່ງຕໍ່ໃຫ້ສະຄຣິບ, ເຊິ່ງເຮັດໃຫ້ຄວາມລັບຮົ່ວໄຫຼ
ການຮົ່ວໄຫຼນີ້ເກີດຂຶ້ນຍ້ອນວ່າເຫດຜົນຂອງ CI ປະຕິບັດຕໍ່ຄວາມລັບຄືກັບໄຟລ໌ປົກກະຕິ. ນັ້ນແມ່ນບ່ອນທີ່ການຮົ່ວໄຫຼຂອງຄວາມລັບເລີ່ມຕົ້ນ, ບໍ່ແມ່ນຍ້ອນບັຟເຟີລົ້ນ, ແຕ່ການໃຊ້ tj-actions/changed-files ໃນທາງທີ່ຜິດໃນການອອກແບບ CI ທີ່ມີຂໍ້ບົກພ່ອງ.
ການຂະຫຍາຍພັນເກີດຂຶ້ນກັບຜົນຜະລິດເຊັ່ນ:
If secrets.env ຢູ່ໃນລາຍຊື່ນັ້ນ, ຊື່ໄຟລ໌ ແລະ ເນື້ອໃນຂອງມັນອາດຈະປາກົດຢູ່ໃນບັນທຶກການສ້າງ. ແມ່ນແຕ່ເຫດຜົນແບບມີເງື່ອນໄຂເຊັ່ນ:
ສາມາດເປີດເຜີຍສິ່ງປະດິດທີ່ລະອຽດອ່ອນໄດ້. ນີ້ແມ່ນ CI/CD ຄວາມລົ້ມເຫຼວຂອງການອອກແບບທີ່ອະນຸຍາດໃຫ້ມີການຮົ່ວໄຫຼຄວາມລັບ, ບໍ່ແມ່ນຂໍ້ບົກຜ່ອງໃນລະຫັດການກະທຳ.
ວິທີການນຳໃຊ້ຂະບວນການເຮັດວຽກທີ່ສາມາດນຳໃຊ້ຄືນໄດ້ຢ່າງປອດໄພ ແລະ ປ້ອງກັນການຮົ່ວໄຫຼ
ທ່ານບໍ່ຈຳເປັນຕ້ອງປະຖິ້ມ tj-actions/changed-files. ທ່ານຄວນໃຊ້ Actions ທີ່ສາມາດນຳໃຊ້ຄືນໄດ້ໂດຍມີແນວຄິດທີ່ເນັ້ນຄວາມລັບກ່ອນ:
ວິທີປະຕິບັດທີ່ດີທີ່ສຸດໃນການຈັດການຄວາມລັບ
- ຢ່າໃຊ້ຄວາມລັບໃນການຄວບຄຸມເວີຊັນເດັດຂາດ
- ຫຼີກລ່ຽງຮູບແບບ glob ທີ່ກົງກັບເສັ້ນທາງທີ່ລະອຽດອ່ອນ
- ໃຊ້ຄວາມລັບທີ່ອີງໃສ່ສະພາບແວດລ້ອມ (GITHUB_ENV, vaults, GitHub Secrets)
CI/CD ການຕັ້ງຄ່າ Guardrails
- ໃຫ້ປັກໝຸດການກະທຳໃສ່ SHA ທີ່ບໍ່ປ່ຽນແປງສະເໝີ, ບໍ່ແມ່ນແທັກ (ຢ່າໃຊ້ @v45)
- ປະຕິບັດຕໍ່ຜົນຜະລິດຂອງ tj-actions/changed-files ວ່າມີການປົນເປື້ອນ, ຂ້າເຊື້ອ ຫຼື ກັ່ນຕອງມັນ
- ຕັ້ງຄ່າຜົນຜະລິດເທົ່ານັ້ນຖ້າຖືກທຳຄວາມສະອາດແລ້ວ
⚠️ ຕົວຢ່າງທີ່ບໍ່ປອດໄພ:
ຂ້າງເທິງນີ້ແມ່ນການໃຊ້ໃນທາງທີ່ຜິດທີ່ຢູ່ເບື້ອງຫຼັງການຮົ່ວໄຫຼລັບ ແລະ CVE‑2025‑30066.
ທາງເລືອກທີ່ປອດໄພ:
ໂດຍການເຮັດສິ່ງນີ້, ທ່ານຈະຫຼີກລ່ຽງຈາກ CI/CD ຄວາມລົ້ມເຫຼວຂອງການອອກແບບທີ່ນຳໄປສູ່ການຮົ່ວໄຫຼລັບຜ່ານ tj‑actions/changed‑files.
ນອກຈາກນັ້ນ:
- ປິດໃຊ້ງານ ຫຼື ຈຳກັດການບັນທຶກບ່ອນທີ່ຂໍ້ມູນລັບອາດຈະປາກົດຂຶ້ນ
- ໃຊ້ຄຸນສົມບັດການປິດບັງລັບຂອງ GitHub
- ຈຳກັດການເຂົ້າເຖິງບັນທຶກການສ້າງ ແລະ ສິ່ງປະດິດ
ບັນຊີກວດສອບການນຳໃຊ້ CI ທີ່ປອດໄພສຳລັບຄວາມລັບດ່ວນ
| ການປະຕິບັດທີ່ດີທີ່ສຸດ |
|---|
| ຢ່າເກັບຮັກສາຂໍ້ມູນລັບໄວ້ໃນໄຟລ໌ທີ່ຄວບຄຸມດ້ວຍເວີຊັນ |
| ໃຊ້ vaults ຫຼື GitHub Secrets ສຳລັບຂໍ້ມູນປະຈຳຕົວ |
| ປັກໝຸດ tj‑actions/changed‑files ໃສ່ SHA ທີ່ບໍ່ປ່ຽນແປງສະເໝີ |
| ກັ່ນຕອງ ຫຼື ເຮັດຄວາມສະອາດຜົນຜະລິດຈາກ tj‑actions/changed‑files |
| ຢ່າລວມເອົາເສັ້ນທາງລັບໃນຮູບແບບກ້ອນ |
| ປິດບັງ ຫຼື ຈຳກັດບັນທຶກທີ່ອາດຈະເປີດເຜີຍຂໍ້ມູນທີ່ລະອຽດອ່ອນ |
| ກວດສອບການຕັ້ງຄ່າ CI ທີ່ສືບທອດມາເລື້ອຍໆ |
ບົດບາດຂອງ Xygeni: ການບັງຄັບໃຊ້ຄວາມລັບຂອງ CI ໃນຂອບເຂດກ້ວາງຂວາງ
ຊີເກນີ ຍຶດ CI/CD pipelines ໂດຍການສຸມໃສ່ ວິທີການຈັດການ, ນຳໃຊ້ ແລະ ເປີດເຜີຍຄວາມລັບໃນໂລກແຫ່ງຄວາມເປັນຈິງ ຂະບວນການເຮັດວຽກ DevOps. ມັນບໍ່ພຽງແຕ່ກ່ຽວກັບການສະແກນລະຫັດເທົ່ານັ້ນ; ມັນກ່ຽວກັບການບັງຄັບໃຊ້ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງການຄຸ້ມຄອງລັບຜ່ານການຖ່າຍທອດສົດ pipeline ການວິເຄາະ.
ການກວດສອບການໃຊ້ຜົນຜະລິດທີ່ບໍ່ປອດໄພ
- ສະແກນການກະທຳຂອງ GitHub ສຳລັບການນຳໃຊ້ຂອງ echo, run, ແລະ ຜົນຜະລິດ ບ່ອນທີ່ ${{ steps.*.outputs.* }} ອາດຈະປະກອບມີຄ່າທີ່ລະອຽດອ່ອນ
- ລະບຸວ່າຄວາມລັບຖືກອ້າງອີງ ຫຼື ພິມໂດຍກົງ, ໂດຍເຈດຕະນາ ຫຼື ໂດຍຄວາມຜິດພາດເມື່ອໃດ
ການຕິດຕາມຄວາມລັບທີ່ຮົ່ວໄຫຼ
- ກວດຫາຄ່າ entropy ສູງ (ລະຫັດ API, ໂທເຄັນ) ພາຍໃນບັນທຶກ ແລະ ຜົນຜະລິດຂັ້ນຕອນ
- ກະຕຸ້ນການແຈ້ງເຕືອນເມື່ອຄວາມລັບປາກົດຢູ່ໃນ pipeline ທ່ອນໄມ້, ເຖິງແມ່ນວ່າຈະຖືກປິດບັງໄວ້ທາງລຸ່ມນ້ຳກໍຕາມ
ການໃຊ້ການກະທຳທີ່ຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ
- ຕິດຕາມການກະທຳທັງໝົດຂອງ GitHub ໃນທົ່ວ pipelineເພື່ອກວດຫາການໃຊ້ລຸ້ນທີ່ຖືກລະເມີດ (ຕົວຢ່າງ, tj-actions/changed-files@v45)
- ກວດສອບຮູບແບບການຈັບຄູ່ໄຟລ໌ທີ່ປະກອບມີຄວາມລັບທີ່ອາດເກີດຂຶ້ນເຊັ່ນ **/*.env, *.key, ຫຼື .env.*
CI ທີ່ອີງໃສ່ນະໂຍບາຍ Guardrails
- ບັງຄັບໃຊ້ການປັກໝຸດ SHA ສຳລັບການກະທຳຂອງພາກສ່ວນທີສາມ
- ບລັອກການໃຊ້ໄຟລ໌ທີ່ບໍ່ປອດໄພເຊິ່ງອາດຈະກວາດຂໍ້ມູນລັບເຂົ້າໄປໃນບັນທຶກໄດ້
- ການປ້ອງກັນ pipelineຈາກການປ່ອຍຄ່າທີ່ລະອຽດອ່ອນເປັນສ່ວນໜຶ່ງຂອງຜົນຜະລິດຂອງຂະບວນການເຮັດວຽກ
ໂດຍການປະຕິບັດຕໍ່ຂະບວນການເຮັດວຽກເປັນສ່ວນໜຶ່ງຂອງໄພຂົ່ມຂູ່ຂອງທ່ານ, Xygeni ຮັບປະກັນວ່າສຸຂະອະນາໄມລັບບໍ່ພຽງແຕ່ເປັນການປະຕິບັດທີ່ດີທີ່ສຸດເທົ່ານັ້ນ, ແຕ່ມັນເປັນການປ້ອງກັນທີ່ຕິດຕັ້ງມາພ້ອມ.
ສະຫຼຸບ: ການຮົ່ວໄຫຼລັບສາມາດເລີ່ມຕົ້ນດ້ວຍການໃຊ້ໃນທາງທີ່ຜິດແບບງ່າຍໆ
CVE‑2025‑30066 ບໍ່ແມ່ນຂໍ້ຜິດພາດຂອງຫ້ອງສະໝຸດ; ມັນແມ່ນ CI/CD ຄວາມລົ້ມເຫຼວຂອງການອອກແບບທີ່ເກີດຈາກການໃຊ້ tj-actions/changed-files ທີ່ບໍ່ຖືກຕ້ອງ. ສິ່ງທີ່ທີມງານ DevSecOps ຄວນປະຕິບັດ:
- ປະຕິບັດຕໍ່ທຸກໆການອ້າງອີງ glob/file ໃນ CI ເປັນຈຸດຮົ່ວໄຫຼທີ່ອາດເກີດຂຶ້ນ
- ກວດສອບຂັ້ນຕອນການເຮັດວຽກເປັນປະຈຳສຳລັບການລວມເອົາຄວາມລັບໂດຍບັງເອີນ
- ໃຊ້ຫ້ອງໂຖງທີ່ປອດໄພ ຫຼື ຄວາມລັບຂອງສະພາບແວດລ້ອມ, ຢ່າກວດສອບຄວາມລັບເຂົ້າໃນການຄວບຄຸມເວີຊັນ
- ເຮັດຄວາມສະອາດ ຫຼື ກັ່ນຕອງຜົນຜະລິດຂອງຂັ້ນຕອນການເຮັດວຽກທັງໝົດ
- ບັນທຶກກິດຈະກຳການເຮັດວຽກທີ່ລະອຽດອ່ອນເພື່ອຮັກສາຄວາມສາມາດໃນການກວດສອບ
CI ແມ່ນລະຫັດ. ຂັ້ນຕອນການເຮັດວຽກແມ່ນລະຫັດ. ບັນທຶກ ແລະ ຜົນຜະລິດແມ່ນລະຫັດ. ປົກປ້ອງຄວາມລັບຂອງທ່ານໃນທຸກໆຂັ້ນຕອນ, ຫຼື ສ່ຽງຕໍ່ສະຖານະການຮົ່ວໄຫຼຄວາມລັບທີ່ບໍ່ຕ້ອງການແຮກເກີ, ພຽງແຕ່ບໍ່ດີ. CI/CD ທາງເລືອກການອອກແບບ.
