美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下:

  1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。

  2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。

  3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。

  搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。

相關連結
你可能會想參加
※ 美國國家安全局發布「軟體記憶體安全須知」, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=8956&no=64&tp=1 (最後瀏覽日:2026/05/27)
引註此篇文章
你可能還會想看
歐盟執委會提出確保其境內數位內容跨境攜帶性之法律案

  隨著行動載具普及和網路寬頻發展,利用行動電話收看線上訂閱數位內容,如電影、音樂或運動比賽直播等已成風氣。消費者更希望無論身在何地都能觀賞線上數位內容。在此背景下,歐執會於2015/12/09正式公布〈線上數位內容之跨境攜帶性法律案(Regulation on ensuring the cross-border portability of on line content services in the internal market)〉。其目的是為使居住歐盟境內之消費者能自由攜帶其所訂閱之數位內容進行移動。另一方面在打破國界限制之障礙後,為了確保數位內容之跨境攜帶性不至於侵害視聽產業之著作權,同時兼顧基於特殊目的(教育、研究等)而使用跨境線上內容之行為,在網路數位內容之可接近性與創作人權利保障間取得平衡。   網路數位內容服務提供業者之行為規則,涉及歐盟著作權如何因應數位時代之挑戰。在歐執會之〈歐盟單一數位內容市場策略〉報告中指出,為提高數位內容之可接近性,歐盟需提高其著作權法制之現代化程度,而令數位內容有跨境攜帶性將是歐盟邁向單一數位內容市場先跨出的第一步。歐執會今後除將於2016年陸續提出多項有關著作權之現代化法案化,並且希望網路數位內容之跨境攜帶性法律案能於2017年正式實施。

歐盟執委會宣布「軟體開源授權及複用」決定

  歐盟執委會於2021年12月8日宣布「軟體開源授權及複用」決定(COMMISSION DECISION on the open source licensing and reuse of Commission software)。本決定規範執委會軟體之開源授權條件與複用方式,其軟體開源授權流程如下: 一、執委會依本決定(下同)第5條授予其軟體的開源授權證應為歐盟公共授權(the European Union Public Licence, EUPL),除因(1)適用第三方軟體的互惠條款,而強制使用其他開源授權證,或替代開源授權證比EUPL更便於人民使用該軟體;(2)適用第三方軟體之授權條款,存在多個開源授權標準(不含EUPL),則應優先選擇授予最廣泛權利的開源授權。 二、透過第8條對智慧財產權進行核實,包括:(1)軟體識別(2)對軟體的智慧財產權進行驗證;及(3)安全驗證。 三、依第6條規定將所有開源軟體置於資料庫,供公民、公司或其他公共服務有潛在利益者取得。   另外,依第四條規定,本規則不適用於以下情形:(1)因第三方智慧財產權問題,無法允許複用的軟體;(2)該原始碼之發布或共享,對執委會、其他歐洲機構或團體的資訊系統或資料庫安全構成實質或潛在風險;(3)因法律規定、契約義務或性質,其內容須被視為機密之軟體;(4)依(EC)1049/2001第4條所列之情形,包含但不限於:因公共利益、國家安全、隱私保護、商業利益、訴訟或審計之利益等,該軟體須被排除,或只能由特定之一方取得或管理;(5)委託由執委會進行研究產生之軟體,若公開將干擾臨時研究結果之驗證或構成拒絕註冊有利於執委會之智慧財產權的理由。

歐盟通過最新基因改造生物指令,並堅持產品標示

  歐洲議會於今(2015)年1月13日通過最新決議(10972/3/2014 – C8-0145/2014)「修正2001/18/EC歐洲議會與理事會指令,關於會員國限制或禁止境內進行基因改造生物耕作之可能性」(Directive of the European Parliament and of the Council amending Directive 2001/18/EC as regards the possibility for the Member States to restrict or prohibit the cultivation of genetically modified organisms (GMOs) in their territory),允許會員國自行決定限制或全面禁止GMO於其國境內耕作,以排除GMO產品。此變革在於,原歐洲議會與理事會2001/18/EC指令、歐洲議會與理事會第1829/2003號決議,允許全歐盟境內使用GMO種子、植物繁殖材料進行耕作;而一旦歐盟許可後,會員國除非有符合歐盟法規定例外,否則不得於其境內再為禁止、限制或障礙。   基於歐洲聯盟「輔助原則」(Principle of Subsidiarity),並考量GMO耕作議題與國家、地區及在地區域土地利用、農業結構與生態維持之關聯度高,其與歐盟GMO產品上市之授權進入內部市場仍有所不同,因此新通過之指令,提供會員國更多裁量彈性,在不影響「歐盟食品安全局」(European Food Safety Authority)之GMO風險評估結果下,會員國在歐盟允許GMO產品上市後,得自行決定是否允許GMO作物於其境內耕作。   由於歐盟與美國之「跨大西洋貿易與投資伙伴協定」(Transatlantic Trade and Investment Partnership),及歐盟與加拿大雙邊自由貿易協定(Comprehensive Economic and Trade Agreement),使歐洲民眾對於GMO產品進入歐洲產生恐慌,且在年初即受到消費者保護團體及農民聯盟之嚴厲批評,因此在前述新通過指令之立場下,歐盟農業委員會委員Phil Hogan在今年1月15日國際綠色週(International Green Week)強調,基於消費者保護,歐盟堅持產品中含有基因改造生物者,皆需進行標示。僅透過條碼掃描才能得知是否為GMO產品,此美國建議之方式仍不符合歐盟規定。

世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧

世界衛生組織(World Health Organization, WHO)於2023年10月19日發布「人工智慧於健康領域之監管考量因素」(Regulatory considerations on artificial intelligence for health)文件,旨在協助各國有效監管健康領域之人工智慧,發揮其潛力同時最大限度地降低風險。本文件以下列六個領域概述健康人工智慧之監管考量因素: (1)文件化與透明度(Documentation and transparency) 開發者應預先規範(pre-specifying)以及明確記錄人工智慧系統(以下簡稱AI系統)之預期醫療目的與開發過程,如AI系統所欲解決之問題,以及資料集之選擇與利用、參考標準、參數、指標、於各開發階段與原始計畫之偏離及更新等事項,並建議以基於風險之方法(Risk-based approach),根據重要性之比例決定文件化之程度、以及AI系統之開發與確效紀錄之保持。 (2)風險管理與AI系統開發生命週期方法(Risk management and AI systems development lifecycle approaches) 開發者應在AI系統生命之所有階段,考慮整體產品生命週期方法(total product lifecycle approach),包括上市前開發管理、上市後監督與變更管理。此外,須考慮採用風險管理方法(risk management approach)來解決與AI系統相關之風險,如網路安全威脅與漏洞(vulnerabilities)、擬合不足(underfitting)、演算法偏差等。 (3)預期用途、分析及臨床確效(Intended use, and analytical and clinical validation) 開發者應考慮提供AI系統預期用途之透明化紀錄,將用於建構AI系統之訓練資料集組成(training dataset composition)之詳細資訊(包括大小、設定與族群、輸入與輸出資料及人口組成等)提供給使用者。此外,可考慮透過一獨立資料集(independent dataset)之外部分析確效(external analytical validation),展示訓練與測試資料以外之效能,並考慮將風險作為臨床確效之分級要求。最後,於AI系統之上市後監督與市場監督階段,可考慮進行一段期間密集之部署後監督(post-deployment monitoring)。 (4)資料品質(Data quality) 開發者應確認可用資料(available data)之品質,是否已足以支援AI系統之開發,且開發者應對AI系統進行嚴格之預發布評估(pre-release evaluations),以確保其不會放大訓練資料、演算法或系統設計其他元素中之偏差與錯誤等問題,且利害關係人還應考慮減輕與健康照護資料有關之品質問題與風險,並繼續努力創建資料生態系統,以促進優質資料來源之共享。 (5)隱私與資料保護(Privacy and data protection) 開發者於AI系統之設計與部署過程中,應考慮隱私與資料保護問題,並留意不同法規之適用範圍及差異,且於開發過程之早期,開發者即應充分瞭解適用之資料保護法規與隱私法規,並應確保開發過程符合或超過相關法規要求。 (6)參與及協作(Engagement and collaboration) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。

TOP