美國國家安全局發布「軟體記憶體安全須知」
美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。
鄭岱宜
法律研究員 編譯整理
NSA Releases Guidance on How to Protect Against Software Memory Safety Issues, National Security Agency, https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/ (last visited Jan. 30, 2023).
阮韻蒨，〈美國公布實施零信任架構相關資安實務指引〉，科技法律研究所，2022/09，https://stli.iii.org.tw/article-detail.aspx?tp=1&d=8885&no=64（最後瀏覽日︰2023/01/30）。
歐洲法院(European Court of Justice)於2011年9月6日作出一項指標性的判決，係針對蜂蜜或食物補充品(Food Supplement)中，若其花粉成分受到基因改造作物之污染，則無論該污染是有意或無意所造成者，未經審核前均不得任意販售。據此，蜂蜜或食物補充品的生產者得就因不得販售所產生之損失向污染源或政府求償。 該案原為德國的養蜂人認為其生產之蜂蜜中的花粉受到鄰近距離五百公尺的基因改造農作物試驗之污染，而該試驗即為巴伐利亞政府所核准之基因改造農作物試驗(1998年EU核准的MON 801 maize)，故而對巴伐利亞政府提出求償。原德國法院在不能確定蜂蜜是否涵蓋在基因改造規範的情況下，轉而尋求歐洲法院的判決。 該判決等於是挑戰歐盟現有的對於傳統作物及基因改造作物共存的政策與法規(GMO, Co-Existence)，歐盟就該共存的門檻標準設定在0.9%，若產品含基因改造成分0.9%以上，需標示為基因改造產品，惟標示為基因改造食品對於傳統農作物之種植可能帶來銷售上的不利。而在共存門檻之下，含有基因改造成分的傳統農作物還是有可能因含有基因改造的成分而影響銷售並帶來損失；又因在共存門檻之下，作物含有基因改造成分是無法向政府或是來源求償的。另一方面，該判決亦影響出口蜂蜜至歐盟的國家，如大量生產蜂蜜且核准種植基因改造作物的阿根廷等國家。 對於基因改造食品採取保守態度的歐盟，近年來有意將是否禁止基因改造農作物以及共存門檻的比率下放給成員國自行決定，在成員國間形成兩極化的意見，而該項提案目前雖已經歐盟議會背書，但尚未由各成員國通過。這樣的判決令共存門檻的制度形同具文，且可能會使更多國家傾向禁止種植基因改造農作物，而不利於基因改造科技的研發。
手機軟體（APP）辨識來電號碼之法律問題手機軟體（APP）辨識來電號碼之法律問題 科技法律研究所 102年03月25日 壹、事件摘要 我國自2005年開始推展行動電話「號碼可攜」服務，允許使用者將行動電話號碼申請移轉至另一業者。當號碼進行移轉時，為降低通話路由資訊傳遞之延遲、避免業者間轉換作業之延宕，通傳會指導各業者共同建立集中式資料庫，整合業者號碼管理資源，增進號碼可攜服務之效率。 日前有某非屬電信事業之業者，設計一款應用軟體，提供智慧型手機使用者下載、安裝後，可自行上傳通訊錄內之電話號碼，並透過電信事業之「號碼可攜集中式資料庫」，確認並辨識通訊錄內電話號碼所屬電信業者，將資訊回傳於使用者之智慧型手機。由於電話號碼屬於使用者個人資料之一環，本文以下分析「非電信事業與電信事業合作，於號碼可攜目的外，對資料庫內之資料進行蒐集、處理與利用是否違反個資法」之疑義。 貳、重點說明 「號碼可攜集中式資料庫」之設立主要目的在使不同業者間能準確的完成通訊的連接。然而，通傳會於96年10月亦有要求各電信業者設置查詢系統，提供用戶查詢欲致電之受話方是否係屬同家業者，進而協助用戶瞭解可能之通訊資費計算。換言之，通傳會認為辨識電信號碼屬於網內/外，屬於消費者規劃、理解其電信資費之權益。而目前亦有手機軟體可輔助消費者查詢相關資訊。 那麼，可否允許消費者進一步查詢致電對象所屬的業者呢？是否違反個人資料保護法的規定呢？ 如前所述，通傳會認為使消費者瞭解電信號碼屬於網內/外，有助於資費理解之權益。我們更進一步說，允許查詢號碼所屬門號，不僅消費者可知悉資費之數額計算以決定是否致電，尚可決定是否使用相同電信業者之服務來打電話。我國行動電話普及率早已超過120%，有相當比例之消費者擁有二個以上之門號，若可揭露致電號碼所屬電信業者，使消費者可刻意選擇以網內門號致電，無疑具有相當實益。因此我們認為電信業者提供消費者以手機軟體查詢門號所屬業者，並不違反個資法上針對電信服務規範之「特定目的」（第133項：經營電信業務與電信加值網路業務）。一般的行動電話用戶，可透過電信業者查詢其所致電對象之門號所屬業者，則居於輔助地位的APP軟體，與用戶直接向業者查詢相比，實則無任何不同，應視為用戶之合理行為。 參、事件評析 個資法修正後，對於個人資料之保護更加的完善，但科技之發展使得個人資料之利用呈現多樣性，難以釐清某些利用行為是好是壞，然而本文基於鼓勵科技發展以及創新研發的立場，當面對某些個資利用情狀產生疑義時，應加以釐清其運用之情狀，避免在情境不明時，過度的擴張個資保護的界線，對市場發展以及消費者權益而言，並非好事。 當然另一方面而言，濫用科技便利的情形是存在的，如同2012年12月甫結束之ITU國際電信大會（WCIT2012），多國所簽署之修正電信管制規則第5B條所示，要求各國應努力採取必要措施，防止未經許可之濫發電子訊息，以減少對國際電信業務之影響。由於網路無遠弗屆，具騷擾性、浮濫發送之訊息，已從早期之垃圾電子郵件，擴及網路即時通訊軟體，不但時常造成使用者之困擾，甚至造成詐騙橫行。而這些狀況，光依靠個資法也是不足的，尚須主管機關對於濫用電信資源加以管制，從個人資料與電信資源等層面多管其下，方能維護良好之產業環境。
日本推動智慧醫療照護與巨量資料應用之趨勢觀察 英國期望透過資料使用與近用法案修正案，強化數位證據資料之可信任性英國於2024年11月提出資料使用與近用法案（Data (Use and Access) Bill）修正案，其修正內容包含強化數位證據資料之可信任性。 根據英國數十年來的法院判決，可以觀察到英國法院信任電腦自動產出的資料，因此除非當事人提出反證，否則將推定電腦證據是可信賴的。然而，該見解導致英國爭議案件「郵局Horizon系統出錯案」的發生，亦促使資料使用與近用法案修正案的提出。 資料使用與近用法案修正案於第132條新增與數位證據相關的條款，同條第1項規定由電腦、裝置或電腦系統產生的數位證據，符合下列規定者，於訴訟程序中可以作為證據。 a、 數位證據以及產生數位證據或衍生數位證據之系統之可信任性未受質疑。 b、 法院確信無法合理地挑戰系統之可信任性。 c、 法院確信數位證據源自可信任的系統。 此外，同條第4項規定第1項第c款所指之可信任的系統，應包括適用於系統運作的任何指示或規則，以及為確保系統中保存的資料的完整性而採取的任何措施。 綜上所述，英國逐漸扭轉過去英國法院認為由電腦自動產生的資料具有可信任性之見解，並透過資料使用與近用法案修正案修正對於數位證據的認定，未來在涉及數位證據的案件中，檢辯雙方需要證明作為數位證據的資料完整性具有可信任性。 我國企業如欲強化數位資料的可信任性，可參考資訊工業策進會科技法律研究所創意智財中心所發布之重要數位資料治理暨管理制度規範（EDGS），建立並落實數位資料管理流程，除可確保數位資料的完整性及正確性具有可信任性，亦可提升法院採納數位資料作為證據之可能性。 本文為資策會科法所創智中心完成之著作，非經同意或授權，不得為轉載、公開播送、公開傳輸、改作或重製等利用行為。 本文同步刊登於TIPS網站（https://www.tips.org.tw） .Pindent{text-indent: 2em;} .Noindent{margin-left: 2em;} .NoPindent{text-indent: 2em; margin-left: 2em;} .No2indent{margin-left: 3em;} .No2Pindent{text-indent: 2em; margin-left: 3em} .No3indent{margin-left: 4em;} .No3Pindent{text-indent: 2em; margin-left: 4em}