ນັກພັດທະນາເປີດ IDE, ອະທິບາຍສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການເປັນພາສາອັງກິດທຳມະດາ, ແລະເບິ່ງຕົວແທນ AI ຂຽນຄຸນສົມບັດໃນເວລາທີ່ໃຊ້ເພື່ອຮັບກາເຟ. ມັນລວບລວມ. ມັນຜ່ານການຄລິກຜ່ານຄູ່ມື. ມັນຈັດສົ່ງ. ບໍ່ມີໃຜຖາມວ່າມັນປອດໄພຫຼືບໍ່, ເພາະວ່າບໍ່ມີໃຜຖາມຫຍັງຫຼາຍ. ການກະຕຸ້ນເຕືອນໄດ້ປ່ຽນແທນ pull request, ແລະ “ມັນໃຊ້ໄດ້” ໄດ້ປ່ຽນແທນ “ຂ້ອຍໄດ້ກວດສອບມັນແລ້ວ.” ນັ້ນແມ່ນການຂຽນໂປຣແກຣມ vibe, ແລະມັນບໍ່ແມ່ນນິໄສທີ່ບໍ່ມີປະໂຫຍດອີກຕໍ່ໄປ. ມັນແມ່ນວິທີການຂຽນລະຫັດການຜະລິດທີ່ເພີ່ມຂຶ້ນໂດຍທີມງານມືອາຊີບ, ບໍ່ພຽງແຕ່ຜູ້ທີ່ມັກທົດລອງໃຊ້ແອັບທ້າຍອາທິດເທົ່ານັ້ນ. ແລະມັນແມ່ນເຫດຜົນທີ່ວ່າເປັນຫຍັງຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ຈຶ່ງໄດ້ກາຍເປັນການສົນທະນາທີ່ຜູ້ນຳດ້ານວິສະວະກຳ ແລະ ຄວາມປອດໄພທຸກຄົນກຳລັງມີຢູ່, ບໍ່ວ່າພວກເຂົາຈະຕັ້ງຊື່ມັນແລ້ວຫຼືບໍ່.
"vibe coding" ໝາຍຄວາມວ່າແນວໃດແທ້
ການຂຽນໂປຣແກຣມແບບ Vibe ແມ່ນການພັດທະນາຊອບແວທີ່ບຸກຄົນອະທິບາຍຜົນໄດ້ຮັບທີ່ຕ້ອງການໃນພາສາທຳມະຊາດ ແລະ ຮູບແບບ AI ຫຼື ຕົວແທນທີ່ສ້າງຂຶ້ນໃນນັ້ນຈະສ້າງລະຫັດທີ່ເຮັດວຽກໄດ້. ບຸກຄົນນັ້ນຄວບຄຸມຜົນໄດ້ຮັບ (“ສ້າງ login flow,” “ເພີ່ມການສົ່ງອອກ CSV”) ແທນທີ່ຈະຂຽນ ຫຼື ທົບທວນການຈັດຕັ້ງປະຕິບັດແບບບັນທັດຕໍ່ບັນທັດ. ຄຳສັບນີ້ໄດ້ຮັບຄວາມນິຍົມເພາະມັນຈັບເອົາບາງສິ່ງບາງຢ່າງທີ່ແທ້ຈິງ: ນັກພັດທະນາກຳລັງຄິດວ່າຜົນຜະລິດຖືກຕ້ອງ, ບໍ່ແມ່ນການອ່ານລະຫັດເອງ.
ການປ່ຽນແປງນັ້ນແມ່ນເລື່ອງລາວທັງໝົດ. ການທົບທວນລະຫັດເຄີຍເປັນຈຸດກວດສອບທີ່ສ້າງຂຶ້ນໃນວິທີການຂຽນຊອບແວ. ການຂຽນໂປຣແກຣມ Vibe ກຳນົດທິດທາງອ້ອມມັນໂດຍການອອກແບບ. ຄວາມໄວເພີ່ມຂຶ້ນ. ນິໄສການຖາມວ່າ "ຕົວຈິງແລ້ວສິ່ງນີ້ເຮັດຫຍັງ" ຫຼຸດລົງ.
ເປັນຫຍັງຄຳວ່າ "ມັນໃຊ້ໄດ້" ຈຶ່ງເປັນແຖບທີ່ບໍ່ຖືກຕ້ອງ
"ມັນເຮັດວຽກ" ໝາຍຄວາມວ່າລະຫັດໄດ້ເຮັດໃນສິ່ງທີ່ຖືກຖາມ, ໃນສະຖານະການທີ່ໄດ້ຮັບການທົດສອບ. ມັນບໍ່ໄດ້ບອກຫຍັງກ່ຽວກັບສິ່ງທີ່ລະຫັດເຮັດໃນສະຖານະການທີ່ບໍ່ມີໃຜຖາມກ່ຽວກັບ: ການປ້ອນຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງ, ຜູ້ໃຊ້ທີ່ໄດ້ຮັບການພິສູດຢືນຢັນການກວດສອບຈຸດສຸດທ້າຍທີ່ໄວ້ວາງໃຈພວກເຂົາຫຼາຍເກີນໄປ, ການເພິ່ງພາອາໄສທີ່ບໍ່ເຄີຍຖືກກວດສອບ, ຄວາມລັບທີ່ຖືກລະຫັດແຂງທີ່ຢືນຢູ່ໃນສາຍຕາທີ່ເຫັນໄດ້ຊັດເຈນ. ນີ້ແມ່ນບ່ອນທີ່ຄວາມປອດໄພຂອງການຂຽນລະຫັດ vibe ລົ້ມເຫຼວກ່ອນທີ່ໃຜຈະສັງເກດເຫັນວ່າມີບັນຫາ.
ຮູບແບບການຂຽນໂປຣແກຣມ AI ໄດ້ຮັບການຝຶກອົບຮົມໃຫ້ຜະລິດຜົນຜະລິດທີ່ເຮັດວຽກໄດ້ກົງກັບຈຸດປະສົງຂອງການກະຕຸ້ນ. ຄວາມປອດໄພບໍ່ແມ່ນໜ້າທີ່ທີ່ເປັນວັດຖຸປະສົງ. ຮູບແບບທີ່ປັບປຸງໃຫ້ດີທີ່ສຸດສຳລັບ "ສິ່ງນີ້ຕອບສະໜອງຄຳຮ້ອງຂໍ" ຈະສ້າງຄຳຖາມທີ່ສ້າງຂຶ້ນດ້ວຍການຕໍ່ກັນຂອງສະຕຣິງແທນທີ່ຈະເປັນພາລາມິເຕີ, ຈຸດສິ້ນສຸດທີ່ບໍ່ມີການຄວບຄຸມການເຂົ້າເຖິງເພາະວ່າການກະຕຸ້ນບໍ່ເຄີຍກ່າວເຖິງວ່າໃຜບໍ່ຄວນມີການເຂົ້າເຖິງ, ຫຼືການເອີ້ນ API ທີ່ໄວ້ວາງໃຈການຕອບສະໜອງທີ່ມັນຄວນກວດສອບ. ມັນລວບລວມ. ມັນເຮັດວຽກ. ມັນຍັງແນະນຳຫ້ອງຮຽນຄວາມສ່ຽງດຽວກັນທີ່ທີມງານ AppSec ໄດ້ໃຊ້ເວລາທົດສະວັດໃນການຝຶກອົບຮົມນັກພັດທະນາ, ສ້າງຂຶ້ນໃນຈັງຫວະທີ່ບໍ່ມີຂະບວນການທົບທວນດ້ວຍຕົນເອງຖືກສ້າງຂຶ້ນເພື່ອຈັບຄູ່.
ການຄົ້ນຄວ້າພາຍໃນກ່ຽວກັບລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ເຮັດໃຫ້ຕົວເລກທີ່ແທ້ຈິງຢູ່ເບື້ອງຫຼັງສະຕິປັນຍາ: ສ່ວນແບ່ງທີ່ມີຄວາມໝາຍຂອງສິ່ງທີ່ເຄື່ອງມືການຂຽນໂປຣແກຣມແບບຕົວແທນຜະລິດອອກມາມີຂໍ້ບົກຜ່ອງດ້ານຄວາມປອດໄພທີ່ສາມາດນຳໃຊ້ໄດ້ໃນຄັ້ງທຳອິດ, ກ່ອນທີ່ຈະມີການທົບທວນໃດໆເກີດຂຶ້ນ. ນັ້ນບໍ່ແມ່ນຂໍ້ບົກຜ່ອງໃນຮູບແບບດຽວ. ມັນແມ່ນຜົນຜະລິດທີ່ຄາດຫວັງໄວ້ຈາກການເພີ່ມປະສິດທິພາບສຳລັບ "ມັນເຮັດວຽກ," ບໍ່ແມ່ນ "ມັນຍັງຄົງຢູ່," ແລະມັນແມ່ນຊ່ອງຫວ່າງທີ່ແນ່ນອນທີ່ຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມຕ້ອງປິດ.
ພື້ນຜິວຄວາມສ່ຽງກວ້າງກວ່າລະຫັດຕົວມັນເອງ
ການຂຽນໂປຣແກຣມ Vibe ຄວາມປອດໄພມັກຈະຖືກກຳນົດວ່າເປັນ ບັນຫາຄຸນນະພາບຂອງລະຫັດ, ແຕ່ການເປີດເຜີຍ ແລ່ນຜ່ານຂະບວນການເຮັດວຽກທັງໝົດ ຕົວແທນສຳຜັດ, ບໍ່ພຽງແຕ່ໜ້າທີ່ຂອງມັນເທົ່ານັ້ນ ຂຽນ:
ເປັນຫຍັງເຄື່ອງມື AppSec ແບບດັ້ງເດີມຈຶ່ງຊັກຊ້າຢູ່ທີ່ນີ້
ເຄື່ອງມືຄວາມປອດໄພຂອງແອັບພລິເຄຊັນສ່ວນໃຫຍ່ແມ່ນສ້າງຂຶ້ນໂດຍອີງໃສ່ຈັງຫວະ: ລະຫັດຖືກຂຽນ, ຫຼັງຈາກນັ້ນມັນຈະຖືກສະແກນ, ໃນ CI ຫຼືຢູ່ທີ່ PR. ຈັງຫວະນັ້ນສົມມຸດວ່າມີສິ່ງປະດິດທີ່ໝັ້ນຄົງ, ຂຽນໂດຍມະນຸດເພື່ອຊີ້ເຄື່ອງສະແກນໄປຫາ, ແລະປະລິມານການປ່ຽນແປງແມ່ນສິ່ງທີ່ pipeline ສາມາດທົບທວນຄືນໄດ້ຢ່າງຕັ້ງໃຈ.
ການຂຽນໂປຣແກຣມ Vibe ທຳລາຍເວລາ, ແລະຊ່ອງຫວ່າງເວລານັ້ນແມ່ນຫຼັກຂອງບັນຫາຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe. ລະຫັດປ່ຽນແປງພາຍໃນ IDE ພາຍໃນວິນາທີ, ເຊິ່ງມັກຈະກ່ອນທີ່ມັນຈະໄປຮອດ... pull requestເຄື່ອງສະແກນທີ່ເຮັດວຽກໃນ CI ເທົ່ານັ້ນຈະຈັບບັນຫາຫຼັງຈາກຄວາມຈິງ, ເມື່ອຮູບແບບທີ່ບໍ່ປອດໄພຖືກລວມເຂົ້າກັນແລ້ວ, ເຊິ່ງເປັນສ່ວນໜຶ່ງຂອງຄຸນສົມບັດຕໍ່ໄປທີ່ຄົນອື່ນກຳລັງສ້າງຕໍ່. ແລະເຄື່ອງສະແກນທີ່ປະຕິບັດລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ຄືກັນກັບລະຫັດອື່ນໆຈະພາດສ່ວນຕ່າງໆຂອງຄວາມສ່ຽງທີ່ສະເພາະກັບວິທີການຂຽນ: ແພັກເກດທີ່ຕົວແທນເລືອກໂດຍບໍ່ໄດ້ຖືກຮ້ອງຂໍໃຫ້ໃຫ້ເຫດຜົນ, ໄຟລ໌ຄຳສັ່ງທີ່ບອກຕົວແທນວ່າຕ້ອງເຮັດແນວໃດກ່ອນທີ່ມະນຸດຈະເຫັນຄວາມແຕກຕ່າງ.
ສິ່ງທີ່ປິດຊ່ອງຫວ່າງແທ້ໆ
ອົງກອນຕ່າງໆທີ່ກ້າວໄປຂ້າງໜ້ານີ້ບໍ່ໄດ້ເຮັດໃຫ້ການຂຽນໂປຣແກຣມ vibe ຊ້າລົງ. ພວກເຂົາກຳລັງສ້າງຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ທີ່ແທ້ຈິງເຂົ້າໃນຂະບວນການເຮັດວຽກ: ຍ້າຍຈຸດກວດສອບກັບຄືນໄປບ່ອນທີ່ລະຫັດຖືກຂຽນແທ້ໆ, ແລະ ປະຕິບັດຕໍ່ລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ວ່າເປັນຂໍ້ມູນທີ່ໜ້າເຊື່ອຖືຈົນກວ່າຈະພິສູດໄດ້ເປັນຢ່າງອື່ນ:
- ສະແກນພາຍໃນ IDE, ບໍ່ພຽງແຕ່ໃນ CI ເທົ່ານັ້ນ. ການຈັບຮູບແບບທີ່ບໍ່ປອດໄພໃນຂະນະທີ່ຕົວແທນຍັງສ້າງຟັງຊັນຢູ່ແມ່ນບັນຫາທີ່ແຕກຕ່າງຈາກການຈັບມັນຫຼັງຈາກຄຸນສົມບັດອີກສາມຢ່າງຂຶ້ນກັບມັນ.
- ກວດສອບຄວາມຖືກຕ້ອງຂອງທຸກໆການເພິ່ງພາອາໄສທີ່ຕົວແທນນຳສະເໜີ, ຄືກັນກັບທີ່ທ່ານຈະກວດສອບຄວາມຖືກຕ້ອງຂອງອັນທີ່ນັກພັດທະນາພິມດ້ວຍຕົນເອງກ່ອນທີ່ມັນຈະຕິດຕັ້ງ.
- ປະຕິບັດຕໍ່ໄຟລ໌ການຕັ້ງຄ່າທີ່ຕົວແທນອ່ານຄືກັບລະຫັດ, ບໍ່ແມ່ນເອກະສານ. ໄຟລ໌ກົດລະບຽບ, ໄຟລ໌ທັກສະ ແລະ ການຕັ້ງຄ່າເຊີບເວີ MCP ສາມາດມີຄຳແນະນຳທີ່ປ່ຽນແປງສິ່ງທີ່ຕົວແທນເຮັດ, ແລະ ພວກມັນສົມຄວນໄດ້ຮັບການກວດສອບຢ່າງລະອຽດຄືກັນກັບລະຫັດທີ່ຕົວແທນຜະລິດອອກມາ.
- ໃຫ້ມະນຸດຮັບຮູ້ເຖິງການແກ້ໄຂ, ບໍ່ພຽງແຕ່ທຸງເທົ່ານັ້ນ. ນັກພັດທະນາຜູ້ທີ່ສາມາດເຫັນວ່າເປັນຫຍັງບາງສິ່ງບາງຢ່າງຈຶ່ງຖືກນຳໃຊ້ໂດຍບໍ່ໄດ້ຕັ້ງໃຈ, ບໍ່ພຽງແຕ່ມັນກະຕຸ້ນກົດລະບຽບເທົ່ານັ້ນ, ແຕ່ຕົວຈິງແລ້ວຮຽນຮູ້ທີ່ຈະກະຕຸ້ນ ແລະ ທົບທວນຄືນໃນຄັ້ງຕໍ່ໄປ.
- ສົມມຸດວ່າ "ມັນໃຊ້ໄດ້" ບໍ່ເຄີຍເປັນແຖບຄວາມປອດໄພ, ແລະເຮັດໃຫ້ແຖບຕົວຈິງສາມາດເບິ່ງເຫັນໄດ້ໃນຂັ້ນຕອນການເຮັດວຽກແທນທີ່ຈະປະໄວ້ມັນໄວ້ໃນໜ່ວຍຄວາມຈຳ.
ບ່ອນທີ່ Xygeni ເໝາະສົມ
ນີ້ແມ່ນຮອຍຕໍ່ທີ່ແນ່ນອນ DevAI ຂອງ Xygeni ຖືກສ້າງຂຶ້ນເພື່ອປິດ. DevAI ເຮັດວຽກເປັນຊັ້ນຄວາມປອດໄພຢ່າງຕໍ່ເນື່ອງພາຍໃນ IDE, ເບິ່ງລະຫັດທີ່ຂຽນໂດຍມະນຸດ ແລະ ລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ໃນຂະນະທີ່ມັນຖືກຜະລິດ, ບໍ່ແມ່ນຫຼັງຈາກມັນລົງຈອດໃນ pull requestມັນບໍ່ລໍຖ້າການກະຕຸ້ນ: ມັນໝາຍເຖິງຮູບແບບທີ່ສາມາດຂູດຮີດໄດ້, ອະທິບາຍເສັ້ນທາງການໂຈມຕີທີ່ແທ້ຈິງດ້ວຍພາສາທີ່ງ່າຍດາຍ, ແລະ ສະເໜີການແກ້ໄຂທີ່ນັກພັດທະນາສາມາດທົບທວນ ແລະ ນຳໃຊ້ໄດ້ໂດຍບໍ່ຕ້ອງອອກຈາກກະແສຂອງເຂົາເຈົ້າ. ໃນດ້ານລະບົບຕ່ອງໂສ້ການສະໜອງ, MEW (ຄຳເຕືອນລ່ວງໜ້າກ່ຽວກັບມັລແວ) ຈັບແພັກເກດທີ່ເປັນອັນຕະລາຍກ່ອນທີ່ຈະມີລາຍເຊັນ, ເຊິ່ງມີຄວາມສຳຄັນຢູ່ທີ່ນີ້ໂດຍກົງ, ເນື່ອງຈາກຕົວແທນທີ່ເລືອກການເພິ່ງພາອາໄສໃນນາມຂອງທ່ານແມ່ນເວລາທີ່ແພັກເກດທີ່ຖືກລະເມີດ ຫຼື ຖືກປະນີປະນອມເຂົ້າມາໄດ້.
ພາຍໃຕ້ທັງສອງຢ່າງ, CoreAI ເຊື່ອມໂຍງສິ່ງທີ່ພົບເຫັນໃນທົ່ວລະຫັດ, ການເພິ່ງພາອາໄສ, ແລະ pipeline ເຂົ້າໄປໃນມຸມມອງຄວາມສ່ຽງທີ່ມີບູລິມະສິດອັນດຽວ, ແລະມຸມມອງນັ້ນບໍ່ໄດ້ຈຳກັດພຽງແຕ່ ຊີເຈນີ ການສະແກນຂອງຕົນເອງ. ມັນໃຊ້ໄດ້ຄືກັນ ການຄັດເລືອກ AI, ຄຳອະທິບາຍ, ແລະ ການແກ້ໄຂ ຕໍ່ກັບການຄົ້ນພົບຈາກເຄື່ອງສະແກນອື່ນໆທີ່ມີຢູ່ແລ້ວ, ສະນັ້ນການຮັກສາຄວາມປອດໄພຂອງລະຫັດ vibe ບໍ່ໄດ້ໝາຍຄວາມວ່າຈະດຶງເອົາ stack ທີ່ໃຊ້ງານໄດ້ແລ້ວອອກມາ. ມັນໝາຍເຖິງການວາງຊັ້ນໜຶ່ງໄວ້ເທິງມັນ ເຊິ່ງໃນທີ່ສຸດກໍ່ຈະເຄື່ອນທີ່ດ້ວຍຄວາມໄວທີ່ລະຫັດກຳລັງຖືກຂຽນຢູ່ໃນປະຈຸບັນ.
FAQ
ການຂຽນໂປຣແກຣມ vibe ບໍ່ປອດໄພໂດຍທຳມະຊາດບໍ?
ບໍ່. ການຂຽນໂປຣແກຣມ Vibe ເປັນວິທີການພັດທະນາ, ບໍ່ແມ່ນຊ່ອງໂຫວ່. ຄວາມສ່ຽງແມ່ນມາຈາກການຂ້າມຂັ້ນຕອນການທົບທວນຄືນທີ່ເຄີຍໃຊ້ເພື່ອຈັບຮູບແບບທີ່ບໍ່ປອດໄພ, ບໍ່ແມ່ນຈາກການໃຊ້ AI ເພື່ອຂຽນລະຫັດໃນຕອນທຳອິດ. ນັ້ນແມ່ນເຫດຜົນທີ່ຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ເປັນລະບຽບວິໄນຂອງຂະບວນການເຮັດວຽກ, ບໍ່ແມ່ນເຫດຜົນທີ່ຈະຫຼີກລ່ຽງການປະຕິບັດ.
ສາມາດມີຢູ່ໄດ້ SAST or SCA ເຄື່ອງມືຈັບຄວາມສ່ຽງດ້ານຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ບໍ?
ພວກເຂົາຈັບໄດ້ບາງສ່ວນ, ແຕ່ໂດຍປົກກະຕິແລ້ວຫຼັງຈາກລະຫັດໄດ້ລວມເຂົ້າກັນແລ້ວ, ເນື່ອງຈາກວ່າສ່ວນໃຫຍ່ເຮັດວຽກຢູ່ໃນ CI ແທນທີ່ຈະຢູ່ໃນ IDE ບ່ອນທີ່ລະຫັດຖືກສ້າງຂຶ້ນ. ໂດຍປົກກະຕິແລ້ວພວກເຂົາຍັງບໍ່ໄດ້ປະເມີນພຶດຕິກຳຂອງຕົວແທນ AI ເອງ, ເຊັ່ນ: ແພັກເກດທີ່ມັນເລືອກ ຫຼື ໄຟລ໌ການຕັ້ງຄ່າທີ່ມັນອ່ານ.
ວິທີແກ້ໄຂທີ່ມີປະສິດທິພາບສູງສຸດອັນດຽວສຳລັບຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ແມ່ນຫຍັງ?
ຍ້າຍການກວດສອບຄວາມປອດໄພໄປໄວ້ໃນ IDE, ໃນຈຸດຂອງການສ້າງ, ແທນທີ່ຈະອີງໃສ່ພຽງແຕ່ໃນພາຍຫຼັງ pipeline ສະແກນ. ການກວດພົບບັນຫາກ່ອນທີ່ມັນຈະເປັນສ່ວນໜຶ່ງຂອງສາມລັກສະນະຕໍ່ໄປທີ່ສ້າງຂຶ້ນມາເທິງມັນແມ່ນບັນຫາທີ່ແຕກຕ່າງຈາກການກວດພົບມັນຫຼັງຈາກນັ້ນ.
ການຮັກສາຄວາມປອດໄພຂອງການຂຽນໂປຣແກຣມ vibe ໝາຍເຖິງການເຮັດໃຫ້ນັກພັດທະນາຊ້າລົງບໍ?
ບໍ່ແມ່ນຖ້າການກວດສອບເກີດຂຶ້ນໃນແຖວ, ໃນ IDE, ພ້ອມດ້ວຍຄຳອະທິບາຍ ແລະ ການແກ້ໄຂທີ່ພ້ອມແລ້ວ. ເປົ້າໝາຍແມ່ນເພື່ອຮັກສາຄວາມໄວທີ່ການຂຽນໂປຣແກຣມສະເໜີໃຫ້ ໃນຂະນະທີ່ຟື້ນຟູການຕັດສິນທີ່ການທົບທວນດ້ວຍຕົນເອງເຄີຍໃຫ້.
