และยิ่งเมื่อได้เห็นถึงผลที่เกิดจากการละเมิดด้านข้อมูลที่เกิดขึ้นบ่อยๆ และความเสียหายที่ได้รับแล้ว สถานการณ์นี้ก็เป็นสิ่งที่ไม่อาจเพิกเฉย ผู้จำหน่ายซอฟต์แวร์สามารถและควรที่จะรับผิดชอบกับข้อผิดพลาดในผลิตภัณฑ์ของตนเองหรือไม่ ยกตัวอย่างเช่น หากนั่นส่งผลต่อกระแสไฟฟ้าที่คนนับล้านๆ ใช้งาน

Brian Fox, co-founder and CTO of Sonatype. Source: Sonatype

สำหรับไบรอัน ฟอกซ์ ผู้ร่วมก่อตั้งและ CTO ของ Sonatype คำตอบก็คือ “ใช่” อย่างไม่มีต้องสงสัย อันที่จริงแล้วนี่ไม่ใช่เพียงแค่การวิวัฒนาการที่หลีกเลี่ยงไม่ได้ของอุตสาหกรรมซอฟต์แวร์ แต่ในขณะนี้คณะกรรมการคุ้มครองผู้บริโภคของคณะกรรมาธิการการค้าแห่งสหพันธรัฐมีอำนาจที่จะฟ้องร้องผู้ผลิตในข้อหาเพิกเฉย ไบรอันได้ให้สัมภาษณ์พิเศษกับ Tech HQ ว่าหากผู้ผลิตวางจำหน่ายผลิตภัณฑ์ที่ไม่ปลอดภัยตั้งแต่ในระบบ “นั่นก็อาจเท่ากับเป็นการละเมิดกฎไปแล้ว และคุณก็อาจต้องรับผิดชอบเมื่อสามารถคาดการณ์ได้ถึงภัยที่จะเกิดขึ้น […] ในอุตสาหกรรมอื่นๆ ที่เกิดขึ้นก่อนหน้าเราต่างก็ผ่านพ้นการปฏิรูปนี้ไปแล้ว เชื่อไหมครับว่า เคยมีช่วงเวลาที่ผู้ผลิตอาหารนั้นไม่ต้องรับผิดชอบใดๆ เลยเมื่อมีสัตว์รบกวนแอบเข้าไปในขวดและทำให้คนล้มป่วย ซึ่งนั่นก็คือเมื่อหนึ่งร้อยปีที่แล้ว […] สมัยก่อนผู้ผลิตรถยนต์ก็ไม่มีหน้าที่รับผิดชอบ หากล้อรถหลุดออกมาแล้วไปทับคนบาดเจ็บ สิ่งที่ผมอยากจะสื่อก็คือ หากคุณคิดว่าผู้ผลิตซอฟต์แวร์ไม่จำเป็นต้องรับผิดชอบความเสียหายใดๆ เลย ไม่ว่าในรูปแบบใดก็ตาม นั่นเท่ากับว่าคุณไม่ได้หันไปพิจารณาสิ่งที่เกิดขึ้นในประวัติศาสตร์ของ […] อุตสาหกรรมอื่นก่อนหน้านี้เลย ผมไม่รู้ว่าคุณคิดอย่างไร แต่ผมว่าคุณคิดผิดแล้ว”

ไม่ว่าอย่างไร อุตสาหกรรมซอฟต์แวร์ก็ยังไม่ได้มีการตกลงร่วมกันเพื่อหาแนวทางว่าความรับผิดชอบหรือการรับผิดนั้นจะออกมาในรูปแบบใด เมื่อหลายทศวรรษก่อนหน้า ลำดับขั้นของความรับผิดชอบนั้นสามารถแยกออกมาได้ชัดเจนกว่านี้เพราะสินค้าภายใต้กรรมสิทธิ์นั้นถูกจัดส่งออกไปในรูปแบบของแผ่นซีดี แต่สำหรับวัฏจักรการผลิตที่ทำได้อย่างรวดเร็ว รวมถึงการใช้ไลบรารี่ เฟรมเวิร์ก และคอมโพเนนต์แบบโอเพ่นซอร์สเช่นในทุกวันนี้ ภาพรวมในท้ายที่สุดจึงเป็นสิ่งที่ตีความได้ลำบากไม่น้อย แนวคิดที่กำลังติดท็อปเทรนด์บนเสิร์ชเอนจิ้นในเวลานี้ก็คือ SBoM (Software bill of materials) หรือ โปรแกรมที่ใช้จัดการกับรายการส่วนประกอบ ซึ่งเป็นหัวข้อที่ใครๆ พากันให้ความสนใจมากขึ้นนับตั้งแต่เริ่มมีข่าวคราวเกี่ยวกับความเปราะบางของซอฟต์แวร์ซัพพลายเชนหนาหูมากยิ่งขึ้น โดยเฉพาะอย่างยิ่งจากข่าวข้อบกพร่องของ Apache Log4j เมื่อปีที่แล้ว

องค์กรซอฟต์แวร์ บริษัท มูลนิธิ และชุมชนกำลังรวบรวมความคิดเห็น ทั้งยังเริ่มมีการเข้ามากำกับดูแลพร้อมกับร่างกฎหมายที่เกี่ยวข้องมากขึ้น สำหรับในยุโรป สิ่งเป็นโฟกัสหลักขณะนี้ก็คือการเรียกคืนและกฎระเบียบที่อยู่ในรูปแบบขององค์ประกอบบัญญัติด้านความมั่นคงปลอดภัยทางไซเบอร์ ถึงแม้จะเป็นแนวทางที่ถูกต้อง แต่ไบรอันก็ยังมองว่าทางสหภาพยุโรปนั้นกำลังทำพลาด ในแง่ที่กลายเป็นสร้างให้เกิดความคลุมเครือยิ่งกว่าเดิมว่าอะไรบ้างที่ถือว่าเป็นหรือไม่เป็นโอเพ่นซอร์ส

ขณะที่ในสหรัฐอเมริกา คำสั่งประธานาธิบดีของสหรัฐอเมริกาเกี่ยวกับ SBoM นั้นดูจะเน้นไปที่กฎหมายในแบบสั่งแล้วก็จบๆ ไป “การผลักดัน […] ความสามารถในการเรียกคืน […] เป็นแนวทางที่ผมผลักดันมาตลอด [เช่นกัน] และสิ่งที่ผมไม่ค่อยพอใจนักเกี่ยวกับข้อกำหนดแรกเริ่มด้าน SBoM ก็คือกฎเหล่านั้นมัวแต่ไปมุ่งเน้นเกี่ยวกับปัญหาในประเด็นที่ผิดๆ พวกเขามัวแต่สนใจกับความต้องการในการสร้างรายการวัสดุแล้วมอบให้เรา [ผู้ใช้ปลายทาง] เมื่อคุณขายซอฟต์แวร์ และผมมักจะเปรียบเทียบให้เห็นภาพด้วยการให้ลองสมมติว่าเราบอกผู้ผลิตรถยนต์ว่าคุณไม่จำเป็นต้องมีการเรียกคืนอีกต่อไปแล้ว ทั้งหมดที่ต้องทำเมื่อขายรถก็คือพิมพ์รายการวัสดุอะไหล่ต่างๆ และยัดใส่ไว้ในช่องเก็บของหน้ารถก็พอ ใครๆ มักจะหัวเราะเมื่อผมพูดแบบนั้นเพราะมันฟังดูตลกสิ้นดี แต่นั่นแหละคือสิ่งที่คำสั่งประธานาธิบดีบอกให้เราทำ โดยที่ไม่มีตรงไหนเลยที่ส่งเสริมให้บริษัทหันมาสนใจกับ SBoM นั้น และรับรองว่าหากมีจุด

อาจจะฟังดูสมเหตุสมผลดี ถ้าการพัฒนาซอฟต์แวร์จะเป็นไปอย่างช้าลง และไม่ต้องรีบเร่งตอบสนองแนวโน้มในการวนซ้ำ ผลิตภัณฑ์ที่วางจำหน่ายนั้นก็น่าจะปลอดภัยกับผู้ใช้ปลายทางมากขึ้นด้วย แต่นั่นไม่ใช่สิ่งที่เกิดขึ้นเลย ไบรอันบอกกับเรา จากหลายๆ บริษัทที่ Sonatype ได้ทำการสำรวจเมื่อไม่นานมานี้ “เราพบว่าบริษัทที่พยายามแก้ไขทั้งสองปัญหา [กระบวนการพัฒนาที่รวดเร็วและปลอดภัย] นั้นกลับปลอดภัยและเร็วกว่าบริษัทที่มุ่งเน้นเฉพาะความปลอดภัยเพียงอย่างเดียวหรือบริษัทที่มุ่งเน้นที่ความว่องไวเพียงอย่างเดียวเสียอีก ซึ่งฟังแล้วย้อนแย้งมาก” เขาอธิบายว่าบริษัทที่พัฒนาซอฟต์แวร์อย่างรวดเร็วและปลอดภัยจะมีกระบวนการ CI/CD ซึ่งมุ่งเน้นที่ DevSecOps ที่เหมาะสมรองรับอยู่แล้ว และบริษัทเหล่านั้นก็คือบริษัทที่ประสบความสำเร็จมากที่สุดนั่นเอง

“การบริหารจัดการซัพพลายเชนได้ดีแปลว่าคุณจะต้องทำงานช้าลงงั้นหรือ เปล่าเลย คำตอบก็คือคุณปลอดภัยขึ้นและรวดเร็วขึ้น เพราะคุณมีการแก้ไขและการทำงานซ้ำที่ไม่ได้วางแผนไว้ก่อนน้อยลงกว่าเดิมต่างหาก การมีวิธีจัดการกับ Dependency อย่างมีประสิทธิภาพนั้นก็แปลว่านักพัฒนาจะสามารถสร้างนวัตกรรมใหม่ๆ ได้อย่างปลอดภัยด้วย ซึ่งเป็นสถานการณ์หายากที่ทุกฝ่ายล้วนได้รับประโยชน์ หากทำอย่างเหมาะสม [ความปลอดภัย] ไม่จำเป็นต้องเป็นตัวถ่วงระบบเสมอไป”

แทบจะเป็นไปไม่ได้เลยที่จะจัดส่งซอฟต์แวร์ที่ปลอดภัยและจะปลอดภัยทั้งหมดตลอดเวลา ทั้ง Dependency การอัปเดต และวิธีเจาะระบบใหม่ๆ ต่างก็มีส่วนทำให้สิ่งนี้เป็นไปไม่ได้ แต่ไบรอันก็ยังชี้ให้เห็นว่า ความเปราะบางส่วนใหญ่ทั้งในปัจจุบันและอนาคตนั้นอาจเป็นแค่เพียงการคาดคะเนในทางทฤษฎีเท่านั้น จะต้องมีโหมดในการใช้ซอฟต์แวร์ที่ทำให้ผู้ไม่ประสงค์ดีสามารถนำไปใช้เพื่อเจาะระบบได้ กระบวนการคิดที่ผิดก็คือ “การมองว่าปัญหาอย่างความเปราะบางนี้เหมือนกับผักกาดที่ใบแหว่ง และเราไม่ควรวางขายผักกาดที่ใบแหว่งๆ นั่นไม่จริงเลย การโจมตีที่มุ่งร้ายก็เหมือนผักกาดใบแหว่ง และสิ่งเหล่านั้นไม่ได้ถูกนำออกจากคลังเก็บโดยเร็วที่สุดเท่าที่จะเป็นไปได้ แต่จริงๆ แล้วความเปราะบางส่วนใหญ่นั้นเหมือนกับเนยถั่วมากกว่า เพราะมันก่อให้เกิดอาการแพ้รุนแรงในบางคน แต่สำหรับคนส่วนใหญ่นั้นกลับไม่มีปัญหาอะไรไ

บทบาทที่ปรึกษาของรัฐบาลและองค์กรต่างๆ เปิดโอกาสให้ไบรอันได้เดินทางไปทั่วโลก โดยล่าสุดเขาได้มีโอกาสร่วมงานกับรัฐบาลของไบเดนในด้านความปลอดภัยไซเบอร์และปัญหาซอฟต์แวร์ เราไม่มีคำตอบง่ายๆ อย่าง คลังที่ตรวจสอบก่อนล่วงหน้าสำหรับส่คอมโพเนนต์ต่างๆ “มีคอมโพเนนต์อยู่มากมายเป็นล้านๆ ดังนั้นจึงเป็นไปไม่ได้เลยที่คุณจะตรวจสอบทั้งหมดอย่างมีประสิทธิภาพ เป็นไปไม่ได้ และบริษัทที่ทำแบบนั้นก็จะเรียกสิ่งนี้ว่า Repository ทองคำ ปัญหาก็คือคุณจะส่งผลกระทบในเชิงลบต่อนวัตกรรมเพราะคุณทำให้นักพัฒนาไม่สามารถนำสิ่งที่ยังไม่ได้ผ่านกระบวนการสารพัดมาใช้งานได้ แต่ปัญหาที่เลวร้ายที่สุดก็คือกระบวนการส่วนใหญ่นั้นไม่มีการย้อนกลับไปและตรวจสอบสิ่งที่อยู่ใน Repo”

และในกรณีเช่นนี้ เจ้าของ Repo ทองคำที่ว่า ซึ่งก็คือบริษัทพัฒนาซอฟต์แวร์ที่มี “Repository ของคอมโพเนนต์ที่ปลอดภัยทั้งหมด” ก็ยังจะต้องรับผิดชอบอยู่ดีจากมุมมองของผู้ใช้ปลายทาง หากเกิดความเสียหายใดๆ ขึ้นจากการใช้งานซอฟต์แวร์ดังกล่าว

ในขณะที่ยังไม่มีทางลัดใดๆ ในการจัดการความรับผิดทางกฎหมายของซอฟต์แวร์ ผู้เชี่ยวชาญที่คร่ำหวอดอยู่ในวงการซอฟต์แวร์ (และความปลอดภัยทางไซเบอร์) อย่างเช่นไบรอันนั้นก็จะต้องมีบทบาทสำคัญในการวางนโยบายที่สอดคล้องเชื่อมโยงกัน อาจต้องใช้เวลาอีกสักพักกว่าที่กฎระเบียบจะเป็นมากกว่าแค่แนวทางที่องค์กรต่างๆ ร่างขึ้นเพื่อรับมือกับปัญหาเดียวกันนี้ สำหรับอีกสองสามปีนับจากนี้ ผู้ซื้อพึงระวัง จึงยังเป็นคำแนะนำที่ดีที่สุดในการรักษาความปลอดภัยของการใช้งานซอฟต์แวร์ในชีวิตประจำวัน และสำหรับบริษัทพัฒนา DevSecOps ก็จะต้องเป็นมากกว่าคำฮิตติดเทรนด์ประจำเดือนด้วย

The post Repo ทองคำไม่ใช่ยาวิเศษสำหรับ DevOps ที่ปลอดภัยกว่าเดิม appeared first on Tech Wire Asia.

隨著資料外洩的影響變得更加普遍且具有破壞性，這樣的責任歸屬似乎更難定義。軟體供應商是否該為產品缺陷負責，例如，危及數百萬人的電力供應問題？

Brian Fox, co-founder and CTO of Sonatype. Source: Sonatype

對於 Sonatype 的共同創辦人兼技術長 Brian Fox 而言，「答案是相當肯定的 」；事實上，這不僅對於軟體產業而言是無法避免的轉變，美國聯邦貿易委員會的消費者保護委員會已有權力追究發行商的過失。他在接受 Tech HQ 的獨家採訪時表示，若是軟體製造商發表的產品本來就是不安全的，「這有可能已嚴重違規，當傷害是經過合理評估後可預見時，即可被追究責任[…]在我們先前的每一個產業都曾經歷過類似轉變。不管你信不信，早在 100 年前，曾有過食品製造商無需對產品內含有蟲，以及食物中毒事件負責[…]，汽車製造商亦無需對車輪從他們製造的汽車脫落事件，而對消費者造成的相關損害負責。我說，聽好，若是打賭某種形式的責任與義務，從來都不會落到軟體製造商頭上，那麼基本上就是打賭一件史上[…]任何產業皆從未發生過的情況。我不知道你是怎麼想的，但我是不敢輕易打賭的。」

軟體產業現階段尚未對責任與問責的形式達成任何共識，也許早在數十年前，當專利產品以 CD 形式實體發表時，責任歸屬是相對明確的。但是目前快速更迭的生產週期與開源庫、框架與元件的使用，讓歸屬變得更加不明確。目前在搜尋引擎上排名較前的是 SBoM（軟體物料清單）之概念，在某些知名軟體供應鏈漏洞事件曝光後（特別是去年的Apache Log4j 漏洞事件），人們對這方面的興趣日益劇增。

軟體組織、公司、基金會與社群正在凝聚意見，治理與立法的雛形亦逐漸清晰。在歐洲，目前的重點是以《網路復原力法案》的形式進行撤回和監管。但 Brian 卻表示，儘管方向是正確的，但歐盟卻放錯焦點，混淆是否為開放源碼的定義。

在美國，行政命令對於 SBoM 的關注，似乎正在朝向一種射後不理的立法方向發展。 「推動[…]能夠進行撤回[…]是我[也]正在大力推行的目標之一。我不喜歡 SBoM 最初要求的一點是，焦點放錯地方。他們聚焦於需要建立出一份物料清單，並在銷售出軟體時將其交給我們[終端使用者]。我喜歡打的比方是，試想一下，如果我們告知汽車製造商不再需要進行撤回程序。當在銷售一輛汽車時，需要做的就只是列印出物料清單，並將它放在手套箱內，對吧？當我這樣比喻時，人們總是覺得很可笑，因為這真的很荒謬，但這正是 SBoM 行政命令所宣稱需執行的內容，並沒有實際上做些什麼來鼓勵公司將焦點放在 SBoM 上，並確保在未來突然出現漏洞時，他們會對此作出相應措施，這也代表了將責任都推到了終端使用者頭上。」

若是軟體開發商願意放慢腳步，不總是將焦點只放在快速迭代的趨勢，那麼最終產品將在某種程度上對終端使用者而言，也許更加安全，這似乎較合乎邏輯一點。但事實並非如此，Brian 告訴我們，在 Sonatype 最近調查的公司之中：「我們發現同時解決這兩個問題[快速且安全的開發流程]的公司，實際上比僅關注其中一項的公司更加安全且迅速，因此，這似乎是有點矛盾的」。他解釋著說，快速且安全的開發軟體公司將以更正確角度，聚焦於安全、開發與營運的 CI/CD 流程，而這些公司剛好也都是最成功的。

「做好供應鏈管理是否就代表你必須得放慢腳步？不，這個問題的答案其實是，當以更安全的方式執行時，你也將執行得更迅速，因為意料之外的修復與重複工作也相對較少。以更有效率的方式來管理依存關係，也代表開發人員也能以更安全的方式進行創新。這是一種少見的雙贏局面，若能處理得當，[安全性]不一定只能成為系統的累贅。」

想要打造無安全疑慮的軟體，幾乎可說是不可能的任務。依存關係、更新與全新運用方法都再再證明無法做出這樣的保證。但 Fox 指出，重要是需要注意，大多數的潛在漏洞事件，無論是現在抑或是將來，都可能只是出自於理論的構想，必須建構出一套軟體使用模式，讓任何人都無法利用漏洞得利。他告訴我們，錯誤的思維流程是：「把這個問題定義為是含有污染殘留物的生菜，不應該銷售有污染殘留物的生菜，其實不是很對，因為惡意攻擊就像含有污染殘留物的生菜，確實得快速地從倉庫中清除，但典型的漏洞事件其實更像是花生醬，能對某些人造成致命性過敏，而對其他人而言，是完全沒有任何危害的。」

Brian Fox 因為擔任政府與組織的顧問，足跡遍佈全球，最近的一次是與拜登政府合作，鑽研網路安全性與軟體問題，想要解決這方面的問題絕非易事，例如，事先審查所謂的安全性元件庫，「因為存放數以百萬計的元件，實在無法一一審查所有元件，因為這是不可能的任務。而這樣做的公司，他們稱之為是最佳元件庫。問題就出在間接地使創新停滯不前，因為你令開發者不能使用未經通過繁冗審查程序的素材。但最嚴重的問題是，大多數的流程並沒有被真正地追蹤跟進與審查元件庫的內容。」

若狀況真是如此時，最佳元件庫的所有者，也就是具備「完整安全元件庫」的軟體開發公司，在終端使用者的觀點中，仍需對使用軟體所產生的任何損失負責。

雖然沒有任何快速的方法能夠解決軟體的法律歸屬責任問題，但像 Fox 這樣深耕於軟體產業（與網路安全產業）的專家，將在制定出具備一致性政策方面，扮演極為重要的角色。只還需要更多的時間，才能讓這些準則成為，不再只是因多個實體對相同問題的不同看法，而制定出的規則。在接下來的幾年內，「謹慎消費 」仍是在日常使用軟體時，維持安全性的最佳建議，對於軟體開發公司而言，安全、開發與營運必須不再只是流行口號而已。

The post 最佳元件庫並非安全開發營運的唯一正解 appeared first on Tech Wire Asia.

데이터 유출이 점점 흔해지고 그 피해가 증가함에 따라 이러한 상황은 조사하기도 쉽지 않습니다. 예를 들어 수백만 명에 대한 전력을 공급하는 제품에 결함이 있을 경우 소프트웨어 공급사에 책임을 물을 수 있을까요? 또한, 그들이 책임을 저야 할까요?

Brian Fox, co-founder and CTO of Sonatype. Source: Sonatype

Sonatype의 공동 창립자이자 CTO인 Brian Fox의대답은 ‘그렇다’입니다. 이런 책임을 지는 것이 소프트웨어 산업의 필연적인 진화일 뿐만 아니라 미국 연방거래위원회 산하 소비자보호위원회(US Federal Trade Commission’s Consumer Protection Board)는 이미 퍼블리셔에게 과실 책임을 물을 수 있는 권한을 갖고 있기 때문입니다. 그는 Tech HQ와의 독점 인터뷰에서 소프트웨어 개발사가 본질적으로 안전하지 않은 제품을 출시하는 경우 “그 자체가 이미 규정 위반일 잠재적인 가능성이 있으며, 피해가 합리적으로 예측 가능한 경우 책임을 져야 할 수 있습니다[…] 지금까지 다른 모든 산업은 이러한 변화를 겪었습니다. 믿기 어렵겠지만, 불과 100년 전만 해도 식품 제조사가 제품안에해충이 들어가서 사람들이 질병에 걸리는 것에 대해 책임을 지지 않던 시절이 있었습니다 […] 자동차 바퀴가 분리되어 사람이 다쳐도 자동차 제조사가 책임을 지지 않던 시절이 있었습니다. 소프트웨어 개발사에게 어떤 형태로든 책임과 의무가 부과되지 않을 것이라고 믿는 것은 […] 말 그대로 다른 산업의 역사상 한 번도 일어나지 않은 일이 일어날 것이라고 내기하는 것과 마찬가지입니다. 당신은 어떨지 몰라도 저는 그런 내기를 하지 않을 것입니다.”라고 밝혔습니다.

소프트웨어 업계는 아직 책임과 의무의 형태에 대해 그 어떤 합의도 이루지 못했습니다. 오히려 수십 년 전 독자적인 제품을 CD에 담아 배송했을 때 책임 소재가 더 명확했을 것입니다. 하지만 빠르게 반복되는 오늘날의 프로덕션 주기와 오픈 소스 라이브러리 사용, 프레임워크 및 구성요소로 인해 상황은 훨씬 더 모호해 졌습니다. 현재 검색 엔진에서 SBoM(소프트웨어 구성요소 목록)이라는 개념의 검색 빈도가 증가하고 있는데, 이는 작년 Apache Log4j 결함 등 잘 알려진 소프트웨어 공급망 취약점이 드러난 이후 이 개념에 대한 관심이 높아졌기 때문입니다.

소프트웨어 조직, 기업, 재단, 커뮤니티가 의견을 모아 거버넌스 및 법률 제정이 시작되고 있습니다. 유럽에서는 현재 사이버 복원력 법안의 일부로 구성된 리콜 및 규제에 초점을 맞추고 있습니다. 하지만 Brian은 이것이 올바른 방향이기는 하지만, EU가 오픈 소스 구분 기준을 명확하게 정하지 못해 목표를 달성하지 못했다고 합니다.

미국에서는 행정명령이 SBoM에 집중하면서 일종의 ‘실행 후 잊어버리는’ 법안이 되고 있는 것으로 보입니다. “리콜을 […] 강제하는 것은 […] 제가 항상 주장해온 것 중 하나입니다. 초기 SBoM 명령에서 마음에 들지 않았던 점은 문제의 엉뚱한 부분에 너무 집중하고 있다는 점이었습니다. 소프트웨어를 판매할 때 구성요소 목록을 작성해서 우리[최종 사용자]에게 제공해야 하는 필요성에 집중했습니다. 제가 보기에는 자동차 제조사에게 더 이상 리콜을 할 필요가 없다고 하는 것과 마찬가지입니다. 자동차를 판매할 때 부품 명세서를 출력해서 글러브박스에 붙이기만 한다고 될까요? 제가 이 말을 하면 사람들은 항상 어처구니 없으니까 웃습니다. 하지만 SBoM에 대한 행정명령은 이와 다를 바가 없습니다. 기업들이 실제로 SBoM에 신경 쓰도록 하고, 향후 취약점이 발견되었을 때 이에 대한 조치를 취하도록 장려하는 데 아무런 도움이 되지 않습니다. 결국은 책임을 최종 사용자에게 전가한다는 의미입니다.”

논리적으로 봤을 때 소프트웨어 개발 속도를 늦추고 제품 출시 주기가 늘어나면 최종 제품이 최종 사용자에게 더 안전할 것이라고 생각할 수 있습니다. 하지만 Brian은 그렇지 않다고 말합니다. Sonatype이 최근 조사한 기업에 대해 이렇게 말합니다. “빠르고 안전한 개발 프로세스라는 두 마리 토끼를 모두 잡은 기업만이 오직 보안에만 집중하는 기업이나 속도에만 집중하는 기업보다 더 안전하고 빠르다는 사실을 발견했습니다. 그래서 역설적이죠.” 그는 소프트웨어를 빠르고 안전하게 개발하는 기업은 올바른 DevSecOps 중심 CI/CD 프로세스를 갖추고 있으며, 이러한 기업이 가장 성공적이라고 설명합니다.

“공급망을 더 잘 관리한다는 것이 속도를 늦춰야 한다는 것일까요? 아닙니다. 오히려 예상하지 못한 수정과 재작업이 줄어들기 때문에 더 안전하고 빨라집니다.  종속성을 관리하는 효율적인 방법이 있다는 것은 개발자가 안전하게 혁신할 수도 있다는 것을 의미합니다. 이것은 제대로 수행된다면 윈-윈할 수 있는 드문 시나리오 중 하나입니다. [보안]이 시스템에 걸림돌이 될 필요는 없습니다.”

완벽한 보안을 갖춘 소프트웨어를 출시하는 것은 불가능에 가깝습니다. 종속성, 업데이트, 새로운 취약점 공격 방법 등이 복합적으로 작용하기 때문에 완벽한 보안은 존재하지 않습니다. 하지만 Fox는 현재 또는 미래에 발생할 수 있는 대부분의 잠재적 취약점은 이론적인 구성으로만 남아 있을 수 있다는 점이 중요하다고 지적합니다. 악의적인 공격자가 취약점을 활용할 수 있는 소프트웨어의 사용 모드가 분명히 존재한다는 것입니다. 그는 “취약점은 상한 상추와 같아서 상한 상추를 팔아서는 안 된다는 식으로 이 문제를 생각하는 것”이 잘못된 사고방식이라고 합니다. “그렇지 않습니다. 악의적인 공격은 오염된 상추와 같아서 리포지토리에서 서둘러 삭제해야 하지만, 일반적인 취약점은 땅콩버터와 비슷합니다. 누군가에게는 치명적인 알레르기를 일으킬 수 있지만, 대부분의 사람들에게는 아무 문제가 되지 않아요.”

Brian Fox는 전 세계 정부 및 조직의 자문 역할을 맡아왔으며, 가장 최근에는 사이버보안 및 소프트웨어 문제에 대해 바이든 행정부와 협력하고 있습니다. 예를 들어, 사전 심사를 거쳐 안전한 구성요소만 담긴 리포지토리와 같은 쉬운 해답은 없습니다. “세상에는 수백만 개의 구성요소가 있으며, 모든 구성요소를 충분히 검사하는 것은 불가능합니다. 절대 불가능합니다. 그렇게 검사하는 기업은 이것을 골든 리포지토리라고 부릅니다. 문제는 개발자가 (골든) 리포지토리 외부의 구성요소는 사용하지 못하게 됨으로써 혁신을 저해하게 된다는 점입니다.  그리고 최악의 문제는 대부분의 프로세스가 실제로 리포지토리의 내용물을 백업하거나 검사하지 않는다는 것입니다.”

그리고 이 경우 최종 사용자의 관점에서 볼 때 ‘안전한 구성요소 리포지토리’를 보유한 소프트웨어 개발사, 즉 골든 리포지토리의 소유자는 여전히 소프트웨어를 사용해서 발생하는 모든 손해에 대해 책임이 있습니다.

소프트웨어에 대한 법적 책임 추적 문제를 빠르게 해결할 방법은 없지만, Fox처럼 소프트웨어 산업(및 사이버보안 산업)에 깊이 관여하고 있는 전문가들이 일관된 정책 수립에 중요한 역할을 할 수 있습니다. 이런 정책이 동일한 문제에 대해 관점이 다른 여러 단체가 만든 가이드라인 이상의 규정으로 자리잡기 까지는 시간이 조금 더 걸릴 것입니다. 향후 몇 년 동안은 소프트웨어를 안전하게 사용하기 위한 ‘주의 사항’만이 있을 것입니다. 그리고 개발사는 DevSecOps를 일시적인 유행어로 취급하지 않고 이를 위해 더 많은 노력을 기울여야 할 것입니다.

The post 골든 리포지토리는 더 안전한 DevOps를 위한 묘책이 아닙니다 appeared first on Tech Wire Asia.

As the effects of data breaches become more commonplace and damaging, that situation seems difficult to parse. Can and should a software vendor be held responsible for flaws in their products that endanger, for example, the power supply to millions of people?

Brian Fox, co-founder and CTO of Sonatype. Source: Sonatype

For Brian Fox, co-founder and CTO of Sonatype, the answer is a firm ‘yes;’ in fact, it’s not only an inevitable evolution of the software industry, but the US Federal Trade Commission’s Consumer Protection Board already has the power to hold publishers as negligent. Speaking exclusively to Tech HQ, he said, that if software makers ship an inherently insecure product, “that’s potentially already against the rules, you can be held accountable when harm is reasonably foreseable […] Every other industry before us has gone through this transformation. Believe it or not, there was a time when food manufacturers were not liable for pests getting into their bottles and people getting sick, just 100 years ago […] There was a time when auto manufacturers were not held responsible when the wheels fell off their cars and hurt people. I say, look, if you’re betting that some form of accountability and liability doesn’t end up on the producers of software, you’re basically betting on something that has literally never happened in the history of […] any other industry. I don’t know what you think but I’m not taking that bet.”

The software industry hasn’t yet agreed by any means on what shape responsibility and accountability may take. Perhaps a few decades  ago, the chain of responsibility was clearer when proprietary products were physically shipped on CD. But today’s quickly-iterating production cycles and use of open-source libraries, frameworks, and components make the eventual picture much more unclear. Ranking high in search engine returns at the moment is the concept of SBoM – software bill of materials – something that has had a greater interest shown in it since some of the better-known software supply chain vulnerabilities came to light, especially the Apache Log4j flaw of last year.

Software organizations, companies, foundations, and communities are coalescing opinions, and the beginnings of governance and legislation are emerging. In Europe, the focus is currently on the recalls and regulation in the form of elements of the Cyber Resiliency Act. But, Brian said, although in the right direction, the EU is off-target by muddying the waters around what is and isn’t considered open source.

In the US, the Executive Order’s concentration on an SBoM seems to be moving towards a type of fire-and-forget legislation. “Pushing on […] being able to do a recall […] is one thing I’ve always kind of pushed on [too]. The thing that I didn’t like about the initial SBoM mandate was that it was a little bit too focused on the wrong part of the problem. They focused on the need to create a bill of materials and give it to us [end-users] when you sell a software. And the analogy I like to use is, imagine if we told our auto manufacturers you don’t need to do recalls anymore. All you got to do when you sell a car is print out the bill of parts and stick it in the glove box, right? People always laugh when I say that because it’s ridiculous. But that’s exactly what the executive order on SBoM says to do. It doesn’t do anything to encourage the companies to actually pay attention to that SBoM, and make sure when their vulnerability pops up in the future, they do something about it. The implication of that is putting the responsibility on the end user.”

It seems logical that if software development were to slow down and perhaps lose its tendency to embrace fast iterations, the end product would be somehow safer for the end user. But that’s not the case, Brian told us. Of the companies Sonatype had surveyed recently, “We found that companies that are solving for both problems [fast and secure development processes] are actually both more secure, and faster than the companies that focus only on being secure, or the company that is focused only on going fast. So that seems paradoxical.” He explained that companies that develop software quickly and safely have the right DevSecOps-focused CI/CD processes in place, and those companies are the most successful.

“Does doing a better job managing your supply chain mean you have to go slower? No, the answer to this is actually you’re safer, and you’re faster because you have fewer unplanned fixes and rework. Having efficient ways to manage your dependencies means developers can also safely innovate. This is one of these rare win-win scenarios, if it’s done properly. [Security] doesn’t have to be a drag on the system.”

It’s borderline impossible to ship software that is and will remain entirely secure. Dependencies, updates, and new exploitation methods all conspire to ensure there’s no such thing as a sure thing. But, Fox points out, it’s important to note that most potential vulnerabilities, present or future, may remain only theoretical constructs. There has to be a mode of use of the software that allows any exploit to be leveraged by bad actors. The wrong thought process, he told us, was “to think about this problem like vulnerabilities are tainted lettuce, and you shouldn’t be selling tainted lettuce. That’s not true. Malicious attacks are like tainted lettuce, and those things do get taken down from the repository post haste, but what the typical vulnerability looks like is more like peanut butter. It causes deadly allergies in some people, and for a bunch of other people, it’s totally fine.”

Brian Fox’s advisory role to governments and organizations has taken him all over the world, most recently working with the Biden administration on cybersecurity and the software issue. There are no easy answers like, for instance, a pre-vetted repository of so-called safe components. “There’s millions of components out there, it’s impossible for you to vet all of them in a sufficient way. It’s impossible. And companies that do that, they call it the golden repository. The problem is you indirectly harm innovation because you stop developers from using something that hasn’t already gone through some crazy process. But the worst problem is, most processes don’t actually follow back up and check the stuff that’s in the repo.”

And if that’s the case, the owner of the golden repo, the software development company with the ‘all safe component repository’ is still effectively liable in the eyes of the end user for any damages accruing from software use.

While there are no quick ways that the trail of legal liability for software can be navigated, experts deeply embedded in the software industry (and cybersecurity industry) like Fox will be instrumental in forming coherent policy. It will just take a little more time before the rules are more than guidelines produced by multiple entities with different takes on the same problems. For the next few years, caveat emptor remains the best advice for staying safer in the daily use of software. And for development companies, DevSecOps has to be more than this month’s buzzphrase.

The post The Golden Repo Is No Silver Bullet For Safer DevOps appeared first on Tech Wire Asia.

ปฏิเสธไม่ได้เลยว่าแหล่งข้อมูล สำหรับนักพัฒนานั้นกำลังถูกโจมตีโดยผู้ประสงค์ร้ายซึ่งตระหนักอยู่เต็มอกว่าแค่การจดชื่อโดเมนเนมแบบสะกดผิดๆ แบบง่ายๆ ก็สามารถแจกจ่ายโค้ดแบบพังๆ ไปยังโปรเจ็กต์นับพันทั่วโลกได้แล้ว แต่เหตุการณ์ที่ซัพพลายเชนต้องเผชิญกับมัลแวร์แบบรุนแรงส่วนใหญ่นั้นมักไม่มีการแจ้งรายงาน ซึ่งก็อาจเพราะว่ามีจำนวนมากจนนับไม่ถ้วน การสแกนอย่างต่อเนื่องโดยผู้ให้บริการความปลอดภัยไซเบอร์สำหรับซัพพลายเชน OSS ชื่อ Sonatype พบ 102,930 เหตุการณ์ที่เป็นอันตรายหรืออาจเป็นอันตรายของโค้ดทั่วระบบนิเวศ npm โดยเมื่อผสานเข้ากับไปป์ไลน์การพัฒนาแล้ว แอปพลิเคชันที่เป็นภัยเหล่านี้จะเข้าสู่ขั้นตอน QA, การทดสอบ หรือแม้แต่การผลิตได้ง่ายๆ จากนั้นก็สามารถล้วงข้อมูลยืนยันตัวตนบนคลาวด์ ควบคุมรอบการทำงานของโปรเซสเซอร์เพื่อทำเหมืองคริปโต เจาะที่อยู่ IP ของบริษัท และกิจกรรมอื่นๆ ที่ไม่พึงประสงค์ที่พบได้บ่อยๆ อีกนับไม่ถ้วนจากมัลแวร์

ชุมชนนักพัฒนาได้โพสต์แหล่งข้อมูลและโค้ดเพื่อให้สาธารณชนทั่วไปใช้งาน ตั้งแต่มีประเด็นกรรมสิทธิ์ UIX ที่กลายเป็นฟางเส้นสุดท้ายที่เกิดจากการที่นำ Linux kernel เวอร์ชันแรกๆ มาใช้ ถึงแม้อุดมคติของ OSS (Open Source Software หรือซอฟต์แวร์โอเพ่นซอร์ส) จะยังคงอยู่ต่อไปเพราะประโยชน์ที่ เหลือคณานับ มากมายสำหรับนักพัฒนาและซอฟต์แวร์ทั้งหมด แต่ตัวกลางในการส่งมอบคุณประโยชน์ที่ว่านั้นกลับกำลังถูกองค์ประกอบมุ่งร้ายเข้าครอบงำ นี่เป็นด้านมืดของพฤติกรรมมนุษย์และคงหลีกเลี่ยงไม่ได้ นอกเสียจากว่าทุกโปรเจ็กต์จะถูกเขียนอยู่ใหม่ตั้งแต่แรกเริ่มโดยไม่มีการอ้างอิงถึงไลบราลี่ เฟรมเวิร์ก หรือโค้ดที่ใช้ร่วมกันเลย

องค์กรต่างๆ ได้แก้ไขปัญหาความปลอดภัยและการควบคุมคุณภาพหลายๆ ปัญหาด้วยการสร้างคลังของตัวเองที่ประกอบด้วยองค์ประกอบ “ที่ผ่านการอนุมัติแล้ว” สำหรับใช้ภายใน หรืออย่างน้อยๆ ก็เป็นการยืนยันความปลอดภัยของแพ็กเกจทั้งหมดที่เข้ามาในไปป์ไลน์ CI/CD ของตน การควบคุมนั้นเรียกได้ว่าเป็นข้อดีสำหรับการผลิตซอฟต์แวร์โดยรวม ซึ่งรวมถึงการควบคุมเวอร์ชันและการเข้ากันได้, อัตราความละเอียดของ Dependency, การทำงานอัตโนมัติของ CI/CD และผลิตที่ค่อนข้างง่ายของ BOM (Bills of Material หรือ รายการส่วนประกอบหรือสูตรการผลิต) ทั้งหมดสำหรับแอปพลิเคชันใดๆ ก็ตาม และนี่เป็นเพียงตัวอย่างส่วนหนึ่งเท่านั้น คลังส่วนตัวของบริษัทนั้นเริ่มกลายเป็นส่วนสำคัญที่ขาดไม่ได้ในการบริหารการเปลี่ยนแปลง การพัฒนาใหม่ และทุกสิ่งที่เกี่ยวข้องอย่างรวดเร็ว แต่ก็แน่นอนว่า การบริหารจัดการด้านความปลอดภัยของแหล่งข้อมูลเช่นนี้ต้องอาศัยการทำงานที่ซับซ้อนซึ่งต้องใช้ทรัพยากรบุคคล (ค่าแรงสูง) ตามไปด้วย

Source: Shutterstock

ทีมนักพัฒนาที่ถูกกดดันให้ทำได้ตามเป้านั้นไม่เพียงแต่จะทำพลาด แต่ยังมีแรงจูงใจอยากยิ่งที่จะปล่อยปละละเลยประเด็นด้านการรักษาความปลอดภัยเพื่อลดค่าใช้จ่ายด้วย สิ่งแรกที่มักจะถูกลืมก็คือการตรวจสอบไลบราลี่และฟังก์ชันทั้งหมดอย่างเหมาะสม นี่เป็นปัญหาที่มักทำให้นักพัฒนาและเพื่อนร่วมงานที่โฟกัสด้านความปลอดภัยต้องปะทะกันอยู่เสมอ มีหลายวิธีการและโซลูชันที่พยายามจะผสานรวมแนวทางที่ดีที่สุดในการรักษาความปลอดภัยทางไซเบอร์ให้เข้ากับทุกส่วนของซอฟต์แวร์ซัพพลายเชนและวัฏจักร CI/CD

องค์ประกอบหลักตลอดทั้งกระบวนการพัฒนาและการอัปเดตอื่นๆ ที่ตามมาของทุกแอปพลิเคชันจะต้องได้รับการตรวจสอบว่าผ่านเกณฑ์ด้านการปลอดภัยและการปฏิบัติตาม นั่นหมายถึงปราศจากมัลแวร์หรือข้อกำหนดและเงื่อนไขใดๆ ที่ไม่รองรับ ณ เวลาที่ถูกดาวน์โหลด และมีการตรวจสอบอย่างต่อเนื่องในกรณีที่เกิดพบว่ามี CVE หรือความเสี่ยงใดๆ (หรือมีการเปลี่ยนแปลงข้อกำหนดในการให้สิทธิ์ใช้งาน) สำหรับแอปพลิเคชันที่ซับซ้อน นี่อาจหมายถึงการพิจารณาและบริหารจัดการองค์ประกอบหลายพันรายการ ซึ่งเป็นสิ่งที่เกินกำลังองค์กรส่วนใหญ่ไปมาก

นี่เป็นสถานการณ์ที่คงไม่มีการเปลี่ยนแปลง และแน่นอนว่าคงจะต้องเลวร้ายลงกว่าเดิมเมื่อต้องอาศัยพึ่งพาซอฟต์แวร์มากขึ้น ทุกบริษัทและองค์กรบนโลกนี้ ไม่ว่าจะขนาดใหญ่หรือเล็ก ก็ยังคงเดินหน้าเข้าสู่ระบบดิจิทัลและใช้งานเทคโนโลยีมากขึ้นเรื่อยๆ ดังนั้น จึงคาดเดาได้เลยว่ากิจกรรมภัยร้ายเหล่านี้ก็ย่อมจะต้องเพิ่มขึ้นเป็นเงาตามตัวด้วยเช่นกัน สรุปสั้นๆ ก็คือ ปัญหานั้นเพิ่มมากขึ้นไปพร้อมๆ กับที่การพัฒนาซอฟต์แวร์โอเพ่นซอร์สนั้นจะต้องเร่งสร้างนวัตกรรม ผลิตโซลูชันใหม่ๆ และอัปเดตบริการและแอปทุกแห่งด้วย

Sonatype

ตัวเลขที่ยกมาข้างต้น (แพ็กเกจที่มุ่งร้าย 192,000+ ที่แพร่กระจายอยู่ทั่วไป) ถูกรวบรวมโดยนักวิเคราะห์พฤติกรรมและการสแกนความปลอดภัยอัตโนมัติ Nexus Firewall จาก Sonatype นี่เป็นวิธีที่แผนกพัฒนาขององค์กรจะสามารถปกป้องตัวเองจากความเสี่ยงต่างๆ อาทิจากกรณีเหตุการณ์ Log4J ซึ่งยังส่งผลกระทบอยู่จนถึงทุกวันนี้ โดย SCA (Software Composition Analysis หรือการวิเคราะห์องค์ประกอบซอฟต์แวร์) เป็นกระบวนการที่องค์กรสามารถนำไปใช้เพื่อประเมินความปลอดภัยขององค์ประกอบซอฟต์แวร์ จัดการเวอร์ชัน ช่วยลดปัญหา Dependency และดูแลจัดการประเภทการให้สิทธิ์ใช้งานต่างๆ เป็นไปอย่างถูกต้อง

Nexus Firewall จะทำการ quarantine (และปล่อยออก หลังตรวจสอบแล้ว) ส่วนประกอบ ต่างๆ ที่ดาวน์โหลดมา เพื่อให้บริษัทสามารถควบคุมได้อย่างเต็มที่ว่าอะไรบ้างที่อนุญาตให้เข้าสู่ SDLC (Software Development Lifecycle หรือ วงจรชีวิตการพัฒนาซอฟต์แวร์) สามารถปรับนโยบายให้เบาลงตามความต้องการ และสามารถใส่ระดับการควบคุมโดยอิงตามความนิยม อายุ แหล่งที่มา เวอร์ชัน และสิทธิ์การใช้งานของแพ็กเกจหรือไลบราลี่ได้ (โดยสิทธิ์การใช้งานยังมีประโยชน์ในการช่วยให้แน่ใจว่าจะไม่มีการละเมิดที่อาจกลายเป็นปัญหาทางกฎหมายในภายหลังอีกด้วย)

Source: Shutterstock

นักพัฒนาจะสามารถใช้ได้เฉพาะองค์ประกอบที่ปลอดภัยภายในขอบเขตเวอร์ชันที่กำหนดไว้เท่าน้น ทำให้ตัวเลือกของเวอร์ชันน้อยลงและการละเมิด Dependency ลดลงด้วย เวอร์ชันใหม่จะถูกบล็อกโดยค่าเริ่มต้น จนกว่าจะได้รับการตรวจสอบและปล่อยออกมาโดยคลังของตน ไม่ว่าจะเป็น Nexus Repository หรือ JFrog Artifactory Enterprise

Nexus Firewall นั้นยังรองรับหลายภาษา (Java, JS, Ruby, .NET, Python, Go) จึงเป็นวิธีที่ดีที่สุดในการยกระดับไปสู่เป้าหมายการผสานรวมการรักษาความปลอดภัย การดำเนินงาน และการพัฒนา หรือ DevSecOps ที่ใครๆ ก็มักจะกล่าวถึง หากต้องการข้อมูลเพิ่มเติม ดูราคา และแหล่งข้อมูลที่เฉพาะเจาะจง โปรดนัดหมายการสาธิตกับ Sonatype

Qualys

Qualys เป็นที่รู้จักกันดีในฐานะผู้ให้บริการด้านความปลอดภัยของข้อมูลและการปฏิบัติตามสำหรับโซลูชันการพัฒนา โดยสามารถทำงานร่วมกันได้ดีกับแพลตฟอร์ม CI/CD ที่ใช้กันทั่วไป เช่น Jenkins และ Puppet ทั้งยังสามารถเชื่อมต่อเข้ากับแพลตฟอร์ม SIEM ยอดนิยม เช่น Splunk ได้อีกด้วย

นี่เป็นหนึ่งในแพลตฟอร์มซอฟต์แวร์สำหรับนักพัฒนาโดยเฉพาะรายแรกๆ ที่นำเอาบริการย่อยๆ ที่สร้างขึ้นมาเพื่อใช้กับ Podman และ Docker และเพื่อให้แน่ใจว่านักพัฒนาที่ใช้คอนเทนเนอร์เหล่านั้น (แม้แต่ในสภาพแวดล้อมการทดลองก่อนการผลิตจริง) จะปลอดภัยไร้กังวล มีหลายครั้งที่ภาพลักษณ์ที่เสียหายของ Docker นั้นบ่งบอกถึงแนวคิดเชิงอนุรักษ์นิยมของบริษัท แต่สำหรับผู้ใช้ที่ชื่นชอบ แพลตฟอร์มนี้ช่วยให้สามารถตรวจสอบยืนยันพฤติกรรมของคอนเทนเนอร์กับการนำไปใช้งานในชีวิตจริงเพื่อแจ้งเตือนความผิดปกติที่อาจบ่งบอกว่ามีสิ่งอันตรายแปลกปลอมแฝงอยู่

แพลตฟอร์ม Qualys สามารถสแกนแอสเซ็ตทั้งหมดที่มีได้ ตั้งแต่ที่เก็บบนคลาวด์ (ซึ่งมีการเชื่อมต่อในตัวไปยังบริการปรับขยายขนาดยอดนิยม) ไปจนถึงปลายทางของแต่ละบุคคลที่ทำงานโดยนักพัฒนาคนเดียว

อ่านข้อมูลเพิ่มเติมที่นี่เกี่ยวกับโซลูชันการรักษาความปลอดภัย DevOps โดย Qualys

Micro Focus

แอปส่วนใหญ่นั้นใช้ซอฟต์แวร์โอเพ่นซอร์สบุคคลที่สามซึ่งถูกสร้างขึ้นจากเครื่องมือต่างๆ ที่อาจจะผสานอยู่ในกระบวนการธุรกิจมานานมากแล้ว

Micro Focus Fortify ช่วยมอบความสามารถให้บริษัทต่างๆ สามารถย้อนกลับผ่านแต่ละขั้นตอนของ CI/CD ที่มีอยู่เดิมเพื่อให้วิศวกรสามารถตรวจสอบความปลอดภัยในแต่ละขั้นตอนของ SDLC ได้ดีขึ้น

ซอฟต์แวร์นี้ช่วยให้การพัฒนาแอปพลิเคชันไม่ต้องหยุดชะงักในช่วงเวลาสำคัญเพื่อตรวจสอบความปลอดภัย แต่จะเป็นกระบวนการแบบต่อเนื่องซึ่งสร้างมูลค่าในแง่ของระยะเวลาไปสู่การผลิตและ ROI ของการลงทุนในแอปพลิเคชันใหม่

บริษัทมุ่งเน้นไปที่สาม กลุ่มหลักด้านการรักษาความปลอดภัย หรือที่เรียกว่าสามองค์ประกอบที่จำเป็นต้องให้ความสำคัญเพื่อให้แน่ใจว่า BOM จะเป็นระเบียบเรียบร้อยมากที่สุด นั่นก็คือ พนักงาน กระบวนการ และเทคโนโลยี

ในขณะที่แต่ละแผนกนั้นต้องเผชิญแรงกดดันที่มากขึ้นในการออกอัปเดตใหม่ๆ และเพิ่มฟีเจอร์ รวมถึงวางตลาดแอปพลิเคชันและบริการใหม่ๆ อยู่เสมอ Fortify สามารถช่วยให้มั่นใจได้ว่าเวิร์กโฟลว์การทำงานจะเป็นอย่างรวดเร็วแต่ปลอดภัย

คลิกที่นี่เพื่อดูเพิ่มเติมว่า Micro Focus Fortify สามารถช่วยให้องค์กรต่างๆ รักษาความปลอดภัยซอฟต์แวร์ซัพพลายเชนได้อย่างไร

The post หลีกเลี่ยงองค์ประกอบที่เป็นพิษต่อห่วงโซ่อุปทานโอเพ่นซอร์ส appeared first on Tech Wire Asia.

不可否認的是，公開的開發者資源資料庫正遭駭客竊取，他們已完全意識到一個簡單的誤植域名就有可能會將他們改寫的程式碼傳播到全球數千個專案之中。但大多數惡意供應鏈的惡意軟體案例都未被上報 – 可能是因為罄竹難書，開放原始碼軟體供應鏈網路安全供應商Sonatype在一次主動掃描時發現，光是整個npm生態系，就有102,930個惡意或潛在的惡意程式碼案例。一旦整合到開發管道中，被改寫的應用程式將隨即進入產品品質測試、測試、甚至是生產階段。接著，他們就能夠破壞雲端認證、劫持加密貨幣挖礦的處理週期、竊取公司的智慧資產，以及令人心煩的一連串惡意軟體攻擊事件。

因Linux核心初版的部署即引發專有UNIX的垂死掙扎，開發人員社群為大眾利益著想，已發布相關的資源與程式碼。雖然開放原始碼軟體的意識形態將延續下去，因為它對所有開發人員與軟體都具有壓倒性的優勢，但提供這類優勢的手段正在被犯罪分子破壞。這是相當不樂見的人為行動之一，也是無法避免的，除非每項專案皆是從頭編寫，且無須參考公開資料庫、架構與程式碼。

各組織已透過建立自家資料庫，僅能在內部使用包含「已批准」的元素，或至少確保所有進入CI/CD管道軟體套件的真實性，來彌補許多安全性與品質管控問題。控管通常能為軟體的生產帶來優勢，包括版本管控、相容性、依賴解析、CI/CD自動化，以及為任何應用程式（相對）簡單地生產整體BOM（物料清單），以上只是列舉幾個例子。本地資料庫迅速地成為變更管理、新開發與兩者中間所有程序任何交付管道不可或缺的一項工具，但這項資源的安全性維護必定是一項相當繁瑣的工作，亦需消耗(成本極高的)資源。

Source: Shutterstock

在業績達標壓力山大的迫使之下，DevOps團隊不僅容易出錯，且極有可能會為了降低成本而忽視安全性相關疑慮，首先被拋諸腦後的可能是對每個資料庫或功能的適當審查。這是使得開發人員與他們聚焦於安全性議題同事們之所以出現對立立場最根本的原因之一，有許多方法與解決方案試圖將網路安全最佳實踐導入軟體供應鏈與CI/CD生命週期各階段。

任何應用程式的核心元素在其整體開發與後續更新流程中都必須進行安全性與認證合規性檢查。這代表著在下載時沒有惡意軟體或不合乎條款及細則的情況出現，並在漏洞披露或其他敏感性議題變得顯而易見時（或認證條款變更時）不斷反覆檢查。在一個極為複雜的應用程式中，這可能代表著需要觀察與控管數千個的組件，這顯然已超出了大多數組織的負荷。

這樣的情況是無法改變的，事實上，隨著對軟體依賴程度的日益增加，這樣的情況還可能會跟著惡化。全球每間公司與組織，無論規模大小，都正朝著數位化與部署更多技術邁進。因此，可以肯定的是，惡意攻擊事件也將隨之增加。簡而言之，在問題日益加劇的同時，開放原始碼軟體的開發亦需加速創新，擬定全新的解決方案，並更新全球各地的服務與應用程式。

Sonatype

上述引用的數字（192,000多個惡意軟體套件）是透過Sonatype Nexus防火牆執行的行為分析與自動安全掃描整理出的數據。這是一種方法，組織的開發功能得以協助他們保護自身避免遭受Log4J事件所呈現漏洞類型的影響 – 該事件的影響仍持續加劇。 透過SCA（軟體組成分析）程序，組織能夠評估自身軟體組成的安全性、管控版本、確保減少依賴性問題的存在，並在眾多認證類型中維持準確性。

Nexus防火牆能夠隔離（並於審查後釋出）任何下載的組件，讓企業得以完全管控允許進入SDLC（軟體開發生命週期）的內容。政策亦得以根據需求進行調整，包括根據套件或資料庫的流行程度、年代、來源、版本與認證進行管控。 (後者還擁有一個附加的優勢，也就是確保沒有任何後續可能會引起法律問題違規行為的發生。）

Source: Shutterstock

開發人員僅能使用設定版本範圍內的安全組件，進而降低版本選擇問題，亦減少了對破壞性的依賴程度。在預設情況下，新的版本將被封鎖，直至它們再經審查後並釋出至本地資料庫之中，無論是Nexus Repository或是JFrog Artifactory Enterprise。

因為支援多種程式語言（Java、JS、Ruby、.NET、Python、Go），Nexus防火牆是加強實現人們經常提起整合安全性、操作與開發目標的絕佳途徑： DevSecOps。欲瞭解更多相關資訊、探索價格以及以社區為重心的相關資源，請造訪Sonatype預約展示。

Qualys

Qualys是著名的資訊安全與合規開發解決方案供應商，完美無縫地適用於Jenkins及Puppet等常見的CI/CD平台，此外，還能在Splunk等熱門SIEM平台中安裝外掛。

這是首批以開發者為中心設計的軟體平台之一，採用Podman與Docker為主建構出的微型服務，並確保使用容器進行開發（即使在實驗性的預備生產環境之中）是安全且可靠的。Docker鏡像損壞的眾多案例證明該企業在這領域的保守態度，對滿懷感謝之意使用者而言，這樣的作法能夠將預期的容器行為與實際上的部署進行交叉驗證，以便標記出可能出現存在不良反應的異常情況。

Qualys平台能夠掃描所有可用的資產，從雲端資料庫（內建設定連接至熱門超大規模服務平台）到由單一開發人員操作的個別端點。

欲瞭解與Qualys DevOps安全解決方案更多的相關資訊，請閱讀此篇文章。

Micro Focus

絕大多數使用某種第三方開放原始碼軟體的應用程式都是運用現有工具鏈建立的，這些工具鏈可能長期嵌入業務流程之中。

Micro Focus Fortify為企業提供了透過現有的CI/CD堆棧向後移植的能力，以便在SDLC的各個階段建構出更全面的安全性。

它的軟體有效清除了在關鍵時刻暫停應用程式開發以便進行安全掃描的需求 – 流程轉變為連續且不中斷的，生產效率進而大幅提升，也就帶動了新應用程式的投資報酬率。

該公司專注於影響安全性的三大核心理念，或許最合適的形容詞是需特別注意的三大要素，來確保獲取潔淨的BOM：人、流程與技術。

隨著各部門面臨推動更新、增加功能，以及將全新的應用程式與服務上市等各項目標的壓力日益加劇，Fortify在能夠確保迅速工作流程的同時，又能維持安全性。

點擊此處，即可瞭解更多Micro Focus Fortify協助企業維持軟體供應鏈安全性的方法。

The post 避免毒害開源供應鏈的因素 appeared first on Tech Wire Asia.

단순한 타이포스쿼트가 손상된 코드를 전 세계 수천 개의 프로젝트에 배포할 수 있다는 것을 잘 알고 있는 악의적 행위자들에 의해 일반적인 개발자 리소스와 라이브러리가 손상되고 있다는 사실은 부인할 수 없습니다. 하지만 대부분의 악의적인 공급망 멀웨어 인스턴스는 보고되지 않습니다. 그 이유는 그 수가 많기 때문일 가능성이 높습니다. OSS 공급망 사이버 보안 공급업체인 Sonatype의 적극적인 스캔을 통해 npm 생태계 전체에서 102,930개의 악성 또는 잠재적 악성 코드 인스턴스가 발견되었습니다. 일단 개발 파이프라인에 통합되면 손상된 애플리케이션은 QA, 테스트 또는 프로덕션 단계로 진입합니다. 그런 다음 클라우드 자격 증명을 손상시키고, 암호화폐 채굴을 위한 프로세서 사이클을 빼내고, 기업의 IP를 유출하고, 일반적으로 불쾌한 멀웨어 활동인 스모가스보드를 유발할 수 있습니다.

리눅스 커널의 초기 버전 배포로 독점적 UNIX의 마지막 변화가 촉발된 이후 개발자 커뮤니티는 모두를 위한 리소스과 코드를 게시했습니다. 또한 OSS(오픈 소스 소프트웨어)의 이념은 모든 개발자와 소프트웨어에 대한 압도적인 이점 때문에 지속될 것이지만, 그러한 혜택을 제공하는 수단은 범죄에 의해 훼손되고 있습니다. 그것은 인간 행동의 어두운 측면이며, 모든 프로젝트가 공통 라이브러리, 프레임워크 및 코드를 참조하지 않고 처음부터 작성되지 않는 한 피할 수 없는 일입니다.

조직은 내부용으로 ‘승인’된 요소만 포함하는 자체 저장소를 만들거나 최소한 CI/CD 파이프라인으로 들어오는 모든 패키지의 진실성을 보장함으로써 많은 보안 및 품질 관리 문제를 해결했습니다. 제어는 버전 제어 및 호환성, 종속성 해결, CI/CD 자동화, 그리고 모든 애플리케이션에 대한 전체 BOM(Bill of Materials, 자재 명세서)의 상대적으로 간단한 프로덕션을 포함하여 일반적으로 소프트웨어 프로덕션에 이점을 제공합니다. 로컬 저장소는 변경 관리, 새로운 개발 및 그 사이의 모든 단계를 위한 딜리버리 파이프라인에 빠르게 통합됩니다. 하지만 물론 이러한 리소스의 보안 유지는 고비용의 리소스를 소비하는 복잡한 작업입니다.

Source: Shutterstock

목표 달성의 압력을 받는 데브옵스(DevOps) 팀은 실수를 저지를 뿐만 아니라 간접비 절감을 위해 보안 문제를 회피하려는 유혹을 받게 됩니다. 가장 먼저 제외하는 작업은 아마도 모든 라이브러리나 기능에 대한 적절한 조사일 것입니다. 이는 전통적으로 개발자와 보안에 중점을 둔 동료들이 격렬하게 논쟁하는 영역입니다. 소프트웨어 공급망의 모든 부분과 CI/CD 수명 주기에 걸쳐 사이버 보안 모범 사례를 적용하려는 많은 방법과 솔루션이 있습니다.

개발 및 후속 업데이트 전반에 걸쳐 모든 애플리케이션의 핵심 요소는 안전성 및 라이선스 준수 여부에 대한 확인입니다. 즉, 다운로드 시점에서 멀웨어나 호환되지 않는 T와 C가 없으며 CVE 또는 기타 취약성이 명백해질 때(또는 라이선스 조건이 변경될 때) 지속적으로 재검사해야 합니다. 복잡한 애플리케이션에서 이는 수천 개의 구성요소를 관찰하고 관리하는 것을 의미할 수 있으며, 이는 대부분의 조직의 능력을 넘어서는 작업입니다.

이 상황은 소프트웨어에 대한 의존도가 증가함에 따라 변화하지 않고 실제로 악화할 가능성이 높습니다. 세계의 모든 기업과 조직은 규모를 막론하고 계속해서 더 많은 기술을 디지털화하고 배포하고 있습니다. 따라서, 악질 행위자들의 활동도 보조를 맞추어 증가할 것이라고 가정해도 무방합니다. 간단히 말해서 오픈 소스 소프트웨어 개발이 혁신을 가속화하고, 새로운 솔루션을 생산하며, 모든 곳에서 서비스와 앱을 업데이트해야 하는 동시에 문제는 커지고 있는 것입니다.

Sonatype

위에 인용한 수치(192,000개 이상의 악성 패키지)는 Sonatype의 Nexus Firewall에서 실행하는 동작 분석 및 자동 보안 스캔을 통해 수집되었습니다. 이는 조직의 개발 기능을 통해 Log4J 사건으로 대표되는 취약성 유형으로부터 스스로를 보호하는 데 도움이 되는 방법이며, 그 영향은 지속됩니다. SCA(Software Composition Analysis, 소프트웨어 구성 분석)는 조직이 소프트웨어 구성 요소의 보안을 평가하고, 버전을 관리하며, 종속성 문제를 최소화하고, 많은 라이선스 유형의 올바른 면을 유지할 수 있는 프로세스입니다.

Nexus Firewall은 다운로드된 모든 구성 요소를 검역(검토 후 릴리스)하여 기업이 SDLC(소프트웨어 개발 수명 주기)에 허용되는 내용을 완벽하게 제어할 수 있도록 합니다. 정책은 필요에 따라 완화할 수 있으며 패키지 또는 라이브러리 사용 빈도, 사용 기간, 소스, 버전 및 라이선스에 기반한 제어 수준을 포함할 수 있습니다. 후자는 법적 우려를 제기할 수 있는 위반이 발생하지 않도록 하는 추가 이점이 있습니다.

Source: Shutterstock

개발자는 설정된 버전 범위 내에서만 보안된 구성 요소를 사용할 수 있으므로 버전 선택이 낮아지고 주요 종속성을 낮출 수 있습니다. Nexus Repository 또는 JFrog Artifactory Enterprise와 같은 새 버전을 검사하여 로컬 레포로 릴리스할 수 있을 때까지 기본적으로 차단됩니다.

다양한 언어(Java, JS, Ruby, .NET, Python, Go)를 지원하는 Nexus Firewall은 보안, 운영 및 개발 통합, 즉 DevSecOps라는 자주 인용되는 목표에 다가가는 가장 좋은 방법입니다. 더 자세히 알아보고, 가격 및 커뮤니티에 초점을 맞춘 리소스에 대해 알아보려면 Sonatype에서 데모를 예약하십시오.

Qualys

Qualys는 개발 솔루션의 정보 보안 및 컴플라이언스 제공업체로 명성이 높습니다. Jenkins 및 Puppet과 같은 일반적인 CI/CD 플랫폼과 깔끔하게 연결되며 Splunk와 같은 인기 SIEM 플랫폼에도 연결됩니다..

Qualys는 Podman과 Docker를 중심으로 구축된 마이크로서비스의 등장과 컨테이너를 사용한 개발(실험적, 사전 프로덕션 환경 포함)의 안전성을 보장한 최초의 개발자 중심 소프트웨어 플랫폼 중 하나였습니다. 그러한 점에서 Docker 이미지가 손상된 여러 사례는 회사의 보수성을 입증했습니다. 소중한 사용자들을 위해, 예상되는 컨테이너 동작과 실제 배포를 교차 점검하여 악질 행위자의 존재를 암시할 수 있는 이상 징후를 표시할 수 있었습니다.

Qualys 플랫폼은 클라우드 저장소(인기 있는 하이퍼스케일러 서비스에 대한 기본 제공 연결이 있는 곳)에서 단일 개발자가 운영하는 개별 엔드포인트에 이르기까지 사용 가능한 모든 리소스를 스캔할 수 있습니다.

Qualys DevOps 보안 솔루션에 대한 자세한 내용은 여기를 참조하십시오.

Micro Focus

일종의 서드 파티 오픈 소스 소프트웨어를 사용하는 대부분의 앱은 비즈니스 프로세스에 오랫동안 포함될 수 있는 기존 툴링 체인으로 구축되었을 것입니다.

Micro Focus Fortify는 기존 CI/CD 스택을 통해 백포트하여 SDLC의 각 단계에서 더 나은 보안을 역설계할 수 있는 기능을 제공합니다.

이 소프트웨어를 사용하면 보안 스캔을 위해 주요 지점에서 애플리케이션 개발을 일시 중지할 필요가 없습니다. 프로세스가 지속적으로 진행되어 프로덕션 시간 측면에서 가치를 발생시켜 새로운 애플리케이션에 대한 ROI를 기대할 수 있습니다.

이 회사의 초점은 보안의 세 가지 축에 맞춰져 있으며, 깔끔한 BOM을 보장하기 위해 주의가 필요한 세 가지 요소, 즉 인력, 프로세스 및 기술로 가장 잘 설명할 수 있습니다.

부서들이 업데이트를 추진하고 기능을 추가해야 할 뿐만 아니라 새로운 애플리케이션과 서비스를 시장에 출시해야 한다는 압박을 받고 상황에서, Fortify는 안전하게 유지되는 신속한 워크플로를 보장할 수 있습니다.

Micro Focus Fortify가 조직의 소프트웨어 공급망 보안을 어떻게 지원하는지 자세히 알아보려면 여기를 클릭하십시오.

The post 오픈 소스 공급망을 오염시키는 요소 피하기 appeared first on Tech Wire Asia.

It’s undeniable that common developer resources and libraries are being compromised by bad actors who are fully aware that a simple typo-squat can distribute their corrupted code to thousands of projects across the globe. But most malicious supply chain malware instances go unreported – more than likely because they are numerous. An active scan by OSS supply chain cybersecurity vendor Sonatype found 102,930 malicious or potentially malicious instances of code across the npm eco-system. Once integrated into development pipelines, corrupted applications enter QA, testing, or even production stages. Then they can compromise cloud credentials, hijack processor cycles for cryptocurrency mining, exfiltrate companies’ IP, and the usual unpleasant smorgasbord of malware activities.

The developer community has posted its resources and code for the good of all since the final throes of proprietary UNIX were triggered by the deployment of the early versions of the Linux kernel. And while the ideology of OSS (open source software) will endure because of its overwhelming advantages for all developers and software, the means of delivering such benefits are being compromised by criminal elements. It’s an unfortunate side of human behavior and one that’s unavoidable unless every project is written from scratch without reference to common libraries, frameworks, and code.

Organizations have remedied many security and quality control issues by creating their own repositories containing only “approved” elements for internal use – or at least ensuring the veracity of all packages coming into their CI/CD pipeline. Control brings advantages to software production in general, including version control and compatibility, dependency resolution, CI/CD automation, and the (relatively) simple production of entire BOMs (bills of materials) for any application, to name a few examples. Local repositories quickly become integral to any delivery pipeline for change management, new development, and everything in between. But of course, the security maintenance of such a resource is a complex undertaking that consumes (highly paid) resources.

Source: Shutterstock

DevOps teams under pressure to hit targets not only make mistakes but will be tempted to park security concerns for the sake of lower overheads. First to be forgotten is likely the proper vetting of every library or function. That’s a story that has traditionally put developers and their security-focused colleagues at loggerheads. There are many methods and solutions that attempt to bake in cybersecurity best practices to all parts of the software supply chain and the CI/CD lifecycle.

The core elements of any application throughout its development and subsequent updates must be checked for safety and license compliance. That means free of malware or incompatible Ts & Cs at the point they’re downloaded and constant re-examining as CVEs or other susceptibilities become apparent (or license terms change). In a complex application, that can mean observing and managing many thousands of components, an undertaking clearly beyond most organizations.

It’s a situation that won’t change and, indeed, will likely worsen as the dependence on software grows. Every company and organization in the world, large and small, is continuing to digitize and deploy more technology. Therefore, it’s safe to assume that bad actors’ activities will likewise increase in step. In short, the problem is growing at the same time that open source software development needs to accelerate innovation, produce new solutions and update services & apps everywhere.

Sonatype

The figure quoted above (192,000+ malicious packages in the wild) was collated by behavioral analysis and automated security scans run by the Nexus Firewall from Sonatype. It’s a way by which organizations’ development functions can help protect themselves from the type of vulnerabilities epitomized by the Log4J incident – the effects of which continue. SCA (software composition analysis) is the process by which organizations can assess the security of their software components, manage versioning, ensure fewer dependency issues and keep on the right side of the many license types.

Nexus Firewall quarantines (and releases, after vetting) any downloaded component, giving companies full control over what is permitted into their SDLC (software development lifecycle). Policy can be attenuated according to needs and can include degrees of control based on package or library popularity, age, source, version, and license. (The latter has the additional advantage of ensuring no violations that might raise legal concerns somewhere down the line.)

Source: Shutterstock

Developers can only use secure components inside a set version range, lowering version choices and reducing breaking dependencies. New versions are blocked by default until they can be examined and released into the local repo, be that Nexus Repository or JFrog Artifactory Enterprise.

With multi-language support (Java, JS, Ruby, .NET, Python, Go), the Nexus Firewall is the best way to enhance progress towards the oft-quoted goal of security, operations, and development integration: DevSecOps. To find out more, discover pricing and community-focused resources, book a demo from Sonatype.

Qualys

Qualys is renowned as a provider of information security and compliance in development solutions. It interfaces neatly with common CI/CD platforms like Jenkins and Puppet, plus it will also plug into popular SIEM platforms like Splunk.

It was one of the first developer-focused software platforms to take the emergence of microservices built around Podman and Docker and ensure that development using containers (even in experimental, pre-production environments) was safe and secure. Multiple instances of corrupted Docker images proved the company’s conservatism in this regard. For its grateful users, it was able to cross-check expected container behaviors with real-world deployments to flag anomalies that might suggest the presence of bad actors.

The Qualys platform can scan all available assets, from cloud repositories (where there are built-in connections to popular hyperscalers’ services) to individual endpoints operated by single developers.

Read here for more information on Qualys DevOps security solutions.

Micro Focus

The great majority of apps using some sort of third-party open-source software will have been built with an existing chain of tooling that may be long-bedded into business processes.

Micro Focus Fortify offers companies the ability to backport through the extant CI/CD stack to backwards engineer better security at each stage of the SDLC.

Its software removes the need for application development to be paused at key points to be security scanned – the process is continuous, bringing value in terms of time-to-production and therefore ROI on investment in a new application.

The company’s focus is on three pillars of security, perhaps best described as the three elements that need attention to ensure a clean BOM: people, process and technology.

With departments under increased pressure to push updates and add features, as well as to bring new applications and services to market, Fortify can ensure speedy workflows that remain safe.

Click here to learn more about how Micro Focus Fortify can help organizations secure their software supply chain.

The post Avoiding The Elements That Poison the Open Source Supply Chain appeared first on Tech Wire Asia.