延續昨天，今天來看一下 Post-build scanning 的功能。

Post-build scanning 功能

位於 Post-build scanning 分類下的功能有以下幾個

1. Dynamic application security testing (DAST)
2. API security testing
3. Operational container scanning
4. Fuzz testing

Dynamic application security testing (DAST)

DAST 是 Ultimate 付費功能。

由於 DAST 掃描的對象是你部署上線的 Website，所以它最麻煩的地方就是要先實現自動部署，接著再讓 CI/CD Pipeline 執行 DAST。所以你可以看到原廠的 Auto DevOps 功能，就有提供 Review apps 這個 Job，可以自動將你的應用程式部署至 K8s 環境中。

當然，如果你的環境比較傳統，你有一台固定的「測試機」在做各種測試，你也可以用比較單純的做法，例如單獨做一條 CI Pipeline，定期去對「測試機」跑 DAST。（只是這樣的做法，變成你還是將 Security 視為是一個單獨的任務，無法跟你的 DevOps Lifecycle 緊密的綁定在一起。）

最後原廠也有提醒，不要對你的 Production 環境做 DAST，因為它有可能會寫入資料或造成破壞，你總不會希望網站掛掉是因為自己人打自己人造成的吧？

API security testing

同是 Ultimate 付費功能。

API security testing 也是一種 DAST，因此你必須要將你想要測試的 API 部署上線才行。比較簡單的做法是將你的 API 程式 + 運行環境一起打包成 container image，然後用 GitLab CI 的 services: 啟動它，直接去執行 API security testing。

例如下面的範例

stages:
  - build
  # 必須要設置 dast 這個 stage 來執行 API security testing。
  - dast

# 將 API 與環境 build 為 docker image
build:
  stage: build
  services:
  - docker:26-dind
  image: docker:26
  script:
  - docker build -t $CI_REGISTRY_IMAGE/my-api .
  - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  - docker push $CI_REGISTRY_IMAGE/my-api

# 接著使用原廠的 CI Template
include:
  - template: API-Security.gitlab-ci.yml

# 覆蓋原廠的 CI Job，讓它運行前面 build 好的 docker image
api_security:
  # 利用 services: 以 container 運行 API。
  services:
  - name: CI_REGISTRY_IMAGE/my-api
    alias: myapi
  variables:
    ## APISEC_OPENAPI 要指向你的 OpenAPI specification file，
    ## API security testing 需要此檔案來認識你的 API。
    APISEC_OPENAPI: rest_target_openapi.json
    ## APISEC_TARGET_URL 則設定為你的 API URL
    APISEC_TARGET_URL: http://myapi:7777

OpenAPI specification file 可以是 .json 或 .yml，你也可以指向某個 URL，不一定要是檔案放在同一個 GitLab Project 中。

CI Job 的執行狀況會類似下圖，它會根據前面設定的 variables 去抓取 API 的資訊，然後執行測試。


產出的 report 則類似下圖。

如果想知道 GitLab 的 API security testing 會檢查哪些漏洞，可以查看這份原廠文件 API security testing vulnerability checks。

Operational container scanning

同樣也是 Ultimate 付費功能。

Operational container scanning，是透過 Trivy 與 Trivy K8S Wrapper 幫你檢查 K8s 環境中的 Container images 資安問題。

（擷圖來源：https://www.youtube.com/watch?v=Baqr7eDWris）

運作的 Workflow 如下擷圖

（擷圖來源：https://www.youtube.com/watch?v=Baqr7eDWris）

如果想要看實際運作的模樣，可以參考原廠的這個 DEMO 影片。

Fuzz testing

最後一個測試也是 Ultimate 付費功能，真的只能跟免費的使用者說聲抱歉了。

GitLab 目前提供 Web API Fuzz Testing 與 Coverage-guided fuzz testing 兩種測試。

Web API Fuzz Testing 比較容易理解，簡單來說就是你先將 API 部署上線，然後 CI Job 就會模擬那種沒事亂戳別人 API 的使用者，用各種奇怪的方式去戳你的 API，像是故意 POST 一些奇怪的字串，看看會不會造成問題。

而 Coverage-guided fuzz testing 的概念也是類同，只是這次針對的是應用程式，CI Job 一樣會送出各種奇怪的 inputs 值，看看你的程式是否會因此出現非預期的行為。Fuzz testing 背後會使用對應程式語言的 fuzzing engines，因此目前能使用這個功能的程式語言有限。

小結

很不巧的，今天的四個 Security 付費功能都是最貴的 Ultimate 才能使用功能，也是我不夠熟悉的功能，因此能跟大家分享的內容較少，如果內容有錯，還請各位大大幫忙指正，謝謝。

這四個功能都吻合今天的主題 Post-build scanning，也就是你的應用程式內容已經「固定」了，它將要離開 Artifacts 儲存庫，準備提供服務給使用者之前，再做更多的檢查；確保它不會因為部署上線就出現問題、確保它不會因為「環境」改變，就出現問題、確保它不會因為使用者故意亂操作，就出現問題。

只能說會出現這種測試與掃描工具，實在是再次體現了只要有任何的「異動」都有可能造成問題。

今天的內容就到這裡啦，明天見～

圖片來源 - 吉卜力工作室 https://www.ghibli.jp/works/kazetachinu/#&gid=1&pid=21

參考資料

• https://docs.gitlab.com/ee/user/application_security/dast/
• https://docs.gitlab.com/ee/user/application_security/api_security_testing/
• https://docs.gitlab.com/ee/user/clusters/agent/vulnerabilities.html
• https://docs.gitlab.com/ee/user/application_security/api_fuzzing/
• https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/