內容已複查
約 25 分鐘 · 6 張概念卡 · 2 題對應考古題

從原始碼到上線：編譯、測試與軟體生命週期

本頁為依教材與考古題整理的原創摘要；考古題答案經技術覆核，但不是官方答案。

考古題證據邊界： Language runtime 的 canonical direct ref 有題面與 answer-review mismatch，因此沒有安全 direct refs；錯誤處理與測試也為 0 題 direct primary refs，兩者皆為 reviewed-source-backed foundational coverage。Software lifecycle 則保留題面完整且 eligible 的 q-pp-im-it-106-23、q-pp-im-it-110-10，僅支撐 development-diagram／UML 辨識，不把 UML 內容歸因於 NIST SSDF。

第一次接觸也沒關係

這堂先懂這些詞

先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。

程式建置流程

也會看到：preprocessing、compilation、assembly、linking、GCC

原始碼依序經前置處理、編譯成組合語言、組譯成機器碼，再連結成可執行程式。

生活例子：
像先展開備料清單、翻成廚房指令、各站做好半成品，最後組成完整套餐。
別搞混：
Compilation 常被口語用來泛稱整個流程，但嚴格分階段時 linking 不屬於狹義 compilation。

動態連結

也會看到：dynamic linking、dynamic linker、loader、shared library

程式啟動或執行時，再把需要的共享程式庫載入並接到程式上。

生活例子：
像活動開始時才從共用器材室領取大家都會用的麥克風。
別搞混：
動態連結不是每次都重新編譯原始碼，且缺少相容程式庫仍可能啟動失敗。

安全軟體開發框架

也會看到：NIST SSDF、Secure Software Development Framework

NIST 將安全開發整理成準備、保護、產出安全軟體與回應弱點等實務。

生活例子：
像餐廳不只出餐前檢查，還要訓練人員、保護食材來源並建立問題召回流程。
別搞混：
SSDF 是組織實務框架，不是一套特定程式語言或單一測試工具。

驗證、測試與程式審查

也會看到：verification、testing、code review、static analysis、assertion、exception

測試執行案例、程式審查由人檢視、靜態分析不執行程式就找問題；它們提供不同證據。

生活例子：
像新店開幕前分別試營運、請同事看流程、用清單自動檢查規則。
別搞混：
測試通過只能證明測過的情境，不能保證程式沒有其他錯誤。

以 GCC 的 preprocessing、compilation、assembly、linking 階段為起點，連結 C++ error-handling 原則、可重複 verification 與 NIST SSDF 的安全軟體生命週期。

先抓住這幾件事

  • 區分 preprocessing、compilation、assembly 與 linking
  • 說明 exception、assertion 與 verification 的不同角色
  • 辨識 testing、code review 與 analysis 提供的不同證據
  • 說明 NIST SSDF 的 Prepare、Protect、Produce、Respond 四組實務

先想像這個場景

餐廳新菜單上線

餐廳從需求討論、流程圖、分工製作到試菜與正式上菜，每一階段都有不同產物與檢查，不會把食材清單直接當成可上桌的餐點。

先別急著往下看，花十秒想一想：

單獨試吃每道配料都沒問題，為什麼整套出餐流程還需要另外測試？

把故事換成電腦語言

生活中的角色對應到技術概念
食材清單與製作指示轉成餐點Source 經 preprocessing 與 compilation
各工作站的成品最後組成整份套餐Object files/libraries 由 linker 解析符號與組合
食材缺貨時走備用流程Exception handling 處理可預期異常
單項試味、工作站串接測試、全流程試營運多種 verification activities 提供互補證據
準備規範、保護產物、安全製作並回應問題NIST SSDF 的 Prepare、Protect、Produce、Respond

題目出現這些字，先想到

  • GCC -E 停在 preprocessing，-S 停在 compilation，-c 產生 object code 而不 linking。
  • Exception 處理可回復的 runtime failure；assertion 表達不應違反的程式內部假設。
  • Testing、code review 與 static analysis 提供不同證據；任一項通過都不等於零缺陷。
  • SSDF 四組實務是 Prepare、Protect、Produce、Respond；它們橫跨整個 secure SDLC。

1.GCC 驅動的四個主要階段

GCC Overall Options 將流程區分為 preprocessing、compilation proper、assembly、linking；-E、-S、-c 可在不同階段停止。Linking 再組合 object files 與所需 libraries。

  • -E 輸出 preprocessed source
  • -S 輸出 assembly
  • -c 產生 object file 而不執行 linking

2.錯誤處理不等於測試

Exception 是執行期異常轉移機制；assertion 表達開發者假設；tests 是可重複驗證行為的額外程式。

  • 不要用 exception 隱藏所有錯誤
  • Assertion 不應取代必要的 user-input validation
  • Test 要有可觀察 expected result

3.Verification 需要多種互補證據

Testing 執行程式觀察行為，code review 檢查設計與實作，automated analysis 尋找特定缺陷模式。NIST SSDF 要求依風險規劃 verification，而不是把單一測試結果視為 release 保證。

  • Verification criteria 應在 release 前明確
  • 工具結果仍需 triage false positives/negatives
  • 發現的漏洞應回饋到開發實務

4.SSDF 把安全責任放進整個生命週期

NIST SSDF 將實務分為 Prepare the Organization、Protect the Software、Produce Well-Secured Software、Respond to Vulnerabilities。重點是把安全活動整合進既有 SDLC，並保留可追溯證據與改善回饋。

  • Prepare 建立角色、流程與環境
  • Protect 維護程式碼與產物完整性
  • Respond 追蹤、修補並防止漏洞重現

5.考古題辨識：system development diagrams

本課只保留兩個由完整題面直接支持的辨識點：UML 是軟體工程的 general-purpose modeling language；class diagram 呈現類別結構，不是表示活動工期與專案進度的 Gantt chart。這兩點來自 past-paper stems，不歸因於 NIST SSDF，也不擴張成完整 UML 教程。

  • UML 是 modeling language，不是 programming language
  • Class diagram 不等於 project schedule
  • Decision tree、ERD、flowchart 回答不同問題

一起拆題目

範例 1：兩個 object files 分別定義與呼叫 calculate()，誰負責解析符號？

  1. Compiler/assembler 先產生 object files。
  2. 呼叫端留下 unresolved symbol。
  3. Linker 尋找定義並連結位址。

所以答案是：Linker 負責模組間符號解析與組合。

範例 2：測試全數通過，但 release 使用的第三方元件來源與版本無法追溯。可以只憑測試結果核准嗎？

  1. 測試只提供已執行情境的行為證據。
  2. 來源與版本不可追溯是 software integrity 與 vulnerability response 風險。
  3. 應補齊 provenance、風險評估與 release criteria 再決策。

所以答案是：不應只憑測試核准；依 SSDF 還需保護與追蹤 software components，保留可回應漏洞的證據。

這裡最容易選錯

  • 把 compiler、assembler 與 linker 當同一工具
  • 把 GCC driver 的階段當成所有語言唯一 runtime 模型
  • 用 assertion 取代使用者輸入驗證
  • 單一 verification activity 通過就宣稱系統無缺陷
  • 把 SSDF 當成只在 release 前執行一次的 checklist

換你快速判斷

先在心中作答，再展開答案。答不出來時，回頭找本課的對照關係。

1GCC 驅動流程的 compilation、assembly、linking 各產生什麼？

Compilation 產生 assembly，assembly 產生 object file，linking 組合 objects 與 libraries 成最終程式。

這是 GCC Overall Options 描述的主要階段；其他語言工具鏈不一定相同。

2GCC 的 -E、-S、-c 分別在哪個階段停止？

-E 停在 preprocessing；-S 停在 compilation 並輸出 assembly；-c 完成 assembly 產生 object file但不 linking。

沒有這些停止選項時，GCC driver 通常繼續後續階段直到 linking。

3Exception、assertion、test 各自的角色？

Exception 處理執行期異常；assertion 檢查內部假設；test 提供可重複輸入與 expected behavior。

三者互補，不應相互取代。

4為什麼 testing、code review 與 automated analysis 要互補？

三者觀察的缺陷面不同；單一 verification activity 通過，不能證明 software 沒有其他缺陷。

SSDF 要求依風險規劃 verification 並處理發現，而不是只追求單一工具全綠。

5NIST SSDF 的四組高階實務是什麼？

Prepare the Organization、Protect the Software、Produce Well-Secured Software、Respond to Vulnerabilities。

四組實務把安全責任整合到既有 SDLC，而不是只在 release 前做一次檢查。

6為什麼 secure software lifecycle 必須包含 vulnerability response？

Release 後仍可能發現漏洞；組織需接收、分析、修補並把根因回饋到後續開發實務。

SSDF 的 Respond to Vulnerabilities 強調持續改善，release 不是安全責任終點。

最後用考古題驗證

本課連結的題目都已通過可重現的技術覆核，可逐題練習與判分。

開始本課考古題練習

參考來源