Continuous Security 學習筆記

Where
6 min readDec 17, 2019

--

除了怎麼寫程式、設計商業邏輯、怎麼部屬開發好的應用程式一直到去把整個開發的流程拉成一條條的管線做到自動化,在整個 DevOps 中,其實還有很重要的一環,也就是 Security 的部分,我們可能常常忽略它的重要性,但卻也是開發中最重要的一個環節(同時也非常的複雜),今年參加的 DevOps Day 關於 Security 的 Session 也不少,可見其日趨重要,但是關於在學習這塊上面,自己一直不能很上手,對於資訊安權這塊的了解真的甚少,於是想說那就先從基礎學起吧!

Continuous security validation should be added at each step from development through production to help ensure the application is always secure. The goal of this approach is to switch the conversation with the security team from approving each release to approving the CI/CD process and having the ability to monitor and audit the process at any time.

Source : https://docs.microsoft.com/en-us/azure/devops/migrate/security-validation-cicd-pipeline?view=azure-devops&viewFallbackFrom=vsts

在各個不同的軟體開發週期中,所需要做的 Security 把關也各有不同,要使用的工具也大有相異,以下針對上圖來做個比較詳細的介紹吧!

IDE / Pull Request

從工程師 commit code,對於程式碼品質的把關就此開始,而在這個階段可以透過引入以下項目來確保你的程式碼。

Static Code Analysis 靜態程式碼分析

IDE 中的靜態程式碼分析為首要關卡,以卻保在後續 CI/CD 的環節中不會有惡意漏洞產生。

Pull Request

通過 branch policy 機制的啟動,需要提交拉取請求(pull request, PR)才能啟動合併,而 PR 應要求進行代碼審查(code review),儘管這是一項手動操作,但卻十分重要,可用來提前找出程式碼中隱含的問題,及早發現及早修正。

Work item linking

在提交程式碼並進行合併的同時,要求團隊成員需連接到相對應的 work item,以利審核進行程式碼修改的原因

Continuous Integration 持續集成

CI 應作為先前討論的拉取請求(PR-CI)流程的一部分執行。 通常,兩次運行之間的主要區別在於 PR-CI 中不需要執行 CI 中建構程式碼及打包的步驟,而是運行靜態程式碼分析測試,以確保程式碼遵循安全性的所有規則。

Static Code Analysis 靜態程式碼分析 及 OSS Vulnerability Scan

以下幾項工具可在此階段使用:

  • Visual Studio Code Analysis and the Roslyn Security Analyzers
  • Checkmarx
  • BinSkim:可針對二進位的檔案做分析而不需要原始碼
  • Fortify
  • White Source

以上的許多工具都可以整合到 Azure DevOps 的 pipeline 中,請至 Visual Studio Market Place 查看。

而關於各個工具的細節,可以參考底下連結: https://devblogs.microsoft.com/devops/team-services-october-extensions-roundup-rugged-devops/

Unit Test

工程師在完成新的功能更新後便同時也完成相對應的單元測試腳本,在CI的同時自動的去執行單元測試腳本,更能有效的確保開發團隊間在開發不同新功能時不會導致其他團的已開發完成的項目失效。

部屬至 Dev、Test 環境

驗證程式碼質量並將應用程式部署到開發測試後,該過程應驗證正在運行的系統是否含有安全漏洞。

Penetration test 滲透測試

針對駭客有可能的攻擊手法對於應用程式做測試,根據等級的不同可主要分為主動測試(Active Penetration Test)及被動測試(Passive Penetration Test)。

被動測試並不直接與目標應用程式接觸,從旁來發掘應用程式本身的漏洞,其可以快速的被執行。 而主動測試則是用於模擬駭客常用來攻擊網站的技術,使用大量不同的組合,以查看目標應用程式如何反應, 主動測試需要較長的執行時間,通常建議在半夜運行。使用的工具:

  • OWASP ZAP

OWASP 是一個全球性的非營利組織,提供免費的滲透測試工具,其提供 API或 docker image 的服務,可以將此工具與部屬的環境整合。OWASP ZAP 可以安裝在任何機器上,或將 image 整合至 Azure Container Services 中使用,以達到 image 的自動更新、同時啟動多個 instance 來掃描企業內的多個應用程式。

Application CI / CD pipeline 和運行時間較長的 Nightly OWASP ZAP pipeline 步驟

通常,在白天運行的 CI/CD Pipeline 建議在幾分鐘內變運行完成。並可透過在夜間執行較細部掃描的功能。如 OWASP ZAP 可以搜索網站並運行完整的Active Scan,以評估可能的漏洞。

Infrastructure Scan

除了驗證應用程式本身之外,還應驗證基礎結構以檢查是否存在任何漏洞。 若使用如同 Azure 等的公有雲服務,都有提供相對應的工具來協助你的基礎結構。如 Azure 中就有提供像是 Azure Security Center 或是 Azure Policy 等等。

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

No responses yet

Write a response