AppSec дэх Autofix нь гараар оролцоогүйгээр хөгжүүлэлтийн ажлын урсгалд эмзэг байдлыг автоматаар илрүүлж, засах үйл явц юм. Орчин үеийн програм хангамжийн багуудын хувьд энэ нь дараагийн алхам мэт сонсогдож байна. Дууссан ажлууд өсөн нэмэгдэж, хувилбарын мөчлөгүүд багассаар байгаа бөгөөд цөөхөн байгууллага бүрийг чиглүүлэх чадвартай. SAST олох, хамаарлын асуудал, нууц алдагдлыг илрүүлэх, эсвэл IaC бүрэн гараар засах дараалалд буруу тохиргоо хийгдсэн.
Гэсэн хэдий ч нэг асуудал бий. Багууд хүсэж байна эмзэг байдлыг засах илүү хурдан боловч тэд регрессийг чимээгүйхэн нэвтрүүлдэг, хамаарлыг тасалдуулдаг эсвэл тогтворгүй байдлыг бий болгодог автоматжуулалтыг хүсэхгүй байна. CI/CDЭнэхүү хурцадмал байдал нь одоо програмын аюулгүй байдлын гол асуудлуудын нэг болж байна. OWASP илтээр авч үздэг CI/CD өөрийн гэсэн гол эрсдэлийн ангилалтай аюулгүй байдлын салбарын хувьд, харин NIST-ийн Аюулгүй Програм Хангамж Хөгжүүлэлтийн Хүрээ аюулгүй хөгжлийн туршлагыг нэгтгэх шаардлагатайг тодорхой болгож байна SDLC төгсгөлд нь бэхлэхийн оронд.
Тийм ч учраас автоматаар засах зүгээр нэг бүтээгдэхүүний онцлог биш. Энэ бол үйлдлийн загвар юм. Муу хийвэл чимээ шуугиан, эрсдэл, эвдэрсэн бүтцийг бий болгодог. Сайн хийвэл илрүүлэлт болон засварлалтын хоорондох зайг арилгаж, засах хугацааг багасгаж, аюулгүй байдлыг DevOps-ийн хурдад нийцүүлэхэд тусалдаг. Энэхүү гарын авлагад бид автоматаар засах гэдэг нь юу гэсэн үг болохыг авч үзэх болно. АппСек, хаана бүтэлгүйтэх, аюулгүй автоматжуулсан засвар үйлчилгээ ямар байх ёстой, мөн хөгжүүлэгчид үнэхээр итгэх байдлаар хэрхэн хэрэгжүүлэх талаар.
AppSec дээр Autofix гэж юу вэ?
Үндсэн түвшинд автоматаар засах гэдэг нь програм хангамж нь аюулгүй байдлын асуудлыг тодорхойлохоос илүү ихийг хийдэг гэсэн үг юм. Энэ нь залруулах арга хэмжээг санал болгож, үүсгэж эсвэл хэрэгжүүлдэг. Өөрөөр хэлбэл, хэрэгсэл нь "энд асуудал байна"-аас "энд засах арга байна" руу шилждэг.
Энэ нь энгийн сонсогдож байгаа ч практик дээр энэ нь хэд хэдэн маш өөр ажлын урсгалыг хамардаг.
In SAST, autofix гэдэг нь ихэвчлэн SQL injection, сайт хоорондын скрипт, аюултай цувралгүйжүүлэх хэв маяг, сул оролтын баталгаажуулалт, эсвэл аюулгүй бус баталгаажуулалтын логик зэрэг эмзэг байдлын кодын түвшний өөрчлөлтийг бий болгохыг хэлнэ. SCA, энэ нь ихэвчлэн хамаарлын шинэчлэлтийг санал болгох эсвэл хэрэгжүүлэх, илүү аюулгүй хувилбаруудыг бэхлэх эсвэл үүсгэх гэсэн үг юм pull requests багцуудыг засварласан хувилбарууд руу шилжүүлдэг. Нууцын аюулгүй байдал, автоматаар засах гэдэг нь зөвхөн итгэмжлэлүүдийг тэмдэглэх биш, харин хүчингүй болгох, эргүүлэх гэсэн үг юм. IaC, энэ нь аюултай Terraform, Kubernetes эсвэл үүлэн тохиргооны загваруудыг илүү аюулгүй анхдагч тохиргоонд дахин бичих гэсэн үг юм.
Чухал ялгаа нь энэ юм: автомат засвар нь зөвлөмжтэй адил зүйл биш юм. Олон аюулгүй байдлын хэрэгслүүд ерөнхий засвар хийхийг санал болгож чадна. Хөгжүүлэгчдэд бэлэн өөрчлөлтийг бий болгож чадах хүмүүс цөөхөн байдаг. Цөөхөн хүн уг засварыг бодит хүргэлтийн ажлын урсгалаар ажиллуулж, баталгаажуулж, хөгжүүлэгчид эх үүсвэрийн хяналтын хянаж болох өөрчлөлт болгон танилцуулж чаддаг хэвээр байна.
Энэ ялгаа нь чухал учир нь орчин үеийн инженерийн багууд PDF болон тасалбар дээр ажилладаггүй. Тэд дараах байдлаар ажилладаг. pull requests, бодлого, шалгалт болон pipelines.
Уламжлалт нөхөн сэргээлт яагаад өргөждөггүй вэ
Автомат засварын хэрэг нь зовлонтой бодит байдлаас эхэлдэг: уламжлалт нөхөн сэргээх үйл явц нь орчин үеийн програм хангамжийн хүргэлтэд хүрдэггүй.
Ихэнх байгууллагууд аль хэдийн хангалттай сканнертай болсон. Тэдэнд хангалттай нягтрал байдаггүй. Статик шинжилгээ, хамаарлын сканнер, нууц илрүүлэлт, дэд бүтцийн шалгалт нь үр дүнг тасралтгүй гаргадаг. Үүний зэрэгцээ инженерийн багууд функцуудыг тээвэрлэх, хүргэх хугацааг бага байлгах, үйлдвэрлэлийг тогтворгүй болгохоос зайлсхийх дарамтанд байдаг.
Үр дүн нь нээлт ба үйлдлийн хоорондох зай юм.
Нэгдүгээрт, энгийн сэрэмжлүүлгийн хэмжээ байдаг. AppSec програм боловсорч гүйцэх тусам илүү их үр дүн гаргадаг. Энэ нь үргэлж аюулгүй байдлыг сайжруулдаггүй. Олон орчинд энэ нь зүгээр л хоцрогдол үүсгэдэг. Xygeni-ийн бүтээгдэхүүний материалууд үүнийг чимээ шуугиан, эрэмбэлэх асуудал гэж үздэг бөгөөд энэ хүрээ нь салбарын өргөн хүрээний бодит байдалтай нийцдэг: зөвхөн илрүүлэлт биш, эрэмбэлэх нь олон програмын бэрхшээлтэй тулгардаг газар юм.
Хоёрдугаарт, гараар засах нь төлөвлөлтийн хувьд удаан байдаг. Хөгжүүлэгч нь асуудлыг уншиж, сканнерын гаралтыг тайлбарлаж, шаардлагатай бол асуудлыг дахин бүтээж, засварлах арга боловсруулж, хэрэгжүүлж, тест хийж, нээх ёстой. pull request, мөн хянагдахыг хүлээнэ үү. Энэ нь нэг чухал асуудлын хувьд хүлээн зөвшөөрөгдөхүйц байж болох юм. Дунд зэргийн ноцтой олдворууд, давтагдсан хамаарлын шинэчлэлтүүд эсвэл олон репозитор дахь нууц алдагдлуудын хувьд энэ нь хүлээн зөвшөөрөгдөхгүй.
Гуравдугаарт, аюулгүй байдал болон инженерчлэл нь ихэвчлэн өөр өөр үр дүнд хүрэхийн тулд оновчтой болгодог. Аюулгүй байдал нь эрсдэлийг бууруулахыг хүсдэг. Инженерчлэл нь өөрчлөлтийг аюулгүй, урьдчилан таамаглах боломжтой байдлаар оруулахыг хүсдэг. Олдворын урсгал бага байх үед энэ ялгааг зохицуулах боломжтой. Багууд асуудлуудаар дүүрч, баталгаажсан олдворуудыг аюулгүй, бага үрэлттэй засвар болгон хувиргах механизм байхгүй үед энэ нь хор хөнөөлтэй болдог.
Энэ нь автоматжуулалт зайлшгүй шаардлагатай мэт санагдаж эхэлдэг газар юм. Гэсэн хэдий ч дангаараа зайлшгүй шаардлага нь автоматжуулалтыг аюулгүй болгодоггүй.
Naive Autofix-ийн асуудал
Бүх автомат засвар нь сайн автомат засвар биш. Үнэндээ хөгжүүлэгчдийн аюулгүй байдлын автоматжуулалтад гаргадаг олон эсэргүүцэл нь автоматжуулалтын өөрийнх нь эсрэг биш юм. Эдгээр нь муу автоматжуулалтын эсрэг эсэргүүцэл юм.
Автомат засварын хөдөлгүүр нь ихэвчлэн дөрвөн асуудлын нэгтэй байдаг.
Эхнийх нь бүх асуудлыг адилхан засах боломжтой гэж үздэг. Сканнер нь эмзэг хамаарлыг олж хараад дараагийн нөхөөстэй хувилбарыг санал болгодог. Кодын хөдөлгүүр нь аюултай хэв маягийг олж хараад бэлэн орлуулалтыг сольдог. Энэ нь зарим энгийн тохиолдолд ажиллаж магадгүй юм. Энэ нь кодын суурь, архитектур, ажиллах хугацаа, хамаарлын график зэрэг нь бүгд чухал байдаг бодит системд хурдан бүтэлгүйтдэг.
Хоёрдугаарт, энэ нь гүйцэтгэлийн контекстийг үл тоомсорлодог. Тусдаа зөв харагдаж байгаа засвар нь бодит кодын замд хэрэглэгдэх үед хамааралгүй, хангалтгүй эсвэл эрсдэлтэй байж болно. Энэ нь ашиглалтын дохионууд маш чухал байдаг нэг шалтгаан юм. FIRST-ийн EPSS нь өмнө нь байдагcisучир нь ноцтой байдал нь дангаараа эмзэг байдлыг ойрын хугацаанд ашиглах магадлалтай эсэхийг харуулсан найдвартай үзүүлэлт биш юм. EPSS нь CVE-ийн ашиглалтын үйл ажиллагааны өдөр тутмын магадлалын тооцооллыг өгдөг бөгөөд энэ нь багуудад хязгаарлагдмал нөхөн сэргээх чадавхийг халдлагад өртөх магадлал өндөртэй зүйлд төвлөрүүлэхэд тусалдаг.
Гуравдугаарт, гэнэн автомат засвар нь өөрчлөлтийн эрсдэлийг үл тоомсорлодог. Энэ нь ялангуяа аюултай SCAХамаарлын шинэчлэлт нь CVE-г арилгахаас гадна API-ийн нийцгүй байдал, устгагдсан аргууд, нэр өөрчлөгдсөн классууд, өөрчлөгдсөн гэрээнүүд эсвэл ажиллах үеийн зан төлөвийн нарийн өөрчлөлтүүдийг оруулсаар байж болно.
Дөрөв дэх нь хэт автоматжуулалт юм. Хэрэгсэл нь бага үнэ цэнэтэй үерийг нээхэд pull requests, тэдгээрийн олонх нь туршилтанд унадаг эсвэл нэгтгэх үрэлт үүсгэдэг тул хөгжүүлэгчид үүнийг үл тоомсорлож сурдаг. Энэ бол нөхөн сэргээх хурдатгал биш. Энэ бол нөхөн сэргээх спам юм.
Тэгэхээр зөв асуулт бол багууд нөхөн сэргээлтийг автоматжуулах ёстой эсэх биш, харин үйл ажиллагааны хүндрэлийг нэмэгдүүлэхгүйгээр эрсдэлийг бууруулдаг ямар төрлийн автоматжуулалт вэ гэдэг нь зөв асуулт юм.
Хурц өөрчлөлтүүд бол жинхэнэ итгэлцлийн асуудал юм
Хөгжүүлэгчид автоматаар засварлахад итгэдэггүй гэж хэлэхдээ ихэвчлэн нэг маш тодорхой зүйлийг хэлж байгаа нь: тэд ямар нэгэн зүйлийг эвддэггүй гэдэгт итгэдэггүй явдал юм.
Энэхүү итгэлцлийн асуудал нь хамаарлыг арилгахад хамгийн тод илэрдэг.
Эмзэг багц нь засварласан хувилбартай байж болох ч энэ нь шинэчлэлт аюулгүй гэсэн үг биш юм. Зассан хувилбар нь таны аппликейшны ашигладаг аргыг устгаж магадгүй. Энэ нь API-г дахин нэрлэж магадгүй. Энэ нь төрлийн гэрээг чангалж магадгүй. Энэ нь нэгжийн туршилтыг давсан боловч үйлдвэрлэлийн регресс үүсгэдэг байдлаар зан төлөвийг өөрчилж магадгүй юм. Олон багуудад нөхөн сэргээх бодит өртөг нь засварыг хэрэглэхгүй байх явдал юм. Энэ нь тэсрэлтийн радиусыг судалж байна.
Java хэл дээрх энгийн жишээг авч үзье. Кодын сан нь 1.x хувилбарт нийтлэг арга байдаг боловч 2.x хувилбарт устгагдсан сангаас хамаарна.
Шинэчлэгдсэний дараа, foo() цаашид байхгүй болсон. Эмзэг байдал алга болсон байж болох ч бүтээн байгуулалт эвдэрсэн байна.
Тийм учраас "зүгээр л засварласан хувилбар руу шинэчлэх" нь инженерчлэлийн стратеги биш, харин мөрийтэй тоглоом юм.
OWASP-ын CI/CD орчин үеийн хүргэлт учраас энд удирдамж хамааралтай байна pipelines нь хурдатгалын механизм ба довтолгооны гадаргуу хоёулаа юм. Тогтворгүй эсвэл хяналтгүй өөрчлөлтийг бий болгодог аюулгүй байдлын хяналтууд pipeline зан үйл нь нэг асуудлыг өөр асуудлыг бий болгосноор шийддэг. CI/CD Хамгаалалтын системд зөвхөн хурдан өөрчлөлт оруулахаас гадна урсгалын хяналт, баталгаажуулалт, бодлогын хэрэгжилт шаардлагатай.
Аюулгүй автомат засвар нь энэ бодит байдлыг хүндэтгэх ёстой. Энэ нь зөвхөн эмзэг байдлыг засах боломжтой эсэхийг төдийгүй, хамгаалах ёстой програм хангамжийн амьдралын мөчлөгийг эвдэхгүйгээр уг засварыг нэвтрүүлж болох эсэхийг ойлгох ёстой.
Аюулгүй авто засвар ямар харагдах ёстой вэ
Аюулгүй автомат засвар гэдэг нь "автоматаар өөрчлөлт үүсгэх" биш юм. Аюулгүй автомат засвар гэдэг нь хяналттай автоматжуулсан нөхөн сэргээлт.
Энэ нь таван зүйл гэсэн үг.
Нэгдүгээрт, засварууд нь контекстэд тохирсон байх ёстой. Эргэн тойрны код, хүрээний конвенц, өгөгдлийн урсгал эсвэл хамаарлын зан төлөвийг үл тоомсорлодог аюулгүй санал нь хангалтгүй. Засвар нь зөвхөн эмзэг байдлын ангилалд төдийгүй програмд тохирох ёстой.
Хоёрдугаарт, засварууд нь эрсдэлийг мэддэг байх ёстой. Энэ бол засварлах эрсдэлийн шинжилгээ чухал ач холбогдолтой газар юм. Сайн автомат засварлах систем нь өөрчлөлт санал болгохоосоо өмнө инженерийн үндсэн асуултанд хариулах чадвартай байх ёстой: энэ засварлалт ямар магадлалтай вэ? огцом өөрчлөлтүүд?
Гуравдугаарт, засваруудыг нэн тэргүүнд тавих ёстой. Хамгийн сайн автомат засварлах програмууд бүгдийг нэг дор засахыг оролддоггүй. Тэд засварыг ашиглах боломж, хүртээмж, үйл ажиллагааны үр нөлөөтэй уялдуулдаг. Энэ нь боловсорсон AppSec програмууд хэрхэн илүү өргөн хүрээнд хөгжиж байгаатай нийцэж байна. CISА-ийн мэдэгдэж буй ашиглагдаж буй эмзэг байдлын каталог өмнө нь байсанcisбайгууллагуудад мөлжлөгийн нотолгоог нөхөн сэргээлтийн ажилд оруулахад нь туслах нь зүйтэйcisионууд, зөвхөн хүндийн зэргийг оноолох биш.
Дөрөвдүгээрт, autofix нь бодит хүргэлтийн ажлын урсгал дотор ажиллах ёстой. Хэрэв засварлах хөдөлгүүр ажиллахгүй бол pull requests, шалгалт, бодлого, туршилт гэх мэт нь орчин үеийн багууд програм хангамжийг хэрхэн хүргэдэгтэй нийцэхгүй байна.
Тавдугаарт, хөгжүүлэгчид хяналтаа хадгалах ёстой. Хөгжүүлэгчийн зөвшөөрсөн өөрчлөлтүүд нь автомат засварын сул тал биш юм. Эдгээр нь үйлдвэрлэлийн инженерчлэлийн орчинд автоматжуулалтыг найдвартай болгодог механизм юм.
Өөрөөр хэлбэл, аюулгүй нөхөн сэргээлт нь зөвхөн автоматжуулалт биш, харин хяналтыг шаарддаг.
Гэнэн Автомат засвар ба Аюулгүй Автомат засвар
Ажил үүсгэдэг автоматжуулалт болон түүнийг арилгадаг автоматжуулалтын хоорондох практик ялгааг доор харуулав.
| асуудал | Гэнэн автомат засвар | Аюулгүй автомат засвар |
|---|---|---|
| Засах стратеги | Эмзэг байдал илэрмэгц ерөнхий засвар эсвэл шинэчлэлтийг хэрэгжүүлнэ | Код, хамаарлын зан төлөв болон ажлын урсгалын баталгаажуулалт дээр үндэслэн контекстэд мэдрэмтгий засваруудыг үүсгэдэг |
| Хамаарлын шинэчлэлтүүд | Өөрчлөлтийн нөлөөллийн шинжилгээ хийлгүйгээр дараагийн нөхөөстэй хувилбарыг санал болгож байна | Засварлах санал гаргахаасаа өмнө шинэчлэлтийн замыг үнэлж, эвдрэл гарсан өөрчлөлтүүдийг шалгана |
| Тэргүүлэх чиглэл | Зөвхөн ноцтой байдалд нөлөөлдөг | Ноцтой байдлыг ашиглалтын боломж, хүртээмжтэй байдал болон үйл ажиллагааны нөлөөлөлтэй хослуулсан |
| Pipeline аюулгүй байдал | Бүтээлт эсвэл туршилтанд амжилтгүй болсон PR-уудыг нээж магадгүй | Засваруудыг баталгаажуулдаг CI/CD шалгалт болон хяналтын хаалга |
| Хөгжүүлэгчийн үүрэг | Хөгжүүлэгчид автоматжуулалтын алдааг цэвэрлэж байна | Хөгжүүлэгчид аюулгүй, нэгтгэхэд бэлэн засвар үйлчилгээний саналуудыг хянаж байна |
| Үр дүн | Илүү их шуугиан, илүү их регресс, бага итгэлцэл | Илүү хурдан нөхөн сэргээлт, цөөн регресс, илүү өндөр хэрэглээ |
Хэрэв та энэ хүснэгтээс нэг зүйлийг авахыг хүсвэл энэ нь дараах байдалтай байна. Автомат засварын чанарыг түүний контекст болон удирдлагын чанараар тодорхойлдог.
Орчин үеийн DevSecOps дээр Autofix хэрхэн ажилладаг вэ Pipeline
Насанд хүрсэн орчинд, автомат засвар нь ганц үйлдэл биш. Энэ нь бүтэцлэгдсэн нөхөн сэргээлтийн ажлын урсгал юм. CI/CD.
Гарын авлагын, салгагдсан засваруудын оронд орчин үеийн pipelines нь тасралтгүй урсгалыг дагадаг:
Орчин үеийн DevSecOps дээр Autofix хэрхэн ажилладаг вэ Pipeline
Насанд хүрсэн орчинд, автомат засвар нь ганц үйлдэл биш. Энэ нь бүтэцлэгдсэн нөхөн сэргээлтийн ажлын урсгал юм. CI/CD.
Гарын авлагын, салгагдсан засваруудын оронд орчин үеийн pipelines нь тасралтгүй урсгалыг дагадаг:
Алхам алхмаар автоматаар засах ажлын урсгал
- Илрүүлэх
Агуулахууд, pull requests, савнууд, эсвэл IaC эд өлгийн зүйлсийг ашиглан сканнердсан болно SAST, SCA, Нууц, эсвэл дэд бүтцийн шалгалт. - Тэргүүлэх чиглэл
Бүх эмзэг байдлыг адилхан авч үздэггүй. Автомат засварын системүүд дараах зүйлсийг ашиглахыг эрэмбэлдэг:- Хүрэх чадварын шинжилгээ
- EPSS гэх мэт ашиглалтын дохионууд
- Мэдэгдэж буй ашиглагдаж буй эмзэг байдал (KEV)
- Байршуулалтын нөхцөл байдал
- Үүсгэн байгуулалтыг засах
Систем нь асуудлын төрлөөс хамааран дараах залруулах арга хэмжээг гаргадаг:- Кодын засварууд SAST эмзэг байдал
- Хамаарлын шинэчлэлтүүд SCA
- Нууцаар хүчингүй болгох болон эргүүлэх
- IaC тохиргооны залруулга
- Pull Request Бүтээл
Засваруудыг хөгжүүлэгчийн уугуул ажлын урсгалд багцалдаг бөгөөд ихэвчлэн pull requests нь:- Кодын ялгаа
- Хам сэдэв ба үндэслэл
- Санал болгож буй өөрчлөлтүүд
- Баталгаажуулалт CI/CD
Нэгтгэхээс өмнө засваруудыг дараах байдлаар автоматаар баталгаажуулдаг:- Нэгж ба нэгтгэх туршилт
- Бүтцийн шалгалт
- Аюулгүй байдлын бодлого
- Хөгжүүлэгчийн зөвшөөрөл болон нэгтгэл
Хөгжүүлэгчид үйлдвэрлэлд нэгтгэхээсээ өмнө өөрчлөлтүүдийг хянаж, баталж эсвэл татгалздаг
Үүний үр дүнд autofix нь хөгжүүлэлтийн амьдралын мөчлөгийг тойрч гарахгүй, харин түүний дотор ажилладаг.
Энэ нь GitHub, GitLab, Azure DevOps зэрэг платформуудтай жигд нэгтгэгддэг бөгөөд үүнийг баталгаажуулдаг Эмзэг байдлыг арилгах нь тусдаа үйл явц биш харин хүргэлтийн ажлын урсгалын нэг хэсэг болдог.
Эмзэг байдлын янз бүрийн ангиллын автомат засвар
Автомат засварын харилцан ярианы хамгийн түгээмэл алдаануудын нэг бол бүх засваруудыг адилхан ажиллаж байгаа мэтээр авч үзэх явдал юм. Гэхдээ тэд тийм биш.
Автомат засвар SAST
Кодын түвшний автомат засвар нь олон хүн энэ ойлголттой анх тулгардаг газар юм. Сканнер нь SQL тарилга, тусгасан XSS шингээгч эсвэл аюулгүй бус баталгаажуулалтын загварыг олж, аюулгүй орлуулалтыг санал болгодог. Энэ нь ихэвчлэн автомат засварын хамгийн ойлгомжтой хэлбэр юм, учир нь засвар нь эх кодонд харагдаж байгаа бөгөөд бусад өөрчлөлтүүдийн нэгэн адил хянаж болно.
Xygeni-ийн бүтээгдэхүүний материалууд нь AI AutoFix-ийг энэ орон зайд хөгжүүлэгчдэд бэлэн засваруудыг үүсгэдэг контекстэд мэдрэмтгий засварлалт болгон байрлуулдаг. pull requests XSS болон SQL тарилга зэрэг асуудлуудад зориулагдсан. Үндсэн санаа нь бүтээгдэхүүний нэхэмжлэлээс гадна ч чухал юм: сайн SAST autofix нь зөвхөн дүрмийг мэддэг байхаас гадна кодыг мэддэг байх ёстой.
Автомат засвар SCA
Хамаарлын автомат засвар нь үйл ажиллагааны хувьд илүү чухал гэж үзэж болно, учир нь эмзэг багцууд байнга гарч ирдэг бөгөөд гараар хамаарлын засвар үйлчилгээ өргөждөггүй. Гэхдээ энэ нь итгэлийг олоход хамгийн хэцүү газар юм, учир нь хамаарлын шинэчлэлтүүд яг хаана байдаг вэ? огцом өөрчлөлтүүд хамгийн их өвдөлттэй болдог.
Найдвартай SCA Тиймээс автоматаар засах чадвар нь зөвхөн засварласан хувилбарыг олохоос илүү ихийг хийх ёстой. Энэ нь шинэчлэлтийн аюулгүй байдал, тэсрэлтийн радиус болон нийцтэй байдлыг үнэлэх ёстой.
Нууцын автомат засвар
Нууцыг сэргээх нь кодыг дахин бичихээс илүүтэйгээр хязгаарлахтай холбоотой юм. Хэрэв амьд нууц илэрвэл хамгийн тохиромжтой хариу үйлдэл нь хэн нэгнээс дараа долоо хоногт эргүүлэхийг хүсэх торгууль биш юм. Хамгийн тохиромжтой хариу үйлдэл бол шууд цуцлах, солих, тодорхой хянах явдал юм. Тийм ч учраас нууцын аюулгүй байдлын автомат засвар нь кодын автомат засвараас ихэвчлэн өөр харагддаг. Үүний утга нь хурд болон тодорхой байдал юм.
Автомат засвар IaC
Дэд бүтцийн буруу тохиргоо нь ихэвчлэн давтагддаг. Энэ нь тэдгээрийг автоматжуулалтын хүчтэй нэр дэвшигч болгодог. Хэрэв багууд чадвал standardTerraform, Kubernetes, ARM эсвэл CloudFormation-д зориулсан аюулгүй загваруудыг тохируулж, дараа нь autofix нь эдгээр загваруудыг хамаагүй эрт хэрэгжүүлж чадна. pipelineNIST-ийн SSDF нь аюулгүй байдлын практикийг тус бүрт нэгтгэхэд анхаарлаа хандуулдаг SDLC Хэрэгжилт нь энд шууд тохирч байна: аюулгүй байдал нь ажлын урсгалд суулгагдсан үед хамгийн хүчтэй байдаг бөгөөд дараагийн үе шатуудад хойшлуулагддаггүй.
Автомат засвар ашиглан барилгуудыг хэрхэн эвдэхээс зайлсхийх вэ
Энэ бол сэдвийн ард байгаа гол амлалт бөгөөд үүнийг шууд авч үзэх хэрэгтэй.
Автомат засвараар бүтцийг эвдэхээс зайлсхийхийн тулд багууд бусад үйлдвэрлэлийн өөрчлөлтийг баталгаажуулдагтай адил засварыг баталгаажуулах шаардлагатай. Энэ нь:
- Өөрчлөлтийг хэрэгжүүлэхийн өмнө хамаарал болон кодын нөлөөллийг шинжлэх
- засварыг баталгаажуулна уу CI/CD туршилт болон бодлоготой
- Тэсэлгээний радиус өндөр үед автоматжуулсан дуранг хязгаарлах
- материалын өөрчлөлтийн хувьд хөгжүүлэгчийн хяналт шаардлагатай
- Өндөр нөлөө бүхий шинэчлэлтүүдэд үе шаттай танилцуулга ашиглах
Тийм ч учраас нөхөн сэргээлтийн эрсдэлийн шинжилгээ маш үнэ цэнэтэй юм. Энэ нь "засах арга байна уу?" гэсэн асуултыг "энэ хамгийн аюулгүй, хэрэгжих боломжтой засвар мөн үү?" гэж өөрчилдөг. Энэ бол хамаагүй илүү инженерийн асуулт юм.
Мөн олон автоматжуулалтын програмууд энэ хэсэгт бүтэлгүйтдэг. Тэд дамжуулах хурдыг оновчтой болгож, өөрчлөлтийн аюулгүй байдлыг үл тоомсорлодог. Хөгжүүлэгчид үүнийг тэр даруй анзаардаг.
Үүний эсрэгээр, найдвартай автомат засварлах систем нь хүчтэй инженерчлэлийн багууд функц хөгжүүлэхэд аль хэдийн хэрэгжүүлдэг өөрчлөлтийн удирдлагын сахилга батыг хүндэтгэдэг: хянах, турших, баталгаажуулах, нэгтгэх.
Автомат засварыг хэрэгжүүлэх шилдэг туршлагууд
Хэрэв та автомат засварлах програмыг бүтээж эсвэл боловсронгуй болгож байгаа бол зорилго нь шинэлэг зүйл биш, харин нэвтрүүлэх явдал байх ёстой. Багууд цэвэрлэгээний ажил хийхгүйгээр цагийг тогтмол хэмнэдэг тохиолдолд автомат засварлахыг ашиглах болно.
Бодлогоос эхэл. Аль асуудлын ангиллыг эхлээд автоматжуулах нь аюулгүй болохыг шийд. SAST Сайн ойлгогдсон дахин бичсэн загварууд, тодорхойлсон хувилбарын хүрээнд хамаарлын шинэчлэлтүүд эсвэл нууц цуцлах ажлын урсгалууд нь ихэвчлэн эрт үеийн сайн нэр дэвшигчид болдог.
Дараа нь хүрээг нарийсга. Бүх зүйлийг нэг хувилбараар автоматжуулах гэж бүү оролд. Эхлээд нийтлэг бөгөөд өндөр итгэл үнэмшилтэй асуудлуудад анхаарлаа төвлөрүүл. Энэ нь өргөн хүрээтэй боловч чимээ шуугиантай засвар хийхээс илүү итгэлцлийг бий болгох илүү сайн стратеги юм.
Засварыг одоо байгаа хөгжүүлэгчийн ажлын урсгалд нэгтгэ. Хэрэв танай инженерийн багууд амьдардаг бол pull requests болон салбарын хамгаалалт, автоматаар засах нь бас хэрэгтэй.
Үр дүнг хэмжих. Зөв хэмжүүрүүд нь зөвхөн "засвар үүсгэсэн тоо" биш юм. Эдгээр нь нэгтгэх хурд, регрессийн хурд, хэмнэсэн хугацаа, хуурамч эерэг бууралт, засах хугацаа юм.
Эцэст нь, чухал газарт хүний баталгааны давхаргыг хадгал. Аюулгүй автомат засвар нь хөгжүүлэгчийн дүгнэлтийг үгүй хийдэггүй. Энэ нь давтагдсан ажлыг арилгаж, илүү үнэ цэнэтэй тоймд анхаарлаа төвлөрүүлснээр үүнийг сайжруулдаг.
Илрүүлэлтээс залруулга хүртэл: Гогцоог хаах нь
Хуучин AppSec хэрэгслүүдийн хамгийн том сул талуудын нэг нь процесс хэтэрхий эрт дуусдаг явдал юм. Олдвор гарч ирээд, тасалбар үүсгэгддэг. Дараа нь систем хүлээдэг.
Энэ бол хаалттай гогцоо биш. Энэ бол дамжуулалт юм.
Орчин үеийн AppSec програм нь илрүүлэлтээс эхлээд эрэмбэлэлт, засварлалт руу аль болох бага гар аргаар зохион байгуулалт хийх чадвартай байх шаардлагатай. Энэ бол автомат засварын жинхэнэ амлалт юм. Энэ нь зөвхөн засварыг хурдасгаад зогсохгүй. Энэ нь засвар хаана хийгдэж байгаа, хэрхэн нэвтрүүлж байгаа, давтагдах ажлыг хэн хийх ёстойг өөрчилдөг.
Тийм ч учраас энэ сэдэв зөвхөн техникийн хувьд ч биш, арилжааны хувьд ч чухал юм. Худалдан авагчид зөвхөн илрүүлэлтийн чанарыг хүсэхээ больсон. Тэд хүлээгдэж буй бараа бүтээгдэхүүний хэмжээг хэмжигдэхүйц хэмжээгээр бууруулж, асуудлыг илрүүлэхээс эхлээд шийдвэрлэх хүртэлх хөдөлгөөнийг хурдан болгохыг хүсдэг.
Xygeni нь аюулгүй автомат засварыг хэрхэн идэвхжүүлдэг вэ
Xygeni-ийн материалууд нь автоматаар засах чадвараа гурван сэдвийн хүрээнд байрлуулдаг: контекст, автоматжуулалт, хүргэлтийн интеграци.
Кодын тал дээр, Xygeni хиймэл оюун ухаан SAST AutoFix нь хөгжүүлэгчдэд бэлэн засваруудыг үүсгэж, эрсдэлтэй хэв маягийг аюулгүй хувилбаруудаар сольж, эдгээр засваруудыг хүргэдэг pull requests хийсвэр зөвлөмжийн оронд. Энэ нь XSS эсвэл SQL Injection зэрэг эмзэг байдлыг шууд засч, хөгжүүлэгчийн ажлын урсгалд аюулгүй код бичих шилдэг туршлагыг шууд хэрэгжүүлдэг.
Гэсэн хэдий ч Xygeni дахь автомат засварлалт нь үүнээс ч илүү юм SAST. Үүнд бас багтана Нууцын автомат засвар, энэ нь алдагдсан итгэмжлэлийг илрүүлж, урьдчилан бүтээгдсэн ашиглан автоматаар хүчингүй болгодог playbooks AWS, GCP, эсвэл GitLab зэрэг платформууд дээр. Энэ нь шууд хязгаарлах боломжийг олгож, гараар хариу өгөх саатлыг арилгаж, итгэмжлэлийг буруугаар ашиглах эрсдэлийг бууруулдаг.
Хараат байдлын тал дээр, Xygeni's SCA Автоматаар засах эмзэг хамаарлуудад засвар үүсгэж, тэдгээрийг өргөн хүрээнд хэрэгжүүлснээр бөөнөөр нь автоматаар нөхөн сэргээх боломжийг олгодог. Багууд автомат нөхөөсийг идэвхжүүлж, үүсгэж чадна pull requests сайжруулсан хувилбаруудтай бөгөөд засвар үйлчилгээг шууд нэгтгэх CI/CD pipelineхүргэлтийг тасалдуулахгүйгээр.
Үүнээс гадна эдгээр чадварууд нь дараахь зүйлийг хамарна Дэд бүтэц нь код (IaC) болон pipeline тохиргоонууд, буруу тохиргоо болон эрсдэлтэй дэд бүтцийн хэв маягийг мөн адил автоматжуулсан ажлын урсгалын нэг хэсэг болгон засч залруулахыг баталгаажуулах.
Энэ бол стратегийн гол санаа юм. Аюулгүй автомат засвар нь тусгаарлагдсан байдлаар ажилладаггүй. Энэ нь ...-г хамардаг. код (SAST), хамаарлууд (SCA), нууцууд болон дэд бүтэц (IaC), програм хангамжийн хангамжийн сүлжээний туршид тууштай нөхөн сэргээлтийг хангах. Түүнчлэн, энэ нь ашиглалтад суурилсан эрэмбэлэлт, хамаарлын графикийн шинжилгээ, болон бусадтай хослуулсан үед хамгийн сайн ажилладаг. CI/CD баталгаажуулалт, тиймээс засварууд нь зөвхөн автоматжуулагдахаас гадна аюулгүй, хамааралтай, үйлдвэрлэлд бэлэн байдаг.
Шуурхай хариулт: Autofix ашиглан эмзэг байдлаа хэрхэн аюулгүйгээр засах вэ?
Автомат засвар ашиглан эмзэг байдлыг аюулгүйгээр засахын тулд багууд нөхцөл байдалд тохирсон засвар, ашиглалтад суурилсан эрэмбэлэлт, нөхөн сэргээх эрсдэлийн шинжилгээ, CI/CD нэгтгэхээс өмнө баталгаажуулалт, хөгжүүлэгчийн зөвшөөрөл.
Энэ бол товч хариулт нь.
Үүнээс бага зүйл нь автоматжуулалт байж болох ч энэ нь үйлдвэрлэлд автоматжуулалтын хөгжүүлэгчдийн итгэж болох төрөл биш юм.
тусламж
AppSec дээр автоматаар засах гэж юу вэ?
AppSec дэх Autofix нь кодын алдаа, эмзэг хамаарал, ил гарсан нууц эсвэл дэд бүтцийн буруу тохиргоо зэрэг аюулгүй байдлын асуудлуудын залруулгын өөрчлөлтийг автоматаар үүсгэж, хүргэдэг.
Автоматаар засварлаж эвдэрсэн бүтээлтүүдийг хийж чадах уу?
Тийм. Хамаарлын шинэчлэлтүүд нь нийцгүй өөрчлөлтүүдийг оруулах, засварууд нь програмын контекстийг үл тоомсорлох, эсвэл өөрчлөлтүүдийг баталгаажуулалтгүйгээр хэрэгжүүлэх үед Autofix нь бүтээлтийг эвдэж болзошгүй.
Регресс үүсгэхгүйгээр эмзэг байдлаа хэрхэн автоматаар засах вэ?
Хяналттай ажлын урсгал дотор автомат засварыг ашиглах: ашиглах боломж болон хүртээмжээр нь эрэмбэлэх, нөхөн сэргээх эрсдэлийг шинжлэх, өөрчлөлтийг баталгаажуулах CI/CD, мөн хөгжүүлэгчийн зөвшөөрлийн алхамыг хадгална уу.
Аюулгүй автомат засвар нь гэнэн автомат засвараас юугаараа ялгаатай вэ?
Аюулгүй автомат засвар нь нөхцөл байдлыг мэдэрч, эрсдэлийг мэдэрч, pipeline-aware. Naive autofix нь нийцтэй байдал, ажиллах үеийн нөлөөлөл эсвэл инженерчлэлийн ажлын урсгалыг ойлголгүйгээр өөрчлөлтүүдийг санал болгодог эсвэл хэрэгжүүлдэг.
Хиймэл оюун ухааны автомат засвар найдвартай юу?
Тийм байж болох ч найдвартай байдал нь баталгаажуулалт болон засаглалаас хамаарна. Gartner нь хиймэл оюун ухаанд суурилсан байгууллагуудад дараах зүйлсийг зөвлөж байна code security Туслахууд уламжлалт AST болон кодын хяналтыг тэнцвэржүүлэх хяналт болгон ашигласаар байгаа, учир нь хиймэл оюун ухааны оновчлогчид гүйцэтгэл, найдвартай байдал, кодын чанартай холбоотой асуудлуудыг хэт их засах эсвэл алгасах боломжтой.
Эцсийн аялал
Autofix нь AppSec-д шинэлэг зүйл байхаа больсон. Энэ нь ажилчдын тоог нэмэгдүүлэх эсвэл хүргэлтийг удаашруулахгүйгээр ажлын ачааллыг бууруулах шаардлагатай багуудын хувьд практик шаардлага болж байна.
Жинхэнэ бэрхшээл нь засвар үйлчилгээг автоматжуулах эсэхэд биш, харин уг автоматжуулалт нь програм хангамжийг хэрхэн бүтээж, тээвэрлэж байгааг хүндэтгэж байгаа эсэхэд оршино.
Хэрэв таны автомат засварлах стратеги нь контекст, эрэмбэлэлт болон баталгаажуулалтыг үл тоомсорловол үнэ цэнээс илүү үрэлт үүсгэх болно. Хэрэв энэ нь хөгжүүлэгчийн ажлын урсгал, нөхөн сэргээх эрсдэл болон бусад зүйлсийн эргэн тойронд бүтээгдсэн бол CI/CD хяналтын цэгүүд нь аюулгүй байдлын үр дүн болон инженерчлэлийн хурдыг мэдэгдэхүйц сайжруулж чадна.
Энэ бол standard зорих нь зүйтэй.
Зохиогчийн Тухай
Хамтран үүсгэн байгуулагч ба технологийн захирал
Фатима Said AppSec, DevSecOps болон бусад програмуудад зориулсан хөгжүүлэгчдэд зориулсан контентоор мэргэшсэн. software supply chain securityТэрээр нарийн төвөгтэй аюулгүй байдлын дохионуудыг тодорхой, хэрэгжүүлэх боломжтой удирдамж болгон хувиргадаг бөгөөд энэ нь багуудад илүү хурдан эрэмбэлэх, чимээ шуугианыг багасгах, аюулгүй код илгээхэд тусалдаг.
