iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 23
0
概述

審查實施是一種程式碼輔助的滲透測試,用於發現新產品或功能的實施中的任何安全錯誤。
這次審查是安全開發生命週期的關鍵組成部分,在這裡我們可以找到產品的大多數問題。

要求實施審核

理想情況下,一旦發布了版本,就應該要求進行實施審核。
這通常是功能完整的發行版,通常是在將應用程式部署到暫存環境中的情況下。
當請求實施審核時,請聯繫應用安全小組(AppSec)安排會議和審核範圍。

要求

當請求安全審查時,為了執行有效的安全審查,需要滿足一些要求。
在初次會議召開之前,應收集以下項目並放在適當的位置。

初始範圍

開發團隊應提供一個初始範圍,需要進行審查。
計劃進行審查時,開發團隊和AppSec將共同商定最終範圍。

指定聯繫點

開發團隊應該有一個指定的聯繫點來解決現場問題,並協助AppSec消除任何阻礙測試或審查該應用程式的障礙。

程式碼資料庫庫訪問

AppSec將需要訪問包含我們將測試的應用程式程式碼的資料庫。
如果應用程式具有多個資料庫,則應將所有相關資料庫提供給執行審核的AppSec工程師。

可測試的環境

為了對正在開發的新應用程式或功能進行全面的審查實施,必須要有一個可測試的環境。
在工作環境中,AppSec可以基於程式碼審查執行動態的,有針對性的測試。
測試環境應盡可能接近生產環境。

最好的情況是開發團隊可以提供資料庫和所有必要的依賴項以便在本地構建應用程式。
或者,可以在臨時環境中部署並訪問應用程式。
如果該服務已經啟用並已部署到生產中,則可以使用生產。
但是,測試生產服務將受到限制,具體取決於應用程式或服務對業務的重要性。

如果應用程式中有多個用戶角色,則應提供憑證,以便可以從多個方面針對授權問題對應用程式進行全面測試。

文件

應該提供運行或使用該應用程式所需的與該應用程式相關的任何文件。
這包括設計流程圖,路線圖以及開發期間生成的任何規範(例如API規範,數據規範)之類的內容。

設計審查工件

應該提供以前由AppSec執行的任何工件,流程圖和/或威脅模型。
如果設計中有任何重大更改可能與威脅模型不符,則應提供這些詳細信息。
如果未進行設計審查,則在初始會議期間將進行初步設計審查和威脅模型。

方法

AppSec將通過執行程式碼審查和執行手動測試來驗證應用程式中的潛在問題,從而對應用程式進行審查。
此外,將在程式碼上運行許多自動化工具,並且將手動驗證所有發現的問題。

時程

通常,審查實施將在一到兩週的時間內進行。
但是,審核的工作水平將取決於申請的規模和風險。
在計劃實施審核時,將在AppSec和開發團隊之間確定一個約定的時間。
如果執行設計評審的工程師遇到任何問題,將立即通知開發團隊,並確定進一步的步驟。

注意事項

會將申請與審核和合規團隊提出的任何要求進行比較。
在設計審查階段確定的任何其他安全要求也將在測試期間得到驗證。
將根據AppSec提供的特定於語言的[開發規範]審查程式碼。
AppSec維護的一組常見漏洞也可以用來檢查應用程式。
AppSec還將確保應用程式遵循[提供的設計原則]。

報告

在審核實施結束時,AppSec將安排會議以討論結果並回答開發團隊的任何問題。


上一篇
設計審核和威脅模型流程
下一篇
風險等級
系列文
安全軟體開發生命週期(SSDLC)學習筆記36
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言