在安全開發生命週期的範疇下，軟體開發的各個階段型塑了生命週期下的環節，由需求分析出發的應用系統安全要求事項 (A.8.26)、系統分析與設計的安全系統架構及工程原則 (A.8.27)、系統開發的安全程式設計 (A.8.28)、系統測試時的開發及驗收中的安全測試 (A.8.29)、系統開發委外的委外開發 (A.8.30)、環境隔離的開發、測試與運作環境之區隔 (A.8.31) 以及妥善管理資訊以用於測試的測試資訊 (A.8.33)，都涵括在安全開發生命週期內，所以原則上只實作了這些控制措施，大體上就能滿足安全開發生命週期 (A.8.25) 的要求了。

應用系統安全需求 (Application Security Requirements) 要求組織在系統開發的需求分析階段時，就應用系統需求 (無謂是功能性或非功能性) 進行分析，辨識可能的風險來源，在這個階段較容易辨識的有幾種：

1. 契約要求事項，若是由客戶委託開發時。
2. 需求的合規性要求事項，例如符合特定標準或是法規，最常見的就是系統是否會蒐集、處理與利用個人資料 (個資法範疇)。
3. 需求本身描述具備資訊安全特性 (如機密、完整、可用、不可否認等)。
4. 處理的資料是否具敏感性 (如組織業務或營運機密)。
5. 處理於基於規劃與設計期間察覺與辨識到的風險所施加的控制措施。

組織需將辨識出的風險來源、風險類型轉換為應用系統資訊安全需求，並列入開發週期進行實作；除了來自於客戶或內部需求外，組織對軟體開發的品質基準 (Software Quality Baseline) 也可以作為資訊安全需求來源之一，例如組織的軟體必須符合國家資通安全防護基準中級以上之要求，此時資通安全防護基準中級的要求也會是應用系統資訊安全要求之一。

在軟體的規劃與設計過程中，有可能會因為執行相關活動 (例如威脅塑模) 發現潛在的風險，在處理這些風險的過程中會施加控制措施，這些控制措施要併入應用系統安全需求內，確保風險控制措施在軟體開發時會進行實作，也作為測試期間確認的依據。

安全系統架構及工程原則 (Secure System Architecture and Engineering Principles) 要求組織需制訂系統開發所應遵循的原則 (Principles)，並且在整個開發過程中作為要求事項；例如在開發Web應用程式時，組織需要求開發團隊落實必要的控制作為，包含資料輸入檢查合法性、權限最小化、過濾輸入資料、加密系統設定、加密敏感資料、蒐集監測數據以及保留日誌 (log) 以作為日後的事故調查證據等，這些作為都需要在開發過程中予以實作，並且以適當機制驗證其有效性 (例如源碼檢測、弱點掃瞄等)。

安全程式設計 (Secure Coding) 則是要求組織在系統開發期間，要求開發人員落實安全的開發習慣，這點通常會以程式開發準則 (Code Standard) 來規範，安全程式設計會與安全系統架構與工程原則整合在一起，由原則給予指引，再由安全程式設計予以落實；系統開發過程中經常也會使用到套件 (Package)，像是一個大型的前端框架 (如React或Angular) 使用的NPM套件可能就會有數百個以上，安全程式設計要求組織需對套件進行有效管理，以及早發現如授權範疇風險 (如GPL強制開源)、套件本身具有弱點或是套件已不再持續更新等問題，組織可運用SBOM (Software BOM) 進行管理，以及早確認並處理來自套件的風險。

開發及驗收中的安全測試 (Security testing in development and acceptance) 要求組織要在進行系統測試或是驗收測試時，應執行相關的安全測試，常見的如弱點掃瞄與源碼檢測，部份組織或較大規模專案，可能會加上滲透測試 (Penetration Test) 或由第三方團隊進行檢測等，都是可行的作法；就軟體開發廠商而言，在系統出廠前至少做完一次完整的安全性檢測是必要的品質控制措施，也是給客戶的安全承諾；常見的如OWASP TOP 10及業界關注的重大風險都可以由弱點掃瞄或源碼檢測發現，於交付與驗收至少要檢附無中高風險弱點的報告，以作為測試執行的證明。

若安全需求無法使用弱點掃瞄、源碼檢測這類方法測試時，應制訂測試方法、測試準則與測試過程的說明，並據以執行且留存證據。

委外開發 (Outsourcing development) 則是要求組織在將系統開發委外時，應落實必要的監管控制，其中也會包含組織控制措施中的供應者相關項目 (如A.5.19供應者關係之資訊安全、A.5.20於供應者合約中闡明資訊安全、A.5.21於資通訊科技供應鏈中管理資訊安全，及A.5.22供應者服務之監控、審查與變更管理)，組織需要參照這些控制項目實作委外開發之監管措施，例如：

1. 在合約中之授權、原始碼所有權、智慧財產權及保密條款。
2. 將組織的安全要求寫入合約內，要求委外開發供應者遵循。
3. 對開發成果的資訊安全與組織安全要求的符合性提供證據。
4. 於開發過程中進行必要的監督活動，確認供應者有依照組織要求執行。

開發、測試與運作環境之區隔 (Separation of development, test and production environment) 要求組織必須將生產環境與開發、測試環境隔離開來，由於系統開發除了會變更程式碼外，也有可能會對其執行環境進行變更 (如平台組態設定)，或是因開發與測試需要，會直接進入資料庫修改資料，若未將開發、測試環境隔離開，那麼在開發活動中會對生產環境造成潛在的不確定性影響 (如無法得知開發人員會不會突然「手殘」刪掉了重要的資料、例如之前發生過的「刪庫跑路」事件)，對組織營運會是極大的風險，因此必須要將生產環境完全獨立出來，開發與測試活動只能在專屬於開發與測試環境執行，當開發、測試與生產環境區隔開時，自動化部署過程就相形重要了，實作必要的自動化部署可以降低人為失誤，並加速部署的速度，有效提升組織的運作效率。

與開發、測試與生產環境區隔相關的一項議題就是，當軟體是在持續演進階段 (非全新開發) 時，通常會在維護與改進過程中分析由業務端回報的議題，而要重現問題 (reproduce) 就可能會需要當時的狀態資訊，因此可能會由備份倒回測試環境，但若是完全使用生產環境的資料，則可能會發生資料誤用的風險，例如在測試時誤將訊息發送給使用者 (因為測試資料沒有經過適當處理就被拿來使用)，或是不小心使用到了個人資料而發送行銷訊息 (該使用者可能早已聲明不接收行銷訊息) 而引發個資法的觸發疑慮，因此測試資訊 (Test information) 的管理必須要落實於系統開發過程中，例如在測試之前先進行資料清洗，移除敏感資訊或對敏感資訊進行預處理 (如資料遮罩、去識別化等)，以降低測試資訊可能的風險。

當然不僅是系統開發，在採購系統或委外開發，由委外供應者進行系統建置及驗收的階段時，也有可能會發生前述的誤報或誤用問題，所以在測試之前都需確認測試資訊狀態是必要執行的工作。