ຄວາມຢ້ານກົວແລະການ Loathing ຂອງ DevSecOps

ພວກ​ເຮົາ​ມີ 2 ເຄື່ອງ​ວິ​ເຄາະ​ລະ​ຫັດ, 4 ເຄື່ອງ​ມື​ການ​ທົດ​ສອບ​ການ​ເຄື່ອນ​ໄຫວ, ຫັດ​ຖະ​ກໍາ​ຂອງ​ພວກ​ເຮົາ​ເອງ​ແລະ 250 scripts. ມັນບໍ່ແມ່ນວ່າສິ່ງທັງຫມົດນີ້ແມ່ນຈໍາເປັນໃນຂະບວນການປະຈຸບັນ, ແຕ່ເມື່ອທ່ານເລີ່ມປະຕິບັດ DevSecOps, ທ່ານຕ້ອງໄປເຖິງທີ່ສຸດ.

ແຫຼ່ງຂໍ້ມູນ. ຜູ້ສ້າງຕົວລະຄອນ: Justin Roiland ແລະ Dan Harmon.

SecDevOps ແມ່ນຫຍັງ? ຈະເປັນແນວໃດກ່ຽວກັບ DevSecOps? ຄວາມແຕກຕ່າງແມ່ນຫຍັງ? Application Security - ມັນກ່ຽວກັບຫຍັງ? ເປັນ​ຫຍັງ​ວິ​ທີ​ການ​ຄລາ​ສ​ສິກ​ບໍ່​ໄດ້​ເຮັດ​ວຽກ​ອີກ​ຕໍ່​ໄປ​? ຮູ້ຄໍາຕອບຂອງຄໍາຖາມເຫຼົ່ານີ້ທັງຫມົດ Yuri Shabalin ຈາກນັ້ນ Swordfish ຄວາມປອດໄພ. Yuri ຈະຕອບທຸກຢ່າງຢ່າງລະອຽດແລະວິເຄາະບັນຫາຂອງການຫັນປ່ຽນຈາກຮູບແບບຄວາມປອດໄພຂອງ Application ຄລາສສິກໄປສູ່ຂະບວນການ DevSecOps: ວິທີການປະສົມປະສານຂອງຂະບວນການພັດທະນາທີ່ປອດໄພເຂົ້າໄປໃນຂະບວນການ DevOps ຢ່າງຖືກຕ້ອງແລະບໍ່ທໍາລາຍສິ່ງໃດ, ວິທີການຜ່ານຂັ້ນຕອນຕົ້ນຕໍ. ການທົດສອບຄວາມປອດໄພ, ເຄື່ອງມືໃດທີ່ສາມາດນໍາໃຊ້ໄດ້, ແລະສິ່ງທີ່ພວກມັນແຕກຕ່າງກັນແລະວິທີການກໍານົດພວກມັນຢ່າງຖືກຕ້ອງເພື່ອຫຼີກເວັ້ນການ pitfalls.

ກ່ຽວ​ກັບ​ຜູ້​ເວົ້າ​: Yuri Shabalin - ຫົວໜ້າສະຖາປະນິກຄວາມປອດໄພໃນບໍລິສັດ Swordfish ຄວາມປອດໄພ. ຮັບຜິດຊອບໃນການປະຕິບັດ SSDL, ສໍາລັບການລວມເອົາເຄື່ອງມືການວິເຄາະຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນລະບົບນິເວດການພັດທະນາແບບປະສົມປະສານແລະການທົດສອບ. 7 ປີຂອງປະສົບການໃນຄວາມປອດໄພຂໍ້ມູນຂ່າວສານ. ເຮັດວຽກຢູ່ Alfa-Bank, Sberbank ແລະ Positive Technologies, ເຊິ່ງພັດທະນາຊອບແວ ແລະໃຫ້ບໍລິການ. ລໍາໂພງຢູ່ໃນກອງປະຊຸມສາກົນ ZerONnights, PHDays, RISSPA, OWASP.

ຄວາມປອດໄພຂອງແອັບພລິເຄຊັນ: ມັນກ່ຽວກັບຫຍັງ?

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

Direction SDL ຫຼື SDLC - ວົງຈອນການພັດທະນາຄວາມປອດໄພ - ພັດ​ທະ​ນາ​ໂດຍ Microsoft​. ແຜນວາດສະແດງໃຫ້ເຫັນຮູບແບບ Canonical SDLC, ຫນ້າທີ່ຕົ້ນຕໍແມ່ນການມີສ່ວນຮ່ວມຂອງຄວາມປອດໄພໃນທຸກຂັ້ນຕອນຂອງການພັດທະນາ, ຈາກຄວາມຕ້ອງການກັບການປ່ອຍແລະການຜະລິດ. Microsoft ຮູ້ວ່າມີແມງໄມ້ຫຼາຍເກີນໄປໃນອຸດສາຫະກໍາ, ມີພວກມັນຫຼາຍກວ່ານັ້ນແລະບາງສິ່ງບາງຢ່າງທີ່ຕ້ອງເຮັດກ່ຽວກັບມັນ, ແລະພວກເຂົາໄດ້ສະເຫນີວິທີການນີ້, ເຊິ່ງໄດ້ກາຍເປັນ canonical.

ຄວາມປອດໄພຂອງແອັບພລິເຄຊັນ ແລະ SSDL ບໍ່ໄດ້ມີຈຸດປະສົງເພື່ອກວດຫາຊ່ອງໂຫວ່, ດັ່ງທີ່ເຊື່ອກັນທົ່ວໄປ, ແຕ່ເພື່ອປ້ອງກັນການປະກົດຕົວຂອງມັນ. ເມື່ອເວລາຜ່ານໄປ, ວິທີການ canonical ຂອງ Microsoft ໄດ້ຖືກປັບປຸງ, ພັດທະນາ, ແລະນໍາສະເຫນີເຂົ້າໄປໃນການດໍານ້ໍາທີ່ເລິກເຊິ່ງກວ່າ, ລະອຽດກວ່າ.

SDLC canonical ແມ່ນລາຍລະອຽດສູງໃນວິທີການຕ່າງໆ - OpenSAMM, BSIMM, OWASP. ວິທີການແມ່ນແຕກຕ່າງກັນ, ແຕ່ໂດຍທົ່ວໄປແມ່ນຄ້າຍຄືກັນ.

ການກໍ່ສ້າງຄວາມປອດໄພໃນຮູບແບບການໃຫຍ່ເຕັມຕົວ

ຂ້ອຍມັກມັນທີ່ສຸດ BSIMM - ການກໍ່ສ້າງຄວາມປອດໄພໃນຮູບແບບການໃຫຍ່ເຕັມຕົວ. ພື້ນຖານຂອງວິທີການແມ່ນການແບ່ງຂະບວນການຄວາມປອດໄພຂອງຄໍາຮ້ອງສະຫມັກອອກເປັນ 4 ໂດເມນ: ການປົກຄອງ, ສະຕິປັນຍາ, SSDL Touchpoints ແລະການປະຕິບັດ. ແຕ່ລະໂດເມນມີ 12 ການປະຕິບັດ, ເຊິ່ງເປັນຕົວແທນ 112 ກິດຈະກໍາ.

ແຕ່ລະກິດຈະກໍາ 112 ມີ 3 ລະ​ດັບ​ຂອງ​ການ​ໃຫຍ່​ເຕັມ​ຕົວ​: ຜູ້ເລີ່ມຕົ້ນ, ລະດັບປານກາງ ແລະຂັ້ນສູງ. ທ່ານສາມາດສຶກສາການປະຕິບັດທັງຫມົດ 12 ພາກສ່ວນໂດຍພາກສ່ວນ, ເລືອກເອົາສິ່ງທີ່ສໍາຄັນສໍາລັບທ່ານ, ຄິດໄລ່ວິທີການປະຕິບັດພວກມັນແລະຄ່ອຍໆເພີ່ມອົງປະກອບ, ຕົວຢ່າງ, ການວິເຄາະລະຫັດຄົງທີ່ແລະແບບເຄື່ອນໄຫວຫຼືການທົບທວນຄືນລະຫັດ. ທ່ານຂຽນແຜນການແລະສະຫງົບເຮັດວຽກຕາມມັນເປັນສ່ວນຫນຶ່ງຂອງການປະຕິບັດກິດຈະກໍາທີ່ເລືອກ.

ເປັນຫຍັງ DevSecOps

DevOps ແມ່ນຂະບວນການທົ່ວໄປ, ຂະຫນາດໃຫຍ່ທີ່ຄວາມປອດໄພຕ້ອງໄດ້ຮັບການພິຈາລະນາ.

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

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

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

ການຫັນປ່ຽນໄປສູ່ DevSecOps

ຄໍາທີ່ສໍາຄັນທີ່ສຸດໃນວົງຈອນການພັດທະນາຄວາມປອດໄພແມ່ນ "ຂະບວນການ". ທ່ານຕ້ອງເຂົ້າໃຈເລື່ອງນີ້ກ່ອນທີ່ທ່ານຈະຄິດກ່ຽວກັບການຊື້ເຄື່ອງມື.

ພຽງແຕ່ການລວມເອົາເຄື່ອງມືເຂົ້າໃນຂະບວນການ DevOps ແມ່ນບໍ່ພຽງພໍ - ການສື່ສານແລະຄວາມເຂົ້າໃຈລະຫວ່າງຜູ້ເຂົ້າຮ່ວມຂະບວນການແມ່ນສໍາຄັນ.

ປະຊາຊົນມີຄວາມສໍາຄັນກວ່າ, ບໍ່ແມ່ນເຄື່ອງມື.

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

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

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

ເລີ່ມຕົ້ນດ້ວຍສິ່ງທີ່ໃຊ້ແລ້ວ

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

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

- ໃນປັດຈຸບັນ, ບາງບ່ອນໃນບັນທຶກມີເສັ້ນທາງທີ່ເອກະສານນີ້ນອນ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບເອກະສານຫນຶ່ງອາທິດຕໍ່ມາ.

ສໍາລັບຄວາມຕ້ອງການ, ການກວດສອບແລະສິ່ງອື່ນໆ, ສ້າງຫນ້າກ່ຽວກັບ e.g. Confluence - ມັນ​ເປັນ​ການ​ສະ​ດວກ​ສໍາ​ລັບ​ທຸກ​ຄົນ​.

ມັນງ່າຍກວ່າທີ່ຈະຟໍແມັດສິ່ງທີ່ທ່ານມີຢູ່ແລ້ວ ແລະໃຊ້ມັນເພື່ອເລີ່ມຕົ້ນ.

ໃຊ້ຄວາມປອດໄພແຊ້ມ

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

ແຊ້ມຄວາມປອດໄພແມ່ນຄົນພາຍໃນທີມພັດທະນາທີ່ມີຄວາມສົນໃຈໃນຄວາມປອດໄພຂອງຜະລິດຕະພັນຂອງເຈົ້າ.

ແຊ້ມຄວາມປອດໄພເປັນຈຸດເຂົ້າໄປໃນທີມງານພັດທະນາແລະຜູ້ປະກາດຂ່າວຄວາມປອດໄພ rolled ເປັນຫນຶ່ງ.

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

- ແລະເຈົ້າແມ່ນໃຜ? ຂ້ອຍເຫັນເຈົ້າເປັນເທື່ອທຳອິດ. ທຸກຢ່າງແມ່ນດີກັບຂ້ອຍ - ເພື່ອນອາວຸໂສຂອງຂ້ອຍໄດ້ໃຫ້ຂ້ອຍ "ສະຫມັກ" ໃນການທົບທວນຄືນລະຫັດ, ພວກເຮົາກ້າວຕໍ່ໄປ!

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

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

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

ຂັ້ນຕອນການທົດສອບ

Paradigm 20 ຫາ 80 ເວົ້າວ່າ 20% ຂອງຄວາມພະຍາຍາມສ້າງ 80% ຂອງຜົນໄດ້ຮັບ. 20% ນີ້ແມ່ນການປະຕິບັດການວິເຄາະຄໍາຮ້ອງສະຫມັກທີ່ສາມາດແລະຄວນຈະເປັນອັດຕະໂນມັດ. ຕົວຢ່າງຂອງກິດຈະກໍາດັ່ງກ່າວແມ່ນການວິເຄາະ static - SAST, ການວິເຄາະແບບເຄື່ອນໄຫວ - DAST и ການຄວບຄຸມແຫຼ່ງເປີດ. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ບອກ​ທ່ານ​ໃນ​ລະ​ອຽດ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ກິດ​ຈະ​ກໍາ​, ເຊັ່ນ​ດຽວ​ກັນ​ກັບ​ເຄື່ອງ​ມື​, ຄຸນ​ນະ​ສົມ​ບັດ​ທີ່​ພວກ​ເຮົາ​ມັກ​ຈະ​ພົບ​ເຫັນ​ໃນ​ເວ​ລາ​ທີ່​ແນະ​ນໍາ​ໃຫ້​ເຂົາ​ເຈົ້າ​ເຂົ້າ​ໄປ​ໃນ​ຂະ​ບວນ​ການ​, ແລະ​ວິ​ທີ​ການ​ເຮັດ​ໃຫ້​ມັນ​ຖືກ​ຕ້ອງ​.

ບັນຫາຕົ້ນຕໍຂອງເຄື່ອງມື

ຂ້າພະເຈົ້າຈະຍົກໃຫ້ເຫັນບັນຫາທີ່ກ່ຽວຂ້ອງສໍາລັບເຄື່ອງມືທັງຫມົດແລະຮຽກຮ້ອງໃຫ້ມີຄວາມສົນໃຈ. ຂ້າພະເຈົ້າຈະວິເຄາະໃຫ້ເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມເພື່ອບໍ່ໃຫ້ເຮັດຊ້ໍາອີກ.

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

ລະດັບສູງ False Negative ຫຼື False Positive. ຜະລິດຕະພັນທັງຫມົດແມ່ນແຕກຕ່າງກັນ, ທັງຫມົດນໍາໃຊ້ກອບທີ່ແຕກຕ່າງກັນແລະຮູບແບບການຂຽນລະຫັດຂອງຕົນເອງ. ໃນ codebases ແລະເຕັກໂນໂລຢີທີ່ແຕກຕ່າງກັນ, ເຄື່ອງມືອາດຈະສະແດງໃຫ້ເຫັນລະດັບທີ່ແຕກຕ່າງກັນຂອງ False Negative ແລະ False Positive. ສະນັ້ນເບິ່ງສິ່ງທີ່ແນ່ນອນຢູ່ໃນ ຂອງທ່ານ ບໍລິສັດແລະສໍາລັບ ຂອງເຈົ້າ ຄໍາຮ້ອງສະຫມັກຈະສະແດງໃຫ້ເຫັນຜົນໄດ້ຮັບທີ່ດີແລະເຊື່ອຖືໄດ້.

ບໍ່ມີການເຊື່ອມໂຍງກັບເຄື່ອງມືທີ່ມີຢູ່. ເບິ່ງເຄື່ອງມືໃນແງ່ຂອງການເຊື່ອມໂຍງກັບສິ່ງທີ່ທ່ານໃຊ້ແລ້ວ. ຕົວຢ່າງ, ຖ້າທ່ານມີ Jenkins ຫຼື TeamCity, ກວດເບິ່ງການລວມເອົາເຄື່ອງມືກັບຊອບແວນີ້, ແລະບໍ່ແມ່ນກັບ GitLab CI, ທີ່ທ່ານບໍ່ໄດ້ໃຊ້.

ການຂາດຫຼືຄວາມຊັບຊ້ອນຫຼາຍເກີນໄປຂອງການປັບແຕ່ງ. ຖ້າເຄື່ອງມືບໍ່ມີ API, ແລ້ວເປັນຫຍັງມັນຈຶ່ງຕ້ອງການ? ທຸກສິ່ງທຸກຢ່າງທີ່ສາມາດເຮັດໄດ້ໃນການໂຕ້ຕອບຄວນຈະມີຜ່ານ API. ໂດຍຫລັກການແລ້ວ, ເຄື່ອງມືຄວນຈະມີຄວາມສາມາດໃນການປັບແຕ່ງການກວດສອບ.

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

ລັກສະນະຂອງຂະບວນການ

ນອກເຫນືອໄປຈາກລັກສະນະຂອງເຄື່ອງມື, ຄໍານຶງເຖິງລັກສະນະຂອງຂະບວນການພັດທະນາ. ຕົວຢ່າງ, ການຂັດຂວາງການພັດທະນາແມ່ນຄວາມຜິດພາດທົ່ວໄປ. ຂໍໃຫ້ພິຈາລະນາລັກສະນະອື່ນໆທີ່ຄວນຈະຖືກພິຈາລະນາແລະສິ່ງທີ່ທີມງານຄວາມປອດໄພຄວນເອົາໃຈໃສ່.

ໃນຄໍາສັ່ງທີ່ຈະບໍ່ພາດການພັດທະນາແລະປ່ອຍເສັ້ນຕາຍ, ສ້າງ ກົດ​ລະ​ບຽບ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ ແລະແຕກຕ່າງກັນ ສະແດງໃຫ້ເຫັນ stoppers — ມາດ​ຖານ​ສໍາ​ລັບ​ການ​ຢຸດ​ເຊົາ​ຂະ​ບວນ​ການ​ການ​ກໍ່​ສ້າງ​ໃນ​ທີ່​ມີ​ຈຸດ​ອ່ອນ — ສໍາລັບສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ. ຕົວຢ່າງ, ພວກເຮົາເຂົ້າໃຈວ່າສາຂາໃນປະຈຸບັນໄປຫາຈຸດຢືນຂອງການພັດທະນາຫຼື UAT, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາບໍ່ຢຸດແລະເວົ້າວ່າ:

"ເຈົ້າມີຈຸດອ່ອນຢູ່ບ່ອນນີ້, ເຈົ້າຈະບໍ່ໄປໃສອີກ!"

ໃນຈຸດນີ້, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະບອກນັກພັດທະນາວ່າມີບັນຫາຄວາມປອດໄພທີ່ຕ້ອງການຄວາມສົນໃຈ.

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

- Guys, ທ່ານມີບັນຫາ, ກະລຸນາເອົາໃຈໃສ່ກັບເຂົາເຈົ້າ.

ໃນຂັ້ນຕອນຂອງ UAT ພວກເຮົາສະແດງການເຕືອນໄພກ່ຽວກັບຄວາມອ່ອນແອອີກເທື່ອຫນຶ່ງ, ແລະໃນຂັ້ນຕອນການປ່ອຍຕົວພວກເຮົາເວົ້າວ່າ:

- ຜູ້ຊາຍ, ພວກເຮົາໄດ້ເຕືອນເຈົ້າຫຼາຍຄັ້ງ, ເຈົ້າບໍ່ໄດ້ເຮັດຫຍັງ - ພວກເຮົາຈະບໍ່ປ່ອຍໃຫ້ເຈົ້າອອກໄປກັບເລື່ອງນີ້.

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

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

ບໍ່ແມ່ນບັນຫາຄຸນນະພາບຂອງຊອບແວທັງໝົດແມ່ນບັນຫາຄວາມປອດໄພ. ແຕ່ບັນຫາຄວາມປອດໄພທັງຫມົດແມ່ນກ່ຽວຂ້ອງກັບຄຸນນະພາບຂອງຊອບແວ. Sherif Mansour, Expedia.

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

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

ຈະເຮັດແນວໃດ? ພວກເຮົາພຽງແຕ່ປ່ຽນຂໍ້ບົກພ່ອງທີ່ຖືກຢືນຢັນທີ່ພວກເຮົາພົບເຫັນເຂົ້າໄປໃນຮູບແບບທີ່ສະດວກສໍາລັບການພັດທະນາ, ຕົວຢ່າງ, ພວກເຮົາເອົາພວກມັນໄວ້ໃນ backlog ໃນ Jira. ພວກເຮົາຈັດລໍາດັບຄວາມສໍາຄັນຂອງຂໍ້ບົກພ່ອງແລະລົບລ້າງພວກມັນຕາມລໍາດັບຄວາມສໍາຄັນ, ພ້ອມກັບຂໍ້ບົກພ່ອງດ້ານການເຮັດວຽກແລະຂໍ້ບົກພ່ອງຂອງການທົດສອບ.

ການວິເຄາະສະຖິດ - SAST

ນີ້ແມ່ນການວິເຄາະລະຫັດສໍາລັບຄວາມອ່ອນແອ., ແຕ່ມັນບໍ່ຄືກັນກັບ SonarQube. ພວກເຮົາບໍ່ພຽງແຕ່ກວດເບິ່ງຮູບແບບຫຼືຮູບແບບ. ວິທີການຈໍານວນຫນຶ່ງແມ່ນຖືກນໍາໃຊ້ໃນການວິເຄາະ: ອີງຕາມຕົ້ນໄມ້ທີ່ມີຄວາມສ່ຽງ, ອີງຕາມ DataFlow, ໂດຍການວິເຄາະໄຟລ໌ການຕັ້ງຄ່າ. ນີ້ແມ່ນທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບລະຫັດຕົວມັນເອງ.

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

Минусы - ນີ້ແມ່ນການຂາດການສະຫນັບສະຫນູນສໍາລັບພາສາທີ່ຈໍາເປັນ.

ການ​ເຊື່ອມ​ໂຍງ​ທີ່​ຈໍາ​ເປັນ​, ເຊິ່ງຄວນຈະຢູ່ໃນເຄື່ອງມື, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ:

• ເຄື່ອງມືປະສົມປະສານ: Jenkins, TeamCity ແລະ Gitlab CI.
• ສະພາບແວດລ້ອມການພັດທະນາ: Intellij IDEA, Visual Studio. ມັນສະດວກກວ່າສໍາລັບຜູ້ພັດທະນາທີ່ຈະບໍ່ນໍາທາງໃນການໂຕ້ຕອບທີ່ບໍ່ສາມາດເຂົ້າໃຈໄດ້ທີ່ຍັງຕ້ອງໄດ້ຮັບການຈົດຈໍາ, ແຕ່ເພື່ອເບິ່ງການເຊື່ອມໂຍງທີ່ຈໍາເປັນທັງຫມົດແລະຈຸດອ່ອນທີ່ລາວພົບເຫັນຢູ່ໃນບ່ອນເຮັດວຽກໃນສະພາບແວດລ້ອມການພັດທະນາຂອງຕົນເອງ.
• ການທົບທວນຄືນລະຫັດ: SonarQube ແລະການທົບທວນຄືນຄູ່ມື.
• ບົບຕິດຕາມລຸດຂໍ້ບົກພ່ອງ: Jira ແລະ Bugzilla.

ຮູບພາບສະແດງໃຫ້ເຫັນບາງສ່ວນຂອງຜູ້ຕາງຫນ້າທີ່ດີທີ່ສຸດຂອງການວິເຄາະ static.

ມັນບໍ່ແມ່ນເຄື່ອງມືທີ່ມີຄວາມສໍາຄັນ, ແຕ່ຂະບວນການ, ດັ່ງນັ້ນມີການແກ້ໄຂ Open Source ທີ່ຍັງດີສໍາລັບການທົດສອບຂະບວນການ.

SAST Open Source ຈະບໍ່ພົບຊ່ອງໂຫວ່ຈຳນວນຫຼວງຫຼາຍ ຫຼື DataFlows ທີ່ຊັບຊ້ອນ, ແຕ່ພວກມັນສາມາດ ແລະຄວນຈະຖືກນຳໃຊ້ໃນເວລາສ້າງຂະບວນການ. ພວກເຂົາຊ່ວຍໃຫ້ເຂົ້າໃຈວ່າຂະບວນການຈະຖືກສ້າງຂື້ນແນວໃດ, ຜູ້ທີ່ຈະຕອບສະຫນອງຂໍ້ບົກພ່ອງ, ຜູ້ທີ່ຈະລາຍງານ, ແລະຜູ້ທີ່ຈະລາຍງານ. ຖ້າທ່ານຕ້ອງການປະຕິບັດຂັ້ນຕອນເບື້ອງຕົ້ນຂອງການສ້າງຄວາມປອດໄພຂອງລະຫັດຂອງທ່ານ, ໃຫ້ໃຊ້ວິທີແກ້ໄຂ Open Source.

ນີ້ສາມາດປະສົມປະສານໄດ້ແນວໃດຖ້າທ່ານຢູ່ໃນຕອນຕົ້ນຂອງການເດີນທາງຂອງທ່ານແລະບໍ່ມີຫຍັງ: ບໍ່ມີ CI, ບໍ່ມີ Jenkins, ບໍ່ມີ TeamCity? ໃຫ້ພິຈາລະນາການເຊື່ອມໂຍງເຂົ້າໃນຂະບວນການ.

ການເຊື່ອມໂຍງລະດັບ CVS

ຖ້າທ່ານມີ Bitbucket ຫຼື GitLab, ທ່ານສາມາດປະສົມປະສານໃນລະດັບ ລະບົບລຸ້ນພ້ອມກັນ.

ໂດຍເຫດການ - ດຶງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​. ທ່ານສະແກນລະຫັດແລະສະຖານະພາບການກໍ່ສ້າງສະແດງໃຫ້ເຫັນວ່າການກວດສອບຄວາມປອດໄພຜ່ານຫຼືລົ້ມເຫລວ.

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

ການປະສົມປະສານກັບລະບົບການກວດສອບລະຫັດ

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

ການປະສົມປະສານກັບ SonarQube

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

ການປະສົມປະສານຢູ່ໃນລະດັບ CI

ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ຍັງຂ້ອນຂ້າງງ່າຍດາຍ:

• ທຽບເທົ່າກັບ autotests, ການທົດສອບຫນ່ວຍງານ.
• ແບ່ງຕາມຂັ້ນຕອນການພັດທະນາ: dev, ການທົດສອບ, prod. ກົດລະບຽບທີ່ແຕກຕ່າງກັນຫຼືເງື່ອນໄຂທີ່ລົ້ມເຫລວທີ່ແຕກຕ່າງກັນອາດຈະລວມເອົາ: ຢຸດການຊຸມນຸມ, ຢ່າຢຸດການຊຸມນຸມ.
• ການເປີດຕົວ synchronous/asynchronous. ພວກເຮົາລໍຖ້າການສິ້ນສຸດຂອງການທົດສອບຄວາມປອດໄພຫຼືບໍ່. ນັ້ນແມ່ນ, ພວກເຮົາພຽງແຕ່ເປີດຕົວພວກມັນແລະກ້າວຕໍ່ໄປ, ແລະຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ຮັບສະຖານະພາບວ່າທຸກສິ່ງທຸກຢ່າງຈະດີຫຼືບໍ່ດີ.

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

ຕົວຢ່າງ, ພວກເຮົາໄດ້ເອົາໂຄງການຂະຫນາດໃຫຍ່ແລະຕັດສິນໃຈວ່າຕອນນີ້ພວກເຮົາຈະສະແກນມັນດ້ວຍ SAST - OK. ພວກເຮົາໄດ້ຍູ້ໂຄງການນີ້ເຂົ້າໄປໃນ SAST, ມັນເຮັດໃຫ້ພວກເຮົາມີຊ່ອງໂຫວ່ 20 ແລະໂດຍການຕັດສິນໃຈທີ່ເຂັ້ມແຂງ, ພວກເຮົາຕັດສິນໃຈວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີ. 000 ຄວາມອ່ອນແອແມ່ນຫນີ້ສິນດ້ານວິຊາການຂອງພວກເຮົາ. ພວກເຮົາຈະເອົາຫນີ້ສິນໄວ້ໃນກ່ອງຫນຶ່ງ, ພວກເຮົາຈະຄ່ອຍໆລ້າງມັນອອກແລະເພີ່ມຂໍ້ບົກພ່ອງໃຫ້ກັບຕົວຕິດຕາມຄວາມບົກພ່ອງ. ຂໍໃຫ້ຈ້າງບໍລິສັດ, ເຮັດທຸກຢ່າງດ້ວຍຕົວເອງ, ຫຼືມີ Security Champions ຊ່ວຍພວກເຮົາ - ແລະຫນີ້ສິນດ້ານວິຊາການຈະຫຼຸດລົງ.

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

ຕົວຢ່າງຂອງປະຕູຄວາມປອດໄພແມ່ນການປຽບທຽບຂອງປະຕູທີ່ມີຄຸນນະພາບ, ໃນແງ່ຂອງການປະກົດຕົວແລະຈໍານວນຊ່ອງໂຫວ່ໃນລະຫັດ.

ພວກເຮົາປະສົມປະສານກັບ SonarQube - plugin ໄດ້ຖືກຕິດຕັ້ງ, ທຸກສິ່ງທຸກຢ່າງແມ່ນສະດວກແລະເຢັນຫຼາຍ.

ການ​ເຊື່ອມ​ໂຍງ​ກັບ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ພັດ​ທະ​ນາ​

ທາງເລືອກໃນການເຊື່ອມໂຍງ:

• ດໍາເນີນການສະແກນຈາກສະພາບແວດລ້ອມການພັດທະນາກ່ອນທີ່ຈະສັນຍາ.
• ເບິ່ງຜົນໄດ້ຮັບ.
• ການວິເຄາະຜົນໄດ້ຮັບ.
• synchronization ກັບເຄື່ອງແມ່ຂ່າຍ.

ນີ້ແມ່ນສິ່ງທີ່ເບິ່ງຄືວ່າຈະໄດ້ຮັບຜົນໄດ້ຮັບຈາກເຄື່ອງແມ່ຂ່າຍ.

ໃນສະພາບແວດລ້ອມການພັດທະນາຂອງພວກເຮົາ Intellect IDEA ລາຍການເພີ່ມເຕີມພຽງແຕ່ປະກົດວ່າແຈ້ງໃຫ້ທ່ານຮູ້ວ່າຈຸດອ່ອນດັ່ງກ່າວໄດ້ຖືກກວດພົບໃນລະຫວ່າງການສະແກນ. ທ່ານສາມາດແກ້ໄຂລະຫັດທັນທີ, ເບິ່ງຄໍາແນະນໍາແລະ Flow Graph. ນີ້ແມ່ນທັງຫມົດທີ່ຕັ້ງຢູ່ໃນບ່ອນເຮັດວຽກຂອງຜູ້ພັດທະນາ, ເຊິ່ງສະດວກຫຼາຍ - ບໍ່ຈໍາເປັນຕ້ອງຕິດຕາມການເຊື່ອມຕໍ່ອື່ນໆແລະເບິ່ງບາງສິ່ງບາງຢ່າງເພີ່ມເຕີມ.

Open Source

ນີ້ແມ່ນຫົວຂໍ້ທີ່ຂ້ອຍມັກທີ່ສຸດ. ທຸກຄົນໃຊ້ຫ້ອງສະຫມຸດ Open Source - ເປັນຫຍັງຂຽນໄມ້ຄ້ອນເທົ້າແລະລົດຖີບເມື່ອເຈົ້າສາມາດເອົາຫ້ອງສະຫມຸດທີ່ກຽມພ້ອມທີ່ທຸກສິ່ງທຸກຢ່າງຖືກປະຕິບັດແລ້ວ?

ແນ່ນອນ, ນີ້ແມ່ນຄວາມຈິງ, ແຕ່ຫ້ອງສະຫມຸດຍັງຖືກຂຽນໂດຍຄົນ, ພວກເຂົາຍັງລວມເອົາຄວາມສ່ຽງທີ່ແນ່ນອນແລະຍັງມີຈຸດອ່ອນທີ່ຖືກລາຍງານເປັນໄລຍະ, ຫຼືຢ່າງຕໍ່ເນື່ອງ. ດັ່ງນັ້ນ, ມີຂັ້ນຕອນຕໍ່ໄປໃນ Application Security - ນີ້ແມ່ນການວິເຄາະອົງປະກອບ Open Source.

ການວິເຄາະແຫຼ່ງເປີດ - OSA

ເຄື່ອງມືປະກອບມີສາມຂັ້ນຕອນໃຫຍ່.

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

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

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

ຄຸນນະສົມບັດ:

• ນະໂຍບາຍທີ່ແຕກຕ່າງກັນສໍາລັບໄລຍະການພັດທະນາທີ່ແຕກຕ່າງກັນ.
• ອົງປະກອບການຕິດຕາມໃນສະພາບແວດລ້ອມອຸດສາຫະກໍາ.
• ການ​ຄວບ​ຄຸມ​ຫ້ອງ​ສະ​ຫມຸດ​ພາຍ​ໃນ​ອົງ​ການ​ຈັດ​ຕັ້ງ​.
• ສະຫນັບສະຫນູນລະບົບການກໍ່ສ້າງຕ່າງໆແລະພາສາ.
• ການວິເຄາະຮູບພາບ Docker.

ຕົວຢ່າງຈໍານວນຫນ້ອຍຂອງຜູ້ນໍາອຸດສາຫະກໍາທີ່ມີສ່ວນຮ່ວມໃນການວິເຄາະ Open Source.

ອັນດຽວຟຣີແມ່ນອັນນີ້ Dependency-Check ຈາກ OWASP. ທ່ານສາມາດເປີດມັນຢູ່ໃນຂັ້ນຕອນທໍາອິດ, ເບິ່ງວິທີການເຮັດວຽກແລະສິ່ງທີ່ມັນສະຫນັບສະຫນູນ. ໂດຍພື້ນຖານແລ້ວ, ເຫຼົ່ານີ້ແມ່ນຜະລິດຕະພັນຟັງທັງຫມົດ, ຫຼືຢູ່ໃນສະຖານທີ່, ແຕ່ຢູ່ຫລັງພື້ນຖານຂອງພວກເຂົາພວກເຂົາຍັງຖືກສົ່ງໄປຫາອິນເຕີເນັດ. ພວກເຂົາເຈົ້າບໍ່ສົ່ງຫ້ອງສະຫມຸດຂອງທ່ານ, ແຕ່ hashes ຫຼືມູນຄ່າຂອງຕົນເອງ, ທີ່ເຂົາເຈົ້າຄິດໄລ່, ແລະ fingerprints ກັບເຄື່ອງແມ່ຂ່າຍຂອງເຂົາເຈົ້າເພື່ອໃຫ້ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບການປະກົດຕົວຂອງຊ່ອງໂຫວ່.

ການເຊື່ອມໂຍງຂະບວນການ

ການຄວບຄຸມ perimeter ຂອງຫ້ອງສະຫມຸດ, ເຊິ່ງຖືກດາວໂຫຼດຈາກແຫຼ່ງພາຍນອກ. ພວກເຮົາມີບ່ອນເກັບມ້ຽນພາຍນອກແລະພາຍໃນ. ຕົວຢ່າງ, Event Central ແລ່ນ Nexus, ແລະພວກເຮົາຕ້ອງການຮັບປະກັນວ່າບໍ່ມີຊ່ອງໂຫວ່ຢູ່ໃນບ່ອນເກັບມ້ຽນຂອງພວກເຮົາທີ່ມີສະຖານະ "ສໍາຄັນ" ຫຼື "ສູງ". ທ່ານສາມາດກຳນົດຄ່າຕົວແທນໄດ້ໂດຍໃຊ້ເຄື່ອງມື Nexus Firewall Lifecycle ເພື່ອໃຫ້ຊ່ອງໂຫວ່ດັ່ງກ່າວຖືກຕັດອອກ ແລະບໍ່ສິ້ນສຸດໃນບ່ອນເກັບຂໍ້ມູນພາຍໃນ.

ການເຊື່ອມໂຍງເຂົ້າໃນ CI. ໃນລະດັບດຽວກັນກັບ autotests, ການທົດສອບຫນ່ວຍງານແລະການແບ່ງສ່ວນເຂົ້າໄປໃນຂັ້ນຕອນການພັດທະນາ: dev, ການທົດສອບ, prod. ໃນແຕ່ລະຂັ້ນຕອນ, ທ່ານສາມາດດາວໂຫລດຫ້ອງສະຫມຸດໃດໆ, ໃຊ້ສິ່ງໃດກໍ່ຕາມ, ແຕ່ຖ້າມີບາງສິ່ງບາງຢ່າງທີ່ຍາກກັບສະຖານະ "ສໍາຄັນ", ບາງທີມັນສົມຄວນທີ່ຈະດຶງດູດຄວາມສົນໃຈຂອງນັກພັດທະນາໃນຂັ້ນຕອນຂອງການຜະລິດ.

ການປະສົມປະສານກັບສິ່ງປະດິດ: Nexus ແລະ JFrog.

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

ການປະສົມປະສານ CD. ນີ້ແມ່ນລັກສະນະທີ່ເຢັນທີ່ຂ້ອຍມັກແລະທີ່ຂ້ອຍໄດ້ເວົ້າມາແລ້ວ - ການຕິດຕາມການເກີດຂື້ນຂອງຊ່ອງໂຫວ່ໃຫມ່ໃນສະພາບແວດລ້ອມອຸດສາຫະກໍາ. ມັນເຮັດວຽກແບບນີ້.

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

• ໃນເວລາທີ່ການກໍ່ສ້າງ, ພວກເຮົາກວດເບິ່ງວ່າບໍ່ມີໃຜໄດ້ເລື່ອນສິ່ງທີ່ບໍ່ດີ, ວ່າອົງປະກອບທັງຫມົດແມ່ນປອດໄພແລະບໍ່ມີໃຜນໍາເອົາສິ່ງທີ່ເປັນອັນຕະລາຍໃນ flash drive.
• ພວກເຮົາມີພຽງແຕ່ອົງປະກອບທີ່ເຊື່ອຖືໄດ້ໃນ repository.
• ເມື່ອນຳໃຊ້, ພວກເຮົາກວດເບິ່ງຊຸດໃໝ່ອີກຄັ້ງ: war, jar, DL ຫຼື Docker image ເພື່ອຮັບປະກັນວ່າມັນປະຕິບັດຕາມນະໂຍບາຍ.
• ເມື່ອເຂົ້າໄປໃນອຸດສາຫະກໍາ, ພວກເຮົາຕິດຕາມສິ່ງທີ່ເກີດຂື້ນໃນສະພາບແວດລ້ອມອຸດສາຫະກໍາ: ຄວາມອ່ອນແອທີ່ສໍາຄັນຈະປາກົດຫຼືບໍ່ປາກົດ.

ການວິເຄາະແບບເຄື່ອນໄຫວ - DAST

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

ລະບົບດຽວກັນອະນຸຍາດໃຫ້ທ່ານກວດເບິ່ງຊ່ອງໂຫວ່ຂອງແມ່ແບບໃນ Open Source. ເນື່ອງຈາກ DAST ບໍ່ຮູ້ວ່າ Open Source ທີ່ພວກເຮົາກໍາລັງໃຊ້, ມັນພຽງແຕ່ຖິ້ມຮູບແບບ "ເປັນອັນຕະລາຍ" ແລະວິເຄາະການຕອບສະຫນອງຂອງເຄື່ອງແມ່ຂ່າຍ:

- ແລ້ວ, ມີບັນຫາ deserialization ຢູ່ທີ່ນີ້, ແຕ່ບໍ່ແມ່ນຢູ່ທີ່ນີ້.

ມີຄວາມສ່ຽງອັນໃຫຍ່ຫຼວງໃນເລື່ອງນີ້, ເພາະວ່າຖ້າທ່ານເຮັດການທົດສອບຄວາມປອດໄພນີ້ຢູ່ໃນເກົ້າອີ້ດຽວກັນທີ່ນັກທົດສອບເຮັດວຽກກັບ, ສິ່ງທີ່ບໍ່ພໍໃຈສາມາດເກີດຂື້ນໄດ້.

• ການໂຫຼດສູງໃນເຄືອຂ່າຍເຊີບເວີແອັບພລິເຄຊັນ.
• ບໍ່ມີການເຊື່ອມໂຍງ.
• ຄວາມສາມາດໃນການປ່ຽນການຕັ້ງຄ່າຂອງແອັບພລິເຄຊັນທີ່ວິເຄາະ.
• ບໍ່ມີການສະຫນັບສະຫນູນເຕັກໂນໂລຢີທີ່ຈໍາເປັນ.
• ຄວາມຫຍຸ້ງຍາກໃນການຕັ້ງຄ່າ.

ພວກ​ເຮົາ​ມີ​ສະ​ຖາ​ນະ​ການ​ໃນ​ທີ່​ສຸດ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເປີດ AppScan​: ພວກ​ເຮົາ​ໃຊ້​ເວ​ລາ​ດົນ​ນານ​ເພື່ອ​ໃຫ້​ໄດ້​ຮັບ​ການ​ເຂົ້າ​ເຖິງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​, ໄດ້ 3 ບັນ​ຊີ​ແລະ​ມີ​ຄວາມ​ສຸກ - ໃນ​ທີ່​ສຸດ​ພວກ​ເຮົາ​ຈະ​ກວດ​ສອບ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​! ພວກເຮົາໄດ້ເປີດຕົວການສະແກນ, ແລະສິ່ງທໍາອິດທີ່ AppScan ເຮັດແມ່ນເຂົ້າໄປໃນກະດານ admin, ເຈາະປຸ່ມທັງຫມົດ, ປ່ຽນເຄິ່ງຫນຶ່ງຂອງຂໍ້ມູນ, ແລະຫຼັງຈາກນັ້ນຂ້າເຄື່ອງແມ່ຂ່າຍທັງຫມົດດ້ວຍມັນ. ແບບຟອມຈົດໝາຍ- ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​. ການພັດທະນາດ້ວຍການທົດສອບກ່າວວ່າ:

- Guys, ເຈົ້າ kidding ຂ້ອຍ?! ພວກ​ເຮົາ​ໃຫ້​ບັນ​ຊີ​ໃຫ້​ທ່ານ​, ແລະ​ທ່ານ​ຕັ້ງ​ສະ​ຖານ​ທີ່​!

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

ມັນເປັນມູນຄ່າພິຈາລະນາວ່າທ່ານສາມາດນໍາໃຊ້ນີ້ເປັນ analogue ຂອງການທົດສອບການໂຫຼດ. ໃນຂັ້ນຕອນທໍາອິດ, ທ່ານສາມາດເປີດເຄື່ອງສະແກນແບບເຄື່ອນໄຫວທີ່ມີ 10-15 ກະທູ້ແລະເບິ່ງວ່າມີຫຍັງເກີດຂື້ນ, ແຕ່ໂດຍປົກກະຕິ, ຕາມການປະຕິບັດ, ບໍ່ມີຫຍັງດີ.

ຊັບພະຍາກອນຈໍານວນຫນ້ອຍທີ່ພວກເຮົາມັກຈະໃຊ້.

ຕົກເປັນມູນຄ່າ ເຫມາະສົມກັບ Burp ແມ່ນ "ມີດສະວິດ" ສໍາລັບຜູ້ຊ່ຽວຊານດ້ານຄວາມປອດໄພໃດໆ. ທຸກຄົນໃຊ້ມັນແລະມັນສະດວກຫຼາຍ. ສະບັບສາທິດໃໝ່ຂອງສະບັບວິສາຫະກິດໄດ້ຖືກປ່ອຍອອກມາແລ້ວ. ຖ້າກ່ອນຫນ້ານີ້ມັນເປັນພຽງແຕ່ປະໂຫຍດທີ່ຢືນຢູ່ຢ່າງດຽວກັບ plugins, ໃນປັດຈຸບັນນັກພັດທະນາສຸດທ້າຍກໍາລັງສ້າງເຄື່ອງແມ່ຂ່າຍຂະຫນາດໃຫຍ່ທີ່ມັນຈະເປັນໄປໄດ້ທີ່ຈະຈັດການຕົວແທນຈໍານວນຫນຶ່ງ. ນີ້ແມ່ນເຢັນ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານລອງມັນ.

ການເຊື່ອມໂຍງຂະບວນການ

ການປະສົມປະສານເກີດຂຶ້ນຂ້ອນຂ້າງດີແລະງ່າຍດາຍ: ເລີ່ມການສະແກນຫຼັງຈາກການຕິດຕັ້ງສໍາເລັດ ຄໍາຮ້ອງສະຫມັກສໍາລັບການຢືນແລະ ການສະແກນຫຼັງຈາກການທົດສອບການເຊື່ອມໂຍງສົບຜົນສໍາເລັດ.

ຖ້າການເຊື່ອມໂຍງບໍ່ເຮັດວຽກຫຼືມີຫນ້າ stubs ແລະ mock, ມັນບໍ່ມີຈຸດຫມາຍແລະບໍ່ມີປະໂຍດ - ບໍ່ວ່າພວກເຮົາສົ່ງຮູບແບບໃດກໍ່ຕາມ, ເຊີບເວີຈະຍັງຄົງຕອບສະຫນອງແບບດຽວກັນ.

• ໂດຍຫລັກການແລ້ວ, ການທົດສອບແຍກຕ່າງຫາກ.
• ກ່ອນທີ່ຈະທົດສອບ, ຂຽນລໍາດັບການເຂົ້າສູ່ລະບົບ.
• ການທົດສອບລະບົບການບໍລິຫານແມ່ນຄູ່ມືເທົ່ານັ້ນ.

ຂະບວນການ

ໂດຍທົ່ວໄປເລັກນ້ອຍກ່ຽວກັບຂະບວນການໂດຍທົ່ວໄປແລະກ່ຽວກັບການເຮັດວຽກຂອງເຄື່ອງມືແຕ່ລະຄົນໂດຍສະເພາະ. ຄໍາຮ້ອງສະຫມັກທັງຫມົດແມ່ນແຕກຕ່າງກັນ - ຫນຶ່ງເຮັດວຽກທີ່ດີກວ່າກັບການວິເຄາະແບບເຄື່ອນໄຫວ, ອື່ນທີ່ມີການວິເຄາະ static, ທີສາມກັບການວິເຄາະ OpenSource, pentests, ຫຼືບາງສິ່ງບາງຢ່າງອື່ນທັງຫມົດ, ຕົວຢ່າງ, ເຫດການທີ່ມີ. Waf.

ທຸກໆຂະບວນການຕ້ອງການການຄວບຄຸມ.

ເພື່ອເຂົ້າໃຈວິທີການເຮັດວຽກແລະບ່ອນທີ່ມັນສາມາດປັບປຸງໄດ້, ທ່ານຈໍາເປັນຕ້ອງເກັບກໍາ metrics ຈາກທຸກສິ່ງທຸກຢ່າງທີ່ທ່ານສາມາດໄດ້ຮັບໃນມືຂອງທ່ານ, ລວມທັງ metrics ການຜະລິດ, metrics ຈາກເຄື່ອງມື, ແລະຈາກຕົວຕິດຕາມຂໍ້ບົກພ່ອງ.

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

ນັບຕັ້ງແຕ່ນັກວິເຄາະແບບຄົງທີ່ແລະແບບເຄື່ອນໄຫວທັງຫມົດມີ APIs ຂອງຕົນເອງ, ວິທີການເປີດຕົວຂອງຕົນເອງ, ຫຼັກການ, ບາງຄົນມີຕົວກໍານົດເວລາ, ຄົນອື່ນບໍ່ມີ - ພວກເຮົາກໍາລັງຂຽນເຄື່ອງມື AppSec Orchestrator, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສ້າງຈຸດເຂົ້າດຽວໃນຂະບວນການທັງຫມົດຈາກຜະລິດຕະພັນແລະຈັດການມັນຈາກຈຸດດຽວ.

ຜູ້ຈັດການ, ຜູ້ພັດທະນາແລະວິສະວະກອນຄວາມປອດໄພມີຈຸດເຂົ້າຫນຶ່ງທີ່ພວກເຂົາສາມາດເຫັນສິ່ງທີ່ກໍາລັງແລ່ນ, ຕັ້ງຄ່າແລະດໍາເນີນການສະແກນ, ຮັບຜົນການສະແກນແລະສົ່ງຄວາມຕ້ອງການ. ພວກເຮົາກໍາລັງພະຍາຍາມຍ້າຍອອກໄປຈາກເອກະສານ, ເພື່ອແປທຸກສິ່ງທຸກຢ່າງເປັນມະນຸດ, ເຊິ່ງຖືກນໍາໃຊ້ໂດຍການພັດທະນາ - ຫນ້າທີ່ Confluence ກັບສະຖານະພາບແລະຕົວຊີ້ວັດ, ຂໍ້ບົກພ່ອງໃນ Jira ຫຼືໃນຕົວຕິດຕາມຂໍ້ບົກພ່ອງຕ່າງໆ, ຫຼືການເຊື່ອມໂຍງເຂົ້າໄປໃນຂະບວນການ synchronous / asynchronous ໃນ CI. /CD.

Key Takeaways

ເຄື່ອງມືບໍ່ແມ່ນສິ່ງຕົ້ນຕໍ. ທໍາອິດຄິດໂດຍຜ່ານຂະບວນການ - ຫຼັງຈາກນັ້ນປະຕິບັດເຄື່ອງມື. ເຄື່ອງມືແມ່ນດີແຕ່ລາຄາແພງ, ດັ່ງນັ້ນທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍຂະບວນການແລະສ້າງການສື່ສານແລະຄວາມເຂົ້າໃຈລະຫວ່າງການພັດທະນາແລະຄວາມປອດໄພ. ຈາກທັດສະນະຂອງຄວາມປອດໄພ, ບໍ່ຈໍາເປັນຕ້ອງ "ຢຸດ" ທຸກສິ່ງທຸກຢ່າງ. ຈາກທັດສະນະຂອງການພັດທະນາ, ຖ້າມີບາງສິ່ງບາງຢ່າງທີ່ສໍາຄັນຂະຫນາດໃຫຍ່, ມັນຈໍາເປັນຕ້ອງໄດ້ລົບລ້າງ, ແລະບໍ່ເຮັດໃຫ້ຕາບອດກັບບັນຫາ.

ຄຸນນະພາບຜະລິດຕະພັນ - ເປົ້າ​ຫມາຍ​ທົ່ວ​ໄປ​ ທັງ​ຄວາມ​ປອດ​ໄພ​ແລະ​ການ​ພັດ​ທະ​ນາ​. ພວກເຮົາເຮັດສິ່ງຫນຶ່ງ, ພວກເຮົາພະຍາຍາມຮັບປະກັນວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກຢ່າງຖືກຕ້ອງແລະບໍ່ມີຄວາມສ່ຽງຕໍ່ຊື່ສຽງຫຼືການສູນເສຍທາງດ້ານການເງິນ. ນີ້ແມ່ນເຫດຜົນທີ່ພວກເຮົາສົ່ງເສີມວິທີການ DevSecOps, SecDevOps ເພື່ອປັບປຸງການສື່ສານແລະປັບປຸງຄຸນນະພາບຂອງຜະລິດຕະພັນ.

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

ມີຄວາມເທົ່າທຽມກັນລະຫວ່າງຄວາມບົກຜ່ອງດ້ານຄວາມປອດໄພຂອງຂໍ້ມູນແລະຂໍ້ບົກພ່ອງດ້ານການເຮັດວຽກ.

ອັດຕະໂນມັດທຸກຢ່າງທີ່ຍ້າຍ. ສິ່ງໃດກໍ່ຕາມທີ່ບໍ່ເຄື່ອນທີ່, ຍ້າຍມັນແລະອັດຕະໂນມັດ. ຖ້າບາງສິ່ງບາງຢ່າງເຮັດດ້ວຍມື, ມັນບໍ່ແມ່ນສ່ວນທີ່ດີຂອງຂະບວນການ. ບາງທີມັນຄຸ້ມຄ່າທີ່ຈະທົບທວນມັນແລະອັດຕະໂນມັດເຊັ່ນກັນ.

ຖ້າຂະຫນາດຂອງທີມງານ IS ຂະຫນາດນ້ອຍ - ໃຊ້ຄວາມປອດໄພ Champions.

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

ຄວາມຕ້ອງການສໍາລັບເຄື່ອງມື.

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

ບົດລາຍງານຂອງ Yuri ໄດ້ຖືກເລືອກໃຫ້ເປັນຫນຶ່ງໃນທີ່ດີທີ່ສຸດໃນ DevOpsConf 2018. ເພື່ອໃຫ້ໄດ້ຮູ້ຈັກກັບແນວຄວາມຄິດທີ່ຫນ້າສົນໃຈຫຼາຍແລະກໍລະນີປະຕິບັດ, ມາ Skolkovo ໃນວັນທີ 27 ແລະ 28 ພຶດສະພາ. DevOpsConf ພາຍໃນ ງານບຸນ RIT++. ດີກວ່າ, ຖ້າທ່ານພ້ອມທີ່ຈະແບ່ງປັນປະສົບການຂອງທ່ານ, ຫຼັງຈາກນັ້ນ ສະຫມັກ ສໍາລັບບົດລາຍງານຈົນເຖິງວັນທີ 21 ເມສາ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com