Cloudflare 實測：近七成 BGP 路徑的 ORIGIN 屬性遭上游竄改
Cloudflare Blog · 2026-07-24
原本的問題
BGP 路由選擇機制中，ORIGIN 屬性用來標示一條路由最初是怎麼進入 BGP 世界的。依照 RFC 4271 定義，它只有三種值：IGP(0)、EGP(1，已廢棄協定的歷史遺留值)、INCOMPLETE(2，來源不明的外部路由)。規格明訂這個屬性「不應被除了原始發布者以外的任何路由器修改」，但它在 BGP 決策演算法中屬於較早比較的欄位，直接影響一條路徑最終會不會被選中。只要其他條件相同，ORIGIN 值較低的路徑就會勝出，這給了竄改者可乘之機。
採用的方法
Cloudflare 工程師 Iliana Xygkou 與 Bryton Herdes 設計了一組主動測量實驗：從多個對等互聯據點同時對外宣告三組 IPv4、三組 IPv6 前綴，並刻意賦予不同的原始 ORIGIN 值。他們接著比對 RIPE RIS、RouteViews 兩大公開路由收集器記錄下的 BGP Update 訊息，並以自家 BMP(BGP Monitoring Protocol)資料交叉驗證。解析 MRT 格式路由傾印檔案用的是開源工具 BGPKIT，AS 階層排名則參考 CAIDA 的 AS Rank 資料集。目的是量化究竟有多少上游電信商會在轉發過程中，把途經的 ORIGIN 值偷偷「升級」成 IGP。
| ORIGIN 值 | 意義 | 公開路由資料占比 |
|---|---|---|
| IGP (0) | 路由源自本 AS 內部 | 89.8% |
| EGP (1) | 舊版 Exterior Gateway Protocol 遺留值 | 3.5% |
| INCOMPLETE (2) | 來源不明的外部路由 | 6.7% |
實際效果
結果顯示問題遠比想像中普遍：約 70% 的 IPv4 AS_PATH 與 67% 的 IPv6 AS_PATH，在傳遞途中被重寫為 IGP；觀測到的前 50 大 AS 裡，有 26% 存在這種行為，而在較長路徑上執行竄改的 AS 比例約為 10.6%。對動手竄改的 AS 而言，效果立竿見影——竄改後可見路徑數量明顯增加，IPv4 多出 18%(約 12 條)，IPv6 多出 40%(約 33 條)，等於把更多下游流量攬進自己網路換取轉送費。
Cloudflare 已提出名為 Scrubbing BGP ORIGIN Attribute 的草案，主張要求所有 BGP 實作在收到路由時一律將 ORIGIN 重設為 IGP，讓這個欄位徹底喪失影響路徑選擇的能力，從根本上讓竄改失去意義。
原始來源：BGP ORIGIN attribute manipulation and its impact on the Internet
Pinterest 的 Resource Provisioner Pipeline：用集中式執行引擎收斂數百個 Terraform Workspace
Pinterest Engineering Blog · 2026-07-23
原本的問題
Pinterest 的基礎設施程式碼分散在數百個 Terraform workspace、橫跨多個 repository，任何團隊都能各自對自己的 workspace 直接執行 terraform apply。這種去中心化的執行模式，讓資安團隊很難統一掌握誰改了什麼、改動有沒有經過審查，尤其牽涉 IAM 角色、網路規則、KMS 加密金鑰這類高風險資源時風險更明顯。工程師 Ammar Ekbote 與 Chan Kim 在文中指出，缺乏一致的執行入口，等於每個 workspace 都是一個獨立的攻擊面。
採用的方法
Pinterest 自建的 Resource Provisioner Pipeline(RPP) 把所有 Terraform apply 動作收斂到單一路徑執行。流程由 GitHub Actions 觸發：先透過 GitHub OpenID Connect(OIDC)簽發的 token 換取集中管理的 RPPActionsRole，再依 PR 改動的檔案路徑，對照一份「路徑對應合法 workspace」的設定檔驗證權限，通過後才向下收斂成該團隊專屬、權限最小化的執行角色。套用前會先跑 terraform fmt 與 Semgrep 靜態掃描，並要求雙重把關：核准程式碼的審核者與實際下達 apply 指令的人必須是不同角色。
team-abc = {
email = "teamabc@pinterest.com"
workspaces = [{
name = "workspace1"
working_directory = "terraform/config-dev"
github_repo = "pinterest/repo1"
}]
agent_iam_roles = ["arn:aws:iam::<account-id>:role/RPP-ExecutionRole-TeamABC"]
}實際效果
RPP 目前已接管數百個 Terraform workspace，統籌管理數萬筆雲端資源，涵蓋安全政策、網路架構與運算儲存等類別。每一次 plan 與 apply 的結果都會自動回貼到 PR 留言，形成可追溯的稽核紀錄，而不是散落在各團隊自己的 CI log 裡。文章沒有公布導入前後的事故率或部署耗時等量化數字，但強調 workspace 隔離加上角色鏈(role-chaining)機制，讓單一 workspace 的憑證外洩不再能波及其他團隊的基礎設施。
原始來源：Securing Infrastructure at Scale: Introducing Pinterest's Resource Provisioner Pipeline (RPP)
不靠網頁工程師：LINE Planet 團隊如何在 LINE App 內做出多人視訊通話
LY Corporation Tech Blog · 2026-07-21
原本的問題
LINE Developers 提供的 LIFF(LINE Front-end Framework)可以讓一個 LINE 官方帳號(LINE OA)在 App 內嵌的 webview 開一個網頁服務，直接對使用者提供互動功能，而不只是推播通知。理論上這讓 LINE OA 有機會變成完整的服務入口，但要做出「多人視訊通話」，一般得處理 WebRTC 媒體流、跨地區網路品質與 LINE 登入串接，通常需要專職網頁工程師才能啃下來。LINE Planet 團隊裡實際動手的只有一位產品經理與一位 Android 工程師，兩人都沒有網頁開發背景。
採用的方法
關鍵做法是把最難的部分外包給既有元件：LINE Planet SDK 直接處理 LINE 使用者驗證、WebRTC 媒體處理與跨區網路基礎設施，團隊只需要在前端呼叫 SDK 提供的介面。開發流程大致分五步：設計房間 ID 產生方式；用 MediaStreamManager 做鏡頭與麥克風的預覽畫面，避免使用者被重複要求授權；串接 LIFF 拿到的 userId、displayName，向自架在 Firebase Cloud Functions 上的 App Server 換取 LINE Planet 存取權杖後加入會議；依參與人數動態切換畫面解析度(1 對 1 用 HD、2×2 用 VGA、更多人用 QVGA 以控制頻寬)；最後用 shareTargetPicker API 讓使用者直接邀請 LINE 好友加入通話。
兩人形容，TypeScript 與 React 的元件模型其實跟 Android 的 View / ViewModel 架構相似度比預期高，再借助 AI 輔助生成前端邏輯與樣板程式碼，讓原本只寫 Android 的工程師能跨過語言與框架的門檻，直接產出可上線的網頁前端。
實際效果
這套架構已支援律師、理財顧問、諮商師等需要一對一視訊諮詢的職業情境，使用者不必額外安裝 App，就能在 LINE OA 內完成通話；也支援遠距教學情境，讓老師與學生能預約時段、準時進入視訊教室並共享畫面。LINE Planet 的底層設施同時支援 500 至 10,000 人同時在線的直播情境，顯示同一套 SDK 可以從一對一諮詢延伸到大型互動直播，不需要重新開發媒體堆疊。
原始來源：Using AI to build a group video call service inside the LINE app without a web engineer