【AI Coding下篇】開發成本大幅壓低，工程師角色如何改變？陳宜昌：懂得定義問題，才能把AI變成槓桿

來源：https://www.ithome.com.tw/news/177186

AI輔助開發（AI Coding）加速程式碼產出，但真正的挑戰才開始。

前聯發創新基地技術經理陳宜昌觀察，AI接手大量實作、測試和修正工作後，團隊更需要穩定的品質把關流程，也可以用AI協助檢查AI產出的結果。同時，工程師也不能停在「怎麼做」，而是要更早判斷「做什麼」、為什麼做，以及AI產出的成果是否真的可用。

AI Coding壓低開發成本，一人搭配AI Agent，也有機會快速開發產品原型；但這也讓工程師面對更高的能力要求。懂得定義問題、拆解任務和驗證結果的人，才更有機會把AI變成槓桿。

在上篇，陳宜昌以語音聊天機器人專案為例，說明AI Coding不是要AI一次生成整套系統，而是先拆模組、寫小範圍規格（Spec）、測試驗證，再逐步整合。下篇則進一步談，AI Coding如何改變軟體開發的品質控管、工程師技能要求與角色定位。

AI加速開發，品質把關更不能少

AI Coding加速開發，開發者更要把關程式碼品質與安全風險。陳宜昌點出，程式碼審查、測試、CI/CD自動化流程、監測等傳統軟體開發手段，在AI Coding時代反而變得更重要。

測試就是最直接的例子。過去，工程師寫單元測試、整合測試很花時間，團隊往往只能挑重點測。但現在，AI可以協助產生測試案例，測試撰寫成本下降，團隊更應該提高測試覆蓋率，把更多功能納入自動化驗證。

CI/CD自動化流程也是如此。開發迭代節奏越快，程式碼更常合併、打包和部署，若沒有自動化檢驗，團隊就更難在上線前發現問題。因此，開發者可在CI/CD中，設定檔案掃描與排除機制，好在產品上線前，先擋下不該公開或不該部署的檔案。

AI代理（AI Agent）也能強化這道關卡。例如部署前，AI先掃描程式碼和檔案，檢查機敏資料是否外洩、錯誤檔案是否被打包，或是否存在其他安全風險，再輸出風險評分。若分數不達標，這次自動化建置流程就不會通過。

可以說，AI Coding不只加速開發，也能反過來強化品質控管。它可以協助產生測試、掃描風險、檢查部署內容，讓更多檢測步驟進入自動化流程，用來驗證AI開發的成果。

工程紀律能控管風險，但不能取代人的架構判斷

AI Coding能做的事越來越多，甚至能讓團隊設下更多品質關卡。但軟體開發更上層的架構與需求判斷，還是得靠人。

陳宜昌認為，目前至少有3件事很難完全交給AI。

第一是架構設計。這不是單純的技術選擇，而是判斷系統未來該如何擴展、哪些地方要保留彈性、哪些部分不能累積技術債。這些取捨牽涉產品方向、既有程式碼狀態和團隊維護能力，不是AI看幾段程式碼，就能完整判斷。

第二是需求收斂。AI很容易發散，可以列出很多可能性、做法和提醒。但真正困難的地方在於，從一堆選項中，決定現在什麼該做、什麼不該做。這些決策，都需要人類工程師理解目標、成本和優先順序。

第三是系統性錯誤。單一函式錯了，AI通常很會修；但若是多個模組整合後的互動，AI就很難抓到問題。這也是為何，陳宜昌在上篇大型專案中，刻意設計Log與可觀測性，來給AI足夠線索，去追蹤問題。

工程師價值從「怎麼做」轉向「做什麼」

AI Coding的出現，開始改變工程師的工作重心與角色定位。

過去，工程師很大一部分工作，是執行與盯細節。需求確認後，要有人把功能寫成程式碼、補測試、修Bug，還要處理各種實作細節。這些工作常由新進工程師處理，也是他們理解系統、累積經驗的起點。

但現在，AI可以接手愈來愈多實作、測試和修正工作，新進工程師因此少了一條熟悉的養成路徑：以前可以從基礎實作慢慢練功，現在得要更早理解產品、系統架構和驗證方式，才能更有效與AI協作。

相較之下，資深工程師更有優勢，只要懂得拆解任務、判斷架構、看懂系統全貌，就能更快運用AI，來完成過去需要更多人力才有進展的工作。

也因此，工程師的能力需求開始往上移。光會寫程式還不夠，還需要站在更高層，理解整體程式碼與系統脈絡、掌握產品與客戶需求，判斷AI產出的程式碼適不適合放進既有架構、長期維護。

這也讓工程師和產品經理（PM）、設計師，甚至客戶之間的邊界越來越模糊。過去，工程師多半接收整理好的需求，再把功能做出來。AI Coding縮短開發時間後，工程師不能只停在「實作」這一端，而是要更早理解使用者回饋，更快判斷產品下一步該往何處發展。

可以說，工程師的工作重心正從回答「怎麼做」，轉向「做什麼、為什麼做」。工程師的角色，也更靠近產品創造者，必須同時看懂技術、產品與市場需求。

從AI技術研究到創業者：在最壞的時代，尋找最好的槓桿

這些觀察，也讓陳宜昌重新思考自己的下一步。

過去幾年，他走的是一條典型的AI技術路線。他曾在聯發創新基地擔任技術經理，主導AI研究與開發工作，參與Breeze繁體中文語言模型系列，也投入臺語與臺灣口音華語的語音辨識、語音合成技術；研究成果也曾發表於ICLR、ACL等頂級國際AI會議。

但AI Coding出現後，陳宜昌看見另一種可能。

他形容，現在是「最好，也是最壞的時代」。最壞的是，純執行類工程技能正在快速貶值。過去需要初階工程師花時間完成的實作、測試和修正工作，現在大都能交給AI處理。只靠執行能力站穩位置，會越來越困難。

但好的一面也很明顯：做出產品雛形的成本大幅下降。

過去，一個人有創業想法，常得先募資、找共同創辦人、組工程團隊，再花幾個月做出初版產品。現在，只要創業者懂軟體開發、懂產品需求，也知道怎麼把問題拆給AI，一人搭配AI Agent，可能一、兩周就能做出產品原型，拿去測試市場反應。

這也是陳宜昌決定投入個人AI創業實驗的原因。對他來說，AI不只幫忙寫程式，也讓產品試錯變得更快、更容易。過去要投入大量時間和人力的想法，現在可以先做成原型，拿到市場驗證；方向不對，就快速淘汰；看見機會，再投入更多資源。

「如果繼續停留在執行者角色，我的價值會被稀釋。」他說。因此，他決定往前一步，從執行任務，走向定義問題、創造市場價值。這也呼應他對AI Coding的核心看法：能定義問題的人，才能把AI變成槓桿，更快將想法落地為產品。

'

【AI Coding上篇】AI如何改寫開發流程？前聯發創新基地技術經理：別只想寫完美Spec

來源：https://www.ithome.com.tw/news/177185

要做一個軟體專案，通常會經過這樣的流程：產品經理（PM）先整理需求，與資深工程師來回討論，釐清功能背後真正要解決的問題，再由資深工程師設計架構、拆解工作，最後與資淺工程師分工實作。

這套流程之所以通用，是因為軟體開發的難題是「判斷這個功能該怎麼做」。同一個功能，可以有很多種寫法，但哪一種比較符合既有系統架構？哪一種未來比較好維護？哪一種不會讓技術債越滾越大？都需要經驗判斷。

也因此，業界長期仰賴一種合作模式：資深工程師規畫架構與規格，再與新進工程師組隊實作。問題也在這，最懂架構、最懂系統脈絡的資深工程師，還是得花大量時間處理實作細節，比如寫程式、查語法、看文件、修編譯錯誤，也要與團隊成員溝通需求、確認進度、檢查方向。專案越大、人越多，溝通成本也越高。

但這種分工模式在AI輔助開發（AI Coding）出現後，開始鬆動了。

這正是前聯發創新基地技術經理陳宜昌的觀察。他點出，AI Coding帶來的最大變化是，一個人也有機會完成過去一個小型工程團隊才能做完的工作。前提是，這個人必須夠懂需求、懂架構，知道怎麼把工作切成AI能處理的範圍。

「一個人能做的事情，會變得非常多，」他說。AI Coding究竟如何把一個人的開發能力，放大到這種程度？

從懷疑到實戰：AI可以參與更多開發環節了

有趣的是，陳宜昌一開始並不看好AI Coding。他原本懷疑，AI頂多幫忙補幾段程式碼，能否真正輔助完成一個專案，還很難說。

真正讓他改觀的，不是公司要求，也不是管理層推動，而是社群朋友們不斷「推坑」。這些朋友持續分享AI Coding實戰經驗，也一直鼓勵他試試看。陳宜昌抱著姑且一試的心態實際動手，結果發現，AI Coding工具的能力遠超想像。

他後來乾脆組織一場線上讀書會，邀請更早投入AI Coding的開發者，分享工作流與踩坑經驗，再把這些方法帶回自己的專案中驗證。

現在，他自己的工作流程裡，大多數開發環節幾乎都有AI參與，從需求分析、架構討論、程式實作、測試、除錯，再到最後的品質檢查（QA）都不例外。

比如，在架構設計階段，AI就像是個隨時在線的討論對象。它未必能直接給出標準答案，但可以提出多種設計方案，供工程師衡量不同取捨。例如，這個模組要不要獨立？資料流要怎麼走？前後端要如何互動？哪些地方未來可能變成維護問題？

又或是，以他採用的測試驅動開發（TDD）作法為例，他先讓AI理解要做什麼，再請AI先寫測試，接著才實作程式碼。程式寫好後，再以測試驗證結果；如果測試不通過，AI再回頭修改程式，直到測試通過為止。

在這套流程裡，AI一邊寫程式，一邊根據測試結果修正問題，兼顧開發和初期品質把關者的角色。

不過，陳宜昌很快就發現，AI會寫程式，不代表就知道該怎麼寫。真正影響成果的，是工程師如何一步步引導它。

別只想寫完美Spec，程式碼本身也是AI的導航

很多人開始用AI Coding後，直覺地以為，只要把規格（Spec）寫得夠完整，就能讓AI一口氣做出整套系統。

陳宜昌認為，這只說對了一半。因為，AI不只看規格做事，還會讀既有程式碼。程式碼本身清不清楚、好不好讀、邏輯嚴不嚴謹，都會影響AI接下來的寫法。要是既有程式碼結構紮實、邏輯嚴謹，AI比較能沿著原本架構延伸；但若程式碼本身混亂，就算Spec寫得再完整，AI的產出也容易跟著失準。

尤其，處理大型專案時，更不該寫一份巨型Spec，期待AI一次生成系統。因為專案越複雜，細節越多，AI就越容易資訊過載；而寫一份鉅細靡遺的Spec，看似把需求交代清楚了，一旦開始生成，錯誤可能在不同模組間一起發酵，最後開發者還是得回頭重做。

陳宜昌建議，比較穩的做法是，開發者先把大型系統拆成幾個獨立元素，每個元素各寫一份小範圍Spec，讓AI先完成單一任務，再用測試確認結果。等各元素穩定後，再寫一份整合專用的Spec，把各個元素組合起來。

這套做法不是紙上談兵，而是陳宜昌在一項大型專案踩坑後，總結出的AI Coding心法。

從5,000行Spec學到的一課：複雜專案要先拆模組，再讓AI各自開發、整合

這項大型專案是，陳宜昌與兩位學生近期開發的語音聊天機器人。該專案的研究基礎來自他們先前在國際AI頂級會議ICLR發表的論文成果，目標是把研究成果落地成一個能即時對話，且擁有情緒變化的語音聊天機器人。

一開始，他們走過一條很多人直覺會選的路：先把規格寫清楚，再讓AI照著開發。

當時，他們使用類似SpecKit前身的上下文工程框架（Context Engineering Framework）。這類做法的邏輯很直覺，先把Spec訂好，再進入開發。於是，他們把能想到的細節都寫進規格裡，包括模型要怎麼設計、工程架構怎麼安排、每個元件該做什麼，甚至最後負責指揮各模組的協調器（Operator）該怎麼運作，一項一項交代清楚。

結果，這份Spec寫到5,000行。

照理說，規格寫到這麼細，AI應該更容易實作。實際執行後，程式碼還是出錯了，而且最麻煩的是，不知道錯在哪。因為，這些程式碼不是一段段產出，而是AI根據Spec一口氣生成；一旦系統跑不起來，就很難判斷是模型設計、模組介面、協調器邏輯，還是某個細節讓AI誤解了。

他們一開始以為是Spec不夠細緻。於是又回頭補充，花了大概一個禮拜，把規格寫得更完整。陳宜昌和兩位學生甚至把Spec攤在螢幕上，一行一行、逐項檢查，確認是不是還有什麼沒交代清楚。

檢查到最後，幾乎想不到還有哪裡沒寫清楚了。

但再跑一次，AI生成的系統還是跑不動。

陳宜昌這時才意識到，問題不是Spec不夠完整，而是這種做法不適合處理複雜系統。把所有需求寫進一份巨型Spec、期待AI一次生成完整專案，看起來很俐落，實際上是把所有複雜性集中到同一個生成階段。只要某個環節出錯，就可能牽動整套系統，除錯也變得非常困難。

後來，他決定換一種方式：不叫AI一口氣生成一套系統，而是先拆分任務。

於是，他把系統拆成3個主要模組。首先是負責聲音接收與前處理的模組；再來是負責中間對話的語音語言模型，能根據聲音資訊和過去對話歷史，即時生成接下來要說的內容；第三個模組負責語音合成，把語音語言模型輸出的回應轉成可以播放的聲音，並送到前端。前端則提供錄音按鈕、播放介面等使用者操作元件。

有了這三個模組，還需要一個總指揮，也就是Orchestrator，來協調各模組運作、與前端互動。

拆分後，事情變簡單了。每個模組的Spec不再承擔整套系統的複雜性，只要把各自的任務寫清楚即可。AI不必一次理解所有模組如何互動，而是先把一個範圍有限、責任清楚的元件做出來。

接下來，陳宜昌用測試驅動開發模式來實作每個模組。也就是AI先寫測試，再寫程式碼，接著跑測試；如果測試失敗，就根據錯誤回頭修正。多數時候，AI可以自己完成這個循環；如果卡住，再人工介入判斷，是測試寫錯、需求描述不清，還是程式遇到特殊狀況。

每個模組都通過測試、表現穩定後，就能進入整合階段。這時，他們寫了一份整合用的Spec，讓AI來處理模組間的串接，最後再做端對端測試，確認整個流程從錄音、理解、生成回應到語音播放，都能如預期運作。

除錯時，陳宜昌還有一套做法，善用日誌（Log）作為線索。他會在系統關鍵節點打入重要Log，當程式出錯時留下足夠資訊，將錯誤訊息和Log交給AI，請它判斷錯誤來源、修改程式。甚至，還能讓AI自己反覆執行、看Log、修程式再執行，人類工程師則在旁邊監督方向是否正確。

這次經驗，讓他重新理解AI Coding的用法。AI不是不能處理複雜專案，而是需要開發者先拆解系統、定義模組邊界，再讓AI在小範圍內開發、測試、修正，最後才把各模組組裝起來。

可以說，AI Coding的真正用法，是工程師先把問題拆清楚，再讓AI在可控範圍內，完成實作與驗證。

'

英國雙管齊下對抗網路威脅，啟動企業承諾並打造國家級AI盾牌

來源：https://www.ithome.com.tw/news/177272

面對因AI而加劇的網路安全威脅，英國政府與國家網路安全中心（National Cyber Security Centre，NCSC）上周二（7/7）宣布啟動企業的網路韌性承諾（Cyber Resilience Pledge），並公布國家級AI網路防禦藍圖Cyber Shield。

NCSC的調查資料顯示，英國企業在2025年遭受超過500萬次的網路攻擊，整體年度經濟損失高達147億英鎊（約6,320億元新臺幣）。這使得英國政府鼓勵企業主動提升資安韌性，在今年4月發表網路韌性承諾，邀請企業參與並採取3項具體行動來改善資安，包括將網路安全提升至董事會層級責任，註冊NCSC的免費預警服務，以及強化供應鏈網路安全。

上周英國政府正式啟動網路韌性承諾，並宣布已有超過60家企業簽署該承諾，涵蓋零售、金融、媒體與科技等產業，如百貨業者Marks & Spencer、金融機構Nationwide、電視臺ITV及英國電信業者Vodafone等。

NCSC表示，網路韌性承諾的3項措施都是切實可行的行動，有助提升組織抵禦網路攻擊及事件復原能力，更能保護客戶；若廣泛推動，也將提升整體英國經濟的韌性。

至於Cyber Shield是由NCSC及科學、創新與技術部（DSIT）共同開發的國家級網路防禦藍圖，核心目標是利用最先進的代理人AI，打造一個可大規模、以機器速度自動化運作的國家網路防禦體系。

根據規畫，Cyber Shield將具備可靠且可說明決策依據的AI、聯邦式代理人（Federated Agents）、漏洞發現與緩解、協同偵測與回應，以及國家級的掃描與緩解等功能。

未來將由紅隊及藍隊AI代理人協同運作，紅隊負責以機器速度發現系統弱點，藍隊則即時偵測、遏制威脅並防禦入侵。這些AI系統初期將以自動發現漏洞與威脅為主，再逐步發展至自動修復；它們可在各自組織的控制與授權下運作，並跨越組織邊界無縫協作，共同提升英國的國家安全。

Cyber Shield目前仍處於規畫階段，NCSC將先與政府及關鍵產業合作測試相關能力，再逐步發展為可於全國部署的商業化方案。

'

資安桌遊融合CTEM與團隊合作，奧義智慧揭Cybercrete設計概念

來源：https://www.ithome.com.tw/news/177268

將複雜的企業資安管理概念融入桌遊，已成為資安教育的新趨勢，先前奧義智慧科技（CyCraft）在此領域的發展引發業界關注，因為他們成功將MITRE ATT&CK與Cyber Defense Matrix（CDM）的資安框架，呈現在遊戲卡牌與桌遊，去年該公司再度推出新作《Cybercrete：守衛資安之路》，進一步將持續威脅曝險（Continuous Threat Exposure Management，CTEM）框架帶到大眾面前，近日奧義智慧資安研究處長陳仲寬特別公開闡釋其幕後設計概念，解析資安框架與遊戲機制的融合重點。

陳仲寬表示，《Cybercrete》的設計核心緊扣2022年Gartner提出的「持續性威脅暴露管理」（CTEM）方法論。該框架強調，企業在識別攻擊面時不應視為一次性任務，而需透過持續性的行動，達成動態且具適應性的主動式攻擊面管理。

具體而言，這款遊戲由奧義智慧資安研究員參與開發，是一套貼合企業真實資安情境的策略模擬遊戲，目的是讓玩家在有限資源下，學習如何持續管理威脅暴露，並在事件發生時有效應對。

遊戲流程完整貫穿CTEM的五大步驟：從釐清防禦範圍的「界定」、識別資產風險的「探索」、到決定處理順序的「排序」、確認風險真實性的「驗證」，以及最終動員資源解決問題的「行動」。

陳仲寬指出，玩家可以想像，企業必須找到所有資產並識別風險，但資源有限，因此排序至關重要。在遊戲中，玩家可能只能處理前三大風險，必須先驗證其存在再執行應對。而且，各角色如何針對威脅進行應變，更是這套模擬工具要傳達的核心概念。

這款桌遊的另一大特色是結合「多人合作」與「劇本殺」元素。陳仲寬表示，開發團隊依據美國NICE資安人才框架，設計出6種遊戲角色，包括資安長、安全架構師、IT工程師、資訊安全分析師、威脅情資研究員及SOC工程師，讓玩家扮演不同職能來聯手應對事件。

為了模擬大型事件發生時的攻防情境，遊戲地圖呈現企業的網路資產拓樸，並引入遊戲主持人來引導遊戲劇情推進。在執行任務時，每個角色的職能邊界非常明確。陳仲寬舉例：「如果你扮演的是安全分析師，你將無法幫其他人修補漏洞，因為這是IT人員的職能；同樣地，IT人員也無法代替你進行威脅調查。」這種角色功能的嚴格切割，亦可讓玩家深刻體會跨部門溝通與協作的必要性。

此外，在規則設計上，開發團隊不僅考量資安概念的融入，更從多款成熟的桌遊玩法中獲得啟發。例如，借鑑策略合作類桌遊《瘟疫危機》的機制，並融入《山中小屋》的劇本殺元素，藉此打造出一款同時具備桌遊趣味性與資安教育意義的作品。

在追求趣味性的同時，遊戲核心仍緊扣實務需求。陳仲寬強調，《Cybercrete》的首要目標是帶領玩家深入理解CTEM框架，並體認到資安管理的第一步，就是預先瞭解自己內部資產配置與權限。

玩家在遊戲過程中，不僅能學習漏洞管理、端點安全、組態配置評估及憑證外洩防護等知識，還能從中領會情資對於資安防禦的重要性，並且深刻體悟「資安不是一個人的事」，每個角色都有其關鍵任務，必須攜手應對。

'

新型釣魚平臺Forg365結合AI技術，鎖定Microsoft 365帳號發動攻擊

來源：https://www.ithome.com.tw/news/177269

資安業者ZeroBEC揭露新型釣魚即服務（Phishing-as-a-Service，PhaaS）平臺Forg365，鎖定Microsoft 365帳號發動釣魚攻擊。研究人員指出Forg365採訂閱制營運，並透過Telegram平臺提供銷售、支援及更新服務，其控制面板直接整合AI產生釣魚信件內容的功能，利用Amazon SES發送釣魚信件，並提供多種攻擊路徑，以及透過專用瀏覽器擴充套件協助維持長期存取能力，整體來說，是與今年稍早揭露的Kali365相似的成熟PhaaS平臺，結合多種已知攻擊手法，同時加入AI功能。

Forg365主要有兩種攻擊路徑，一為濫用Microsoft裝置驗證碼（Device Code）流程，誘導使用者前往真正的Microsoft驗證頁面輸入驗證碼，藉此在後端取得OAuth權杖，這一點與Kali365，以及ZeroBEC日前發現的另一新型惡意工具DEBULL相同；另一種方式則是較傳統的中間人攻擊（AiTM），在受害者與Microsoft登入服務之間，透過代理伺服器攔截驗證資訊。

為了因應這類新型釣魚攻擊的威脅，ZeroBEC建議企業限制裝置驗證碼的使用，並監控Entra登入與Microsoft驗證代理程式（Authentication Broker）記錄，以及異常裝置註冊。

'

立委提案修法放寬StarLink等低軌衛星業者來臺限制，台灣通訊學會：不能只是鬆綁，也要建立境外業者監管機制

來源：https://www.ithome.com.tw/news/177266

立法院交通委員會今天（7/13）日審查「電信管理法」第36條修正草案，外界關心修法可能為Starlink等低軌衛星業者進入臺灣市場鋪路。對此，台灣通訊學會發出聲明指出，支持引進多元低軌衛星服務，提升國家通訊韌性，但修法若只是放寬外資持股及負責人資格限制，卻未同步建立對境外衛星業者的監理制度，恐在市場開放與公共責任間形成治理缺口。

目前「電信管理法 」第36條規定，設置使用電信資源的公眾電信網路者，其董事長須具有中華民國國籍，外國人直接持股不得超過49%，直接及間接持股合計不得超過60%。為了放寬低軌衛星業者進入臺灣市場，立委提出6個修正草案版本，希望對於衛星通信業者增訂例外或放寬相關限制。

台灣通訊學會指出，近年地緣政治風險升高，加上俄烏戰爭顯示衛星通訊可在地面網路受損時提供重要備援能力，而臺灣國際通訊高度依賴海底電纜，因此有必要建構海纜、微波及衛星等多元備援架構，加速導入非地面網路（NTN），提升國家數位韌性。

不過，學會認為，政策討論不應聚焦特定業者，而應以技術中立、風險相稱及公共利益為原則。若僅是調整外資持股與董事長資格，卻未同步建立國家安全審查、在地營運、資料治理、通訊監察、資安、防詐及退場機制等配套，將增加長期治理風險。

台灣通訊學會理事長王維菁表示，臺灣需要多元衛星服務，但關鍵通訊控制、用戶資料治理及法律責任，都必須納入在地可監理、可執行的體系。「衛星服務可以跨境，責任不能境外化；市場開放的前提，是政府在平時能監督、事件發生時能介入，並確保服務持續與民眾權益。」

可參考日本模式，要求在臺建立實質營運能力

針對未來制度設計，學會建議可參考日本模式。日本的KDDI、NTT DOCOMO及SoftBank皆已與Starlink合作推出手機直連衛星服務，將衛星能力納入既有電信服務及公共安全體系。

因此台灣通訊學會建議，國際衛星業者進入臺灣市場時，原則上應在臺設立具實質營運與履責能力的法人；若提供手機直連衛星服務，或使用臺灣行動頻率、號碼及核心網路資源，應與本地持照電信業者合作。同時，也應設置境內地面站、閘道器或具有同等監理效力的節點，並承擔用戶服務、緊急通信、個資保護、資安、防詐及司法協力等責任。

學會也呼籲主管機關建立透明且可驗證的審查制度，針對業者控制權、供應鏈安全、資料流向、服務持續性及消費者保障訂定審查條件，並保留附加負擔、限期改善、停止服務及撤銷許可等必要監理機制。

學會也強調，調整外資持股與負責人資格限制前，應完整檢視國家安全、監理執行及公共利益等配套措施，透過完善制度讓低軌衛星成為我國通訊韌性的關鍵備援，同時維持政府對跨境衛星服務的監理與介入能力。

現有衛星服務多採合作模式，修法瞄準業者直接進入市場

值得注意的是，目前國內已有低軌及多軌衛星服務布局，但主要是由本地電信業者與國際衛星業者合作，將衛星能力納入既有通信服務體系。例如國內電信業者已導入OneWeb低軌衛星及SES中軌衛星等服務，作為地面網路之外的通信備援方案。

在現有的模式下，國際衛星業者主要提供衛星網路、頻寬或衛星系統能力，本地電信業者負責本地服務整合、用戶管理及對主管機關承擔電信服務相關責任。

這次「電信管理法」第36條規定多項修正草案則是希望針對「以衛星通信技術設置使用電信資源的公眾電信網路業者」新增例外機制，經主管機關考量國家安全、公眾電信網路安全、電信資源使用及公共利益等因素核准後，可不受原本的限制。

兩者最大的差異在於，現有OneWeb、SES等服務主要是「衛星業者提供能力、臺灣電信業者負責服務落地」；而第36條修正草案目的是是否讓具高度國際化股權結構的衛星通信業者，得以直接參與臺灣電信市場，因此引起電信產業、學會的關注。

'

駭客組織Helix鎖定SharePoint竊取資料，以此向企業索討贖金

來源：https://www.ithome.com.tw/news/177267

近兩年不斷透過竊得資料向受害組織進行勒索的駭客組織ShinyHunters（UNC6661），近期傳出疑似衍生出新的團體，引起研究人員的注意。威脅情報公司ReliaQuest於7月10日揭露資料勒索團體Helix，駭客結合語音網釣（vishing）、裝置驗證碼釣魚（device code phishing），以及自動化SharePoint資料竊取手法，對多個企業組織展開攻擊。研究人員研判，Helix極可能是今年4月宣告解散的勒索集團BlackFile（UNC6671）分裂後的團體，其手法與惡名昭彰的勒索集團ShinyHunters也有交集。

Helix的攻擊完全以身分盜用為基礎，他們會先透過電話語音網釣（vishing）接觸受害組織員工，在一起事故中，攻擊者偽冒目標的直屬主管撥打電話。取得信任後，攻擊者會誘導受害者完成裝置代碼驗證流程，藉此繞過條件式存取原則（Conditional Access），在不觸碰密碼的情況下，取得已驗證的工作階段權杖（session token）。

ReliaQuest指出，這些駭客在部分活動裡，採取戰術性分頭進行的模式，Helix先利用第一個被入侵的帳號偵察並下載SharePoint的資料內容，然後數日或數週後再入侵另一個帳號，透過微軟協作平臺Teams與電子郵件，在受害組織內部發送勒索訊息。研究人員認為，這種作法是為了干擾受害組織進行事件回應，由於兩個帳號彼此無直接關聯，資安團隊即使揪出並停用了負責竊取資料的帳號，另一個帳號仍可能持續運作，大幅增加調查與防堵的難度。

'