美國國家安全局發布「軟體記憶體安全須知」
美國國家安全局（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）。
美國及其他參與國際反勒索軟體倡議（International Counter Ransomware Initiative, CRI）之50個成員（含國家及國際組織），於2023年10月31日至11月1日召開第三次大會，並且發布聲明表示：應積極建立對抗勒索軟體之集體韌性（collective resilience）、共同合作降低勒索軟體之散布能力、追究相關行為人之法律責任、制裁非法資助勒索軟體之組織、與私部門合力防止勒索軟體攻擊。 CRI於2023年之關鍵成果主要可分以下三個面向： 一、加強資安管理能力 對CRI新成員提供指導及戰術培訓，例如由以色列督導約旦，以確保新成員之資通安全。此外，亦發起利用人工智慧打擊勒索軟體之計畫。 二、促進資訊共享 設立可即時更新之資訊共享平台，使CRI成員得以迅速分享資安威脅指標。如立陶宛之惡意軟體資訊共享計畫（Malware Information Sharing Project, MISP）、以色列及阿拉伯聯合大公國之水晶球平台（Crystal Ball platforms）。 三、反制勒索軟體使用人 CRI發布前所未有之共同政策聲明，闡明成員不應支付贖金，且創設成員間共享之加密貨幣錢包黑名單（blacklist of wallets），以便揭露勒索軟體使用人之非法帳戶，並公開與犯罪組織之金流紀錄。另，CRI於2024年起將持續致力發展前述聲明提及之目標，並優先向潛在成員進行宣導，透過提供量身訂做之資安應變能力培訓，滿足潛在成員之需求。
經濟合作與發展組織發布《促進AI可歸責性：在生命週期中治理與管理風險以實現可信賴的AI》經濟合作與發展組織（Organisation for Economic Co-operation and Development, OECD）於2023年2月23日發布《促進AI可歸責性：在生命週期中治理與管理風險以實現可信賴的AI》（Advancing accountability in AI: Governing and managing risks throughout the lifecycle for trustworthy AI）。本報告整合ISO 31000：2018風險管理框架（risk-management framework）、美國國家標準暨技術研究院（National Institute of Standards and Technology, NIST）人工智慧風險管理框架（Artificial Intelligence Risk Management Framework, AI RMF）與OECD負責任商業行為之盡職調查指南（OECD Due Diligence Guidance for Responsible Business Conduct）等文件，將AI風險管理分為「界定、評估、處理、治理」四個階段： 1.界定：範圍、背景、參與者和風險準則（Define: Scope, context, actors and criteria）。AI風險會因不同使用情境及環境而有差異，第一步應先界定AI系統生命週期中每個階段涉及之範圍、參與者與利害關係人，並就各角色適用適當的風險評估準則。 2.評估：識別並量測AI風險（Assess: Identify and measure AI risks）。透過識別與分析個人、整體及社會層面的問題，評估潛在風險與發生程度，並根據各項基本價值原則及評估標準進行風險量測。 3.處理：預防、減輕或停止AI風險（Treat: Prevent, mitigate, or cease AI risks）。風險處理考慮每個潛在風險的影響，並大致分為與流程相關（Process-related）及技術（Technical）之兩大處理策略。前者要求AI參與者建立系統設計開發之相關管理程序，後者則與系統技術規格相關，處理此類風險可能需重新訓練或重新評估AI模型。 4.治理：監控、紀錄、溝通、諮詢與融入（Govern: Monitor, document, communicate, consult and embed）。透過在組織中導入培養風險管理的文化，並持續監控、審查管理流程、溝通與諮詢，以及保存相關紀錄，以進行治理。治理之重要性在於能為AI風險管理流程進行外在監督，並能夠更廣泛地在不同類型的組織中建立相應機制。
車聯網「V2V」簡介V2V（Vehicle-to-vehicle）通訊使用短程無線通訊技術（dedicated short-range radio communication, DSRC）交換周邊車輛速度與位置等相關訊息，並協助採取相對應措施，如警告駕駛前方車輛正在剎車，或於駕駛視線死角處有其他車輛正高速接近。因此，使用V2V通訊技術可有效避免車輛間相互碰撞、紓解交通壅塞之問題，對環保方面亦有所助益，然而，此技術於多數車輛間得以相互通訊時，方能最大化其效益。 V2V通訊技術可以每秒約10次之頻率，使車輛間相互廣播並接收全面之訊息，從而在一定距離範圍內360度「感知」其他車輛並與其他車輛進行「對話」。若將搭載V2V通訊技術之車輛配備適當的軟體或安全設備，車輛間即可利用接收到的有效訊息來避免潛在的事故威脅。V2V通訊技術可偵測出超過300公尺範圍之交通情況，包括因交通、地形或天氣影響而受人類駕駛忽略之危險，較傳統使用雷達系統或攝影鏡頭進行偵測之方式更為精準。 無論是機車、汽車、卡車及公車皆可使用V2V通訊技術以提升車輛安全系統的性能，車輛間之連接技術將成為協助駕駛發現潛在交通危機的輔助工具，有助於顯著減少每年因交通事故喪生之人數。
歐盟執委會宣布「軟體開源授權及複用」決定歐盟執委會於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）委託由執委會進行研究產生之軟體，若公開將干擾臨時研究結果之驗證或構成拒絕註冊有利於執委會之智慧財產權的理由。