我們有 2 個程式碼分析器、4 個動態測試工具、我們自己的製程和 250 個腳本。 並不是說這一切都是目前流程所需要的，但是一旦開始實施DevSecOps，就必須堅持到底。
。 角色創作者：Justin Roiland 和 Dan Harmon。
什麼是 SecDevOps？ DevSecOps 怎麼樣？ 有什麼區別？ 應用程式安全性—它是關於什麼的？ 為什麼經典方法不再有效？ 知道所有這些問題的答案 尤里·沙巴林 的 劍魚安全。 Yuri 將詳細回答所有問題，並分析從經典應用安全模型到 DevSecOps 流程過渡的問題：如何正確地將安全開發流程整合到 DevOps 流程中而不破壞任何內容，如何經歷主要階段安全測試的內容、可以使用哪些工具、它們有何不同以及如何正確配置它們以避免陷阱。
關於演講者： 尤里·沙巴林 - 公司首席安全架構師 劍魚安全。 負責SSDL的實施，將應用程式分析工具整體整合到統一的開發和測試生態系統中。 7年資訊安全經驗。 曾在 Alfa-Bank、Sberbank 和 Positive Technologies 工作，該公司開發軟體並提供服務。 在 ZerONights、PHDays、RISSPA、OWASP 國際會議上發表演講。
應用程式安全性：它是關於什麼的？
應用安全 - 這是負責應用程式安全的安全部分。 這不適用於基礎設施或網路安全，而是適用於我們編寫的內容和開發人員所做的工作 - 這些是應用程式本身的缺點和漏洞。
方向 - 安全開發生命週期 - 由微軟開發。 該圖顯示了規範的SDLC模型，其主要任務是安全性參與開發的每個階段，從需要到發布和生產。 微軟意識到這個行業存在太多的錯誤，而且數量越來越多，必須採取一些措施來解決它，他們提出了這種方法，這已經成為規範。
應用程式安全和 SSDL 的目的並不是像人們普遍認為的那樣檢測漏洞，而是預防漏洞的發生。 隨著時間的推移，微軟的規範方法得到了改進、發展，並引入了更深入、更詳細的研究。
規範的 SDLC 在各種方法中都非常詳細 - OpenSAMM、BSIMM、OWASP。 方法不同，但整體相似。
在成熟度模型中建立安全性
我最喜歡它 BSIMM - 。 此方法的基礎是將應用程式安全流程分為 4 個領域：治理、智慧、SSDL 接觸點和部署。 每個領域有 12 個實踐，代表 112 個活動。
112項活動中的每一項都有 3個成熟度級別：初級、中級、高級。 你可以逐節學習所有 12 個實踐，選擇對你來說重要的事情，弄清楚如何實現它們並逐漸添加元素，例如靜態和動態程式碼分析或程式碼審查。 你寫下一個計劃，並根據它冷靜地工作，作為實施所選活動的一部分。
為什麼選擇 DevSecOps
DevOps 是一個通用的大型流程，必須考慮安全性。
最初 涉及安全檢查。 在實踐中，安全團隊的數量比現在少得多，他們不是作為流程的參與者，而是作為控制和監督機構，對其提出要求並在發布結束時檢查產品的品質。 這是一種經典方法，其中安全團隊遠離開發並且不參與該過程。
主要問題是資訊安全與開發脫節。 通常這是某種資訊安全電路，包含 2-3 個大型且昂貴的工具。 每六個月一次，需要檢查的源代碼或應用程式到達，每年一次生成 。 所有這些導致行業的發布日期被推遲，並且開發人員面臨自動化工具的大量漏洞。 不可能將所有這些都拆卸和修復，因為前六個月的結果還沒有整理出來，但這裡是新的一批。
在我們公司的工作過程中，我們看到各個領域、各行業的安全都明白，是時候跟上發展的腳步了—— 。 DevSecOps 範式與每次發布和迭代中的敏捷開發方法、實施、支持和參與完美契合。
過渡到 DevSecOps
安全開發生命週期中最重要的字是 “過程”。 在考慮購買工具之前，您必須了解這一點。
僅僅將工具整合到 DevOps 流程中是不夠的，流程參與者之間的溝通和理解很重要。
人更重要，而不是工具。
通常，安全開發流程的規劃從選擇和購買工具開始，並以嘗試將該工具整合到當前流程中結束，這仍然是嘗試。 這會導致不幸的後果，因為所有工具都有自己的特點和限制。
一個常見的情況是，安全部門選擇了一個好的、昂貴的、功能廣泛的工具，然後找開發人員將其整合到流程中。 但它並沒有成功——該流程的結構使得已購買的工具的限制不適合當前的範式。
首先，描述您想要什麼結果以及流程是什麼樣的。 這將有助於理解工具和安全在過程中的作用。
從已經在使用的東西開始
在購買昂貴的工具之前，請先看看您已有的工具。 每個公司都有開發的安全需求，有檢查，有滲透測試——為什麼不把這一切轉化為大家都能理解、方便的形式呢？
通常，要求是放在架子上的紙質塔木德。 有一個案例，我們來到一家公司看流程，要求看軟體的安全要求。 處理這個問題的專家花了很長時間尋找：
- 現在，在筆記中的某處有一條該文檔所在的路徑。
結果一週後我們就收到了文件。
對於要求、檢查和其他內容，請建立一個頁面，例如 合流 - 這對每個人來說都很方便。
重新格式化您現有的內容並使用它來開始使用會更容易。
使用安全冠軍
通常，在擁有 100-200 名開發人員的普通公司中，會有一名安全專家負責執行多項職能，但實際上沒有時間檢查所有內容。 即使他盡力了，他一個人也不會檢查開發生成的所有程式碼。 對於這種情況，我們提出了一個概念— .
安全冠軍是開發團隊中對產品安全有興趣的人員。
安全冠軍是進入開發團隊的切入點，同時也是安全佈道者。
通常，當安全專家來到開發團隊並指出程式碼中的錯誤時，他會收到一個令人驚訝的答案：
- 你是誰？ 我是第一次見到你。 對我來說一切都很好 - 我的高級朋友在代碼審查中給了我“申請”，我們繼續！
這是一種典型的情況，因為對開發人員在工作和程式碼審查中不斷互動的前輩或隊友有更多的信任。 如果安全冠軍而不是安全官員指出錯誤和後果，那麼他的話就會更有分量。
此外，開發人員比任何安全專家都更了解他們的程式碼。 對於一個在靜態分析工具中擁有至少 5 個項目的人來說，通常很難記住所有的細微差別。 安全冠軍了解他們的產品：什麼與什麼相互作用以及首先關注什麼 - 他們更有效。
因此，請考慮實施安全冠軍並擴大安全團隊的影響力。 這對冠軍本人也很有用：在新領域進行專業發展，擴大技術視野，提陞技術、管理和領導技能，增加市場價值。 這是社會工程的一些要素，是開發團隊中你的「眼睛」。
測試階段
說20%的努力產生80%的結果。 這 20% 是可以而且應該自動化的應用程式分析實踐。 此類活動的範例是靜態分析 - SAST，動態分析- 達斯特 и 開源控制。 我將更詳細地告訴您有關活動以及工具、將它們引入流程時我們通常會遇到哪些功能以及如何正確執行的資訊。
工具的主要問題
我將強調與所有文書相關並需要注意的問題。 我將更詳細地分析它們，以免進一步重複。
分析時間長。 如果從提交到發布全部測試和組裝需要30分鐘，那麼資訊安全檢查就需要一天的時間。 所以沒有人會放慢這一進程。 考慮到這個特徵並得出結論。
高水平的假陰性或假陽性。 所有產品都是不同的，都使用不同的框架和自己的程式設計風格。 在不同的程式碼庫和技術上，工具可能會顯示不同等級的假陰性和假陽性。 所以看看裡面到底是什麼 您的 公司和為 你的 應用將顯示出良好且可靠的結果。
不與現有工具集成。 從與您已經使用的工具的整合角度來看待工具。 例如，如果您有 Jenkins 或 TeamCity，請檢查這些工具與該軟體的集成，而不是與您不使用的 GitLab CI 的整合。
定制缺乏或過於複雜。 如果一個工具沒有 API，那為什麼還需要它？ 介面中可以完成的所有操作都應該可以透過 API 取得。 理想情況下，該工具應該能夠自訂檢查。
沒有產品開發路線圖。 發展不會停滯不前，我們總是使用新的框架和功能，將舊程式碼重寫為新語言。 我們希望確保我們購買的工具能夠支援新的框架和技術。 因此，了解產品具有真實且正確的資訊非常重要 發展。
流程功能
除了工具的特性外，還要考慮開發過程的特性。 例如，阻礙發展是一個常見的錯誤。 讓我們看看還應該考慮哪些其他功能以及安全團隊應該注意什麼。
為了不錯過開發和發布截止日期，創建 不同的規則 和不同的 表演塞子 — 在有漏洞的情況下停止建置流程的標準 — 針對不同環境。 例如，我們知道當前分支轉到開發站或UAT，這意味著我們不會停下來說：
“你這裡有漏洞，你不能再往前走！”
此時，有必要告訴開發者，有需要注意的安全問題。
漏洞的存在並不妨礙進一步測試：手動、整合或手動。 另一方面，我們需要以某種方式提高產品的安全性，以便開發人員不會忽略他們認為安全的東西。 因此，有時我們會這樣做：在展位上，當它被推出到開發環境時，我們只是通知開發：
- 夥計們，你們有問題，請注意它們。
在UAT階段我們再次顯示有關漏洞的警告，在發布階段我們說：
- 夥計們，我們警告過你們好幾次了，你們什麼也沒做——我們不會讓你們這麼做的。
如果我們談論程式碼和動態，那麼有必要僅顯示和警告那些功能和剛剛在此功能中編寫的程式碼的漏洞。 如果開發人員將按鈕移動了 3 個像素，我們告訴他那裡有 SQL 注入，因此需要緊急修復，這是錯誤的。 只看現在寫的內容以及應用程式的更改。
假設我們有某種功能缺陷 - 應用程式不應該工作的方式：錢沒有轉移，當您單擊按鈕時沒有轉換到下一頁，或者產品沒有加載。 安全缺陷 - 這些是相同的缺陷，但不是在應用程式操作方面，而是在安全方面。
並非所有的軟體品質問題都是安全問題。 但所有的安全問題都與軟體品質有關。 謝里夫·曼蘇爾，Expedia。
由於所有漏洞都是相同的缺陷，因此它們應該與所有開發缺陷位於同一位置。 因此，忘掉那些無人閱讀的報告和可怕的 PDF 吧。
當我在一家開發公司工作時，我收到了一份靜態分析工具的報告。 我打開它，感到震驚，煮了咖啡，翻閱了 350 頁，合上它，繼續工作。 大報告都是死報告。 通常它們無處可去，信件被刪除、遺忘、遺失，或企業表示接受風險。
怎麼辦？ 我們只是將發現的已確認的缺陷轉換成方便開發的形式，例如，我們將它們放入Jira中的backlog中。 我們對缺陷進行優先排序，並按優先順序消除它們，以及功能缺陷和測試缺陷。
靜態分析-SAST
這是針對漏洞的程式碼分析。，但它與 SonarQube 不一樣。 我們不只是檢查圖案或風格。 分析中使用了多種方法：根據漏洞樹，根據 ，透過分析設定檔。 這就是程式碼本身的全部內容。
此方法的優點: 在開發的早期階段識別程式碼中的漏洞當還沒有支架或現成的工具時，並且 增量掃描能力：掃描有變化的一段程式碼，並且只掃描我們目前正在做的功能，這樣就減少了掃描時間。
缺點 - 這是缺乏對必要語言的支援。
必要的集成， 在我主觀看來，這應該在工具中：
- 整合工具：Jenkins、TeamCity 和 Gitlab CI。
- 開發環境：Intellij IDEA、Visual Studio。 對於開發人員來說，更方便的是，不要瀏覽仍然需要記住的難以理解的介面，而是在自己的開發環境中查看他在工作場所發現的所有必要的整合和漏洞。
- 程式碼審查：SonarQube 和手動審查。
- 缺陷追蹤器：Jira 和 Bugzilla。
下圖展示了靜態分析的一些最佳代表。
重要的不是工具，而是流程，因此開源解決方案也適合測試流程。
SAST Open Source不會發現大量漏洞或複雜的資料流，但在建置流程時可以而且應該使用它們。 他們有助於了解如何建立流程、誰將回應錯誤、誰將報告以及誰會報告。 如果您想執行建置程式碼安全性的初始階段，請使用開源解決方案。
如果您正處於旅程的開始並且什麼都沒有：沒有 CI、沒有 Jenkins、沒有 TeamCity，那麼如何整合？ 讓我們考慮整合到流程中。
CVS 級別集成
如果您有 Bitbucket 或 GitLab，則可以進行等級集成 .
按事件 - 拉取請求，提交。 您掃描程式碼，建置狀態會顯示安全性檢查是通過還是失敗。
聯繫我們。 當然，回饋總是需要的。 如果你只是兼職做安全工作，把它放在一個盒子裡，沒有告訴任何人任何事情，然後在月底拋出一堆錯誤 - 這是不正確的，也不好。
與程式碼審查系統集成
曾經，我們在多個重要專案中擔任技術 AppSec 用戶的預設審閱者。 根據新程式碼中是否發現錯誤或沒有錯誤，審閱者將拉取請求的狀態設定為「接受」或「需要工作」 - 要麼一切正常，要麼指向確切需要改進的內容的連結需要改進。 為了與即將投入生產的版本進行集成，如果未通過資訊安全測試，我們啟用了合併禁止。 我們將其包含在手動程式碼審查中，並且該過程中的其他參與者看到了該特定過程的安全狀態。
與 SonarQube 集成
許多人都有 在代碼品質方面。 這裡也是一樣 - 您只能為 SAST 工具製作相同的門。 會有同樣的接口，同樣的質量門，只有它會被調用 安全門。 而且，如果您有一個使用 SonarQube 的流程，您可以輕鬆整合其中的所有內容。
CI 等級的集成
這裡的一切也很簡單：
- 與自動測試相當，單元測試。
- 按發展階段劃分：開發、測試、生產。 可能包括不同的規則集或不同的失敗條件：停止組裝、不停止組裝。
- 同步/非同步啟動。 我們正在等待安全測試是否結束。 也就是說，我們只是啟動它們並繼續前進，然後我們就得到一切是好還是壞的狀態。
這一切都在一個完美的粉紅色世界。 現實生活中沒有這樣的事情，但我們努力。 執行安全檢查的結果應該與單元測試的結果類似。
例如，我們進行了一個大型項目，並決定現在使用 SAST 對其進行掃描 - 好的。 我們將這個專案推入了 SAST，它為我們帶來了 20 個漏洞，但我們透過堅定的決定決定一切都很好。 000 個漏洞是我們的技術債。 我們將把債務放在一個盒子裡，我們將慢慢清理它，並將錯誤添加到缺陷追蹤器中。 讓我們僱用一家公司，自己做所有事情，或讓安全冠軍幫助我們 - 技術債將會減少。
新程式碼中所有新出現的漏洞都必須以與單元或自動測試中的錯誤相同的方式消除。 相對而言，組裝開始，我們運行它，兩次測試和兩次安全測試都失敗了。 好的 - 我們去了，看看發生了什麼，修復了一件事，修復了另一件事，下次運行它 - 一切都很好，沒有出現新的漏洞，沒有測試失敗。 如果此任務比較深入並且您需要很好地理解它，或者修復漏洞會影響底層的大部分內容：錯誤已添加到缺陷追蹤器中，則會對其進行優先排序並進行修正。 不幸的是，世界並不完美，測試有時會失敗。
安全門的一個例子是質量門的類似物，就程式碼中漏洞的存在和數量而言。
我們與 SonarQube 整合 - 插件已安裝，一切都非常方便和酷。
與開發環境集成
整合選項：
- 在提交之前從開發環境執行掃描。
- 查看結果。
- 結果分析。
- 與伺服器同步。
這就是從伺服器接收結果的樣子。
在我們的開發環境中 只是出現一個附加項目，通知您在掃描過程中偵測到此類漏洞。 您可以立即編輯程式碼，查看建議並 。 這一切都位於開發人員的工作場所，這非常方便 - 無需點擊其他連結並查看其他內容。
開源
這是我最喜歡的話題。 每個人都使用開源程式庫——當你可以使用一個所有東西都已經實現的現成庫時，為什麼還要寫一堆拐杖和自行車呢？
當然，這是事實，但庫也是由人編寫的，它們也包含一定的風險，並且還存在定期或不斷報告的漏洞。 因此，應用安全的下一步就是對開源元件的分析。
開源分析 - OSA
該工具包括三個大階段。
搜尋庫中的漏洞。 例如，該工具知道我們正在使用某個庫，並且在 或者錯誤追蹤器中存在與此版本的庫相關的一些漏洞。 當您嘗試使用它時，該工具會發出警告，指出該庫存正在漏洞，並建議您使用其他沒有漏洞的版本。
許可證純度分析。 這裡還不是特別流行，但是如果您在國外工作，那麼有時您可能會因使用無法使用或修改的開源元件而被徵稅。 根據許可圖書館的政策，我們不能這樣做。 或者，如果我們修改它並使用它，我們應該發布我們的程式碼。 當然，沒有人願意發布他們產品的程式碼，但您也可以保護自己免受這種情況的影響。
分析工業環境中使用的組件。 讓我們想像一個假設的情況，我們終於完成了開發並發布了微服務的最新版本。 他在那裡生活得非常美好——一週、一個月、一年。 我們不收集，我們不進行安全檢查，一切似乎都很好。 但突然間，發布兩週後，我們在工業環境中的這個特定建置中使用的開源元件中出現了一個嚴重漏洞。 如果我們不記錄我們使用的內容和位置，那麼我們根本就不會看到此漏洞。 一些工具能夠監控業界目前使用的庫中的漏洞。 這非常有用。
產品特點：
- 不同的發展階段有不同的政策。
- 監控工業環境中的組件。
- 組織內圖書館的控制。
- 支援各種構建系統和語言。
- Docker 映像分析。
一些從事開源分析的行業領導者的例子。
唯一免費的就是這個 來自 OWASP。 您可以在第一階段打開它，看看它是如何工作的以及它支援什麼。 基本上，這些都是雲端產品或本地產品，但在其基礎背後，它們仍然被發送到互聯網。 他們發送的不是您的庫，而是他們計算的雜湊值或他們自己的值以及指紋到他們的伺服器，以接收有關漏洞存在的資訊。
流程整合
圖書館週邊控制，它們是從外部來源下載的。 我們有外部和內部儲存庫。 例如，Event Central 運行 Nexus，我們希望確保我們的儲存庫中不存在處於「嚴重」或「高」狀態的漏洞。 您可以使用 Nexus Firewall Lifecycle 工具來設定代理，以便切斷此類漏洞並且不會最終出現在內部儲存庫中。
整合到 CI 中。 與自動測試、單元測試處於同一級別，並劃分為開發階段：開發、測試、生產。 在每個階段，您都可以下載任何庫，使用任何東西，但如果存在「關鍵」狀態的困難，也許值得在發佈到生產階段引起開發人員的注意。
與工件集成：Nexus 和 JFrog。
整合到開發環境中。 您選擇的工具應該與開發環境整合。 開發人員必須能夠從其工作場所存取掃描結果，或能夠在提交 CVS 之前自行掃描和檢查程式碼是否有漏洞。
光碟整合。 這是我非常喜歡的一個很酷的功能，我已經討論過它 - 監控工業環境中新漏洞的出現。 它的工作原理是這樣的。
我們有 公共元件儲存庫 — 一些外部工具，以及我們的內部儲存庫。 我們希望它只包含可信任組件。 代理請求時，我們檢查下載的庫是否有漏洞。 如果它屬於我們制定的某些政策並且必須與開發相協調，那麼我們不會上傳它並提示使用另一個版本。 因此，如果庫中有一些非常關鍵和不好的東西，那麼開發人員將不會在安裝階段收到該庫 - 讓他使用更高或更低的版本。
- 在建置時，我們會檢查是否有人遺漏了任何損壞的東西，所有組件都是安全的，並且沒有人在隨身碟上帶來任何危險的東西。
- 我們在儲存庫中只有受信任的元件。
- 部署時，我們再次檢查套件本身：war、jar、DL或Docker映像，以確保其符合原則。
- 當進入產業時，我們監控工業環境中正在發生的事情：出現或不出現嚴重漏洞。
動態分析 - DAST
動態分析工具與之前所說的一切都有根本的不同。 這是對使用者使用應用程式的操作的一種模仿。 如果這是一個網頁應用程序，我們發送請求，模擬客戶端的工作，點擊前面的按鈕，從表單發送人工資料：引號，括號，不同編碼的字符，以查看應用程式如何運作和處理外部資料。
同一系統可讓您檢查開源中的模板漏洞。 由於 DAST 不知道我們正在使用哪個開源程式碼，因此它只是拋出「惡意」模式並分析伺服器的回應：
- 是的，這裡有反序列化問題，但這裡不是。
這其中存在很大的風險，因為如果您在測試人員使用的同一個工作台上進行安全測試，則可能會發生不愉快的事情。
- 應用程式伺服器網路負載高。
- 沒有集成。
- 能夠更改所分析的應用程式的設定。
- 沒有必要的技術支援。
- 設定困難。
當我們最終啟動 AppScan 時，我們遇到了一個情況：我們花了很長時間嘗試訪問該應用程序，獲得了 3 個帳戶，並且很高興 - 我們終於可以檢查所有內容了！ 我們啟動了掃描，AppScan 做的第一件事就是進入管理面板，刺穿所有按鈕，更改一半數據，然後用其完全殺死伺服器 -要求。 開發與測試說：
- 夥伴們，你們在開玩笑嗎？！ 我們幫你算賬，你擺攤！
考慮可能的風險。 理想情況下，準備一個單獨的測試台來測試資訊安全，至少以某種方式與環境的其他部分隔離，並有條件地檢查管理面板，最好是在手動模式下。 這是滲透測試——我們現在不考慮的剩餘工作百分比。
值得考慮的是，您可以將其用作負載測試的模擬。 在第一階段，您可以打開具有 10-15 個執行緒的動態掃描儀，看看會發生什麼，但正如實踐所示，通常沒有什麼好處。
一些我們經常使用的資源。
值得強調 對於任何安全專業人員來說都是一把「瑞士刀」。 大家都在用，而且非常方便。 企業版的新試用版本現已發布。 如果早些時候它只是一個帶有插件的獨立實用程序，那麼現在開發人員終於製作了一個大型伺服器，可以從中管理多個代理程式。 這很酷，我建議你嘗試一下。
流程整合
整合過程非常順利且簡單： 安裝成功後開始掃描 展位申請及 集成測試成功後掃描.
如果整合不起作用或存在存根和模擬函數，那麼它就毫無意義且無用——無論我們發送什麼模式，伺服器仍然會以相同的方式回應。
- 理想情況下，有一個單獨的測試台。
- 測驗前，記下登入順序。
- 管理系統的測試僅是手動的。
過程
對一般過程以及每個工具的具體工作進行了一些概括。 所有應用程式都是不同的 - 一個應用程式使用動態分析效果更好，另一個應用程式使用靜態分析，第三個應用程式使用開源分析、滲透測試或其他東西，例如，事件 .
每個過程都需要控制。
要了解流程的工作原理以及可以改進的地方，您需要從您可以獲得的所有內容中收集指標，包括生產指標、工具指標和缺陷追蹤器指標。
任何資訊都有幫助。 有必要從不同的角度來看看這個或那個工具在哪裡更好地使用，在哪裡過程特別下垂。 可能值得查看開發回應時間，以了解在哪裡可以根據時間改進流程。 數據越多，從頂層到每個流程的細節可以建構的部分就越多。
由於所有靜態和動態分析器都有自己的 API、自己的啟動方法、原理，有些有調度程序，有些則沒有 - 我們正在編寫一個工具 應用安全協調器，它允許您從產品創建整個流程的單一入口點並從一個點進行管理。
經理、開發人員和安全工程師可以透過一個入口點查看正在運行的內容、配置和運行掃描、接收掃描結果以及提交要求。 我們正在嘗試擺脫文書工作，將所有內容轉化為人類的內容，以供開發使用- Confluence 上的狀態和指標頁面、Jira 或各種缺陷追蹤器中的缺陷，或整合到CI 中的同步/非同步流程中/光碟。
關鍵要點
工具不是主要的。 首先思考整個流程 - 然後實施工具。 這些工具很好，但價格昂貴，因此您可以從流程開始，在開發和安全之間建立溝通和理解。 從安全的角度來看，沒有必要「停止」一切；從發展的角度來看，如果有什麼高兆超危的東西，那就需要消除，而不是對問題視而不見。
產品質量 - 共同的目標 安全與發展並舉。 我們只做一件事，努力確保一切正常運轉，並且不存在聲譽風險或財務損失。 這就是為什麼我們提倡 DevSecOps、SecDevOps 方法來改善溝通並提高產品品質。
從你已有的開始：需求、架構、部分檢查、訓練、指南。 沒有必要立即將所有實踐應用到所有項目中—— 迭代地移動。 沒有單一的標準—— 實驗 並嘗試不同的方法和解決方案。
資訊安全缺陷與功能缺陷是等號的.
自動化一切那個移動。 凡是不動的，就移動它並使其自動化。 如果某件事是手工完成的，那麼它就不是這個過程的一個好的部分。 也許值得對其進行審查並使其自動化。
如果IS團隊規模較小— 使用安全冠軍.
也許我所說的話不適合你，你會想出一些你自己的東西——這很好。 但 根據您的流程要求選擇工具。 不要看社群怎麼說，說這個工具不好，這個工具好。 也許您的產品恰恰相反。
對工具的要求。
- 低水平誤報。
- 充足的分析時間。
- 易於使用。
- 整合的可用性。
- 了解產品開發路線圖。
- 客製化工具的可能性。
Yuri 的報告被評為 DevOpsConf 2018 最佳報告之一。要了解更多有趣的想法和實際案例，請於 27 月 28 日至 XNUMX 日前往斯科爾科沃 之內 。 更好的是，如果您準備好分享您的經驗，那麼 報告截止日期為 21 月 XNUMX 日。
來源： www.habr.com