動的アプリケーションセキュリティテスト(DAST)

GitLab Ultimate10.4から導入されました

ホワイトペーパー「A Seismic Shift in Application Security(アプリケーション・セキュリティの激震)」をダウンロードして、組織を保護する方法をご覧ください

コードの静的なチェックを実行することは、コードのセキュリティを危険にさらす脆弱性を検出する最初のステップです。 しかし、いったんデプロイされると、アプリケーションは、クロスサイトスクリプティングや認証違反の欠陥のような、新たなカテゴリの攻撃の可能性にさらされます。 そこで、動的アプリケーションセキュリティテスト(Dynamic Application Security Testing)(DAST) 。

概要

GitLab CI/CDを使っている場合、Dynamic Application Security Testing(DAST)を使って、実行中のウェブアプリケーションの既知の脆弱性を分析することができます。既存の.gitlab-ci.yml ファイルにCI ジョブを含めるかAuto DevOpsが提供するAuto DASTを暗黙的に使うことで、DAST を利用することができます。

GitLab は DAST レポートをチェックし、見つかった脆弱性をソースブランチとターゲットブランチの間で比較し、マージリクエストに情報を表示します。

注意:この比較ロジックは、ターゲットブランチのベースコミットで実行された最新のパイプラインのみを使用します。 他のコミットでパイプラインを実行しても、マージリクエストには影響しません。

DAST Widget

検出された脆弱性をクリックすると、その詳細と影響を受ける URL を確認できます。

DAST Widget Clicked

Dynamic ApplicationSecurityTesting(DAST)は、人気のあるオープンソースツールOWASP Zed Attack Proxyを使用して、実行中のウェブアプリケーションの分析を行います。

デフォルトでは、DASTはZAP Baseline Scanを実行し、パッシブスキャンだけを行います。 アプリケーションをアクティブに攻撃することはありません。 しかし、DASTはアクティブスキャンも実行するように設定することができます。アプリケーションを攻撃し、より広範なセキュリティレポートを作成します。 レビューアプリと組み合わせると非常に便利です。

注:パイプラインは、SAST スキャンと DAST スキャンを含む複数のジョブで構成されることがあります。 何らかの理由でジョブの終了に失敗した場合、セキュリティダッシュボードには DAST スキャナの出力は表示されません。 例えば、DAST ジョブは終了したが SAST ジョブは失敗した場合、セキュリティダッシュボードには DAST の結果は表示されません。 アナライザは失敗時に終了コードを出力します。

ユースケース

アプリケーションの開発やテスト中に、実行中のウェブアプリケーションのセキュリティ脆弱性を自動的に見つけることができます。

要件

DASTジョブを実行するには、GitLab Runnerとdocker executorが必要です。

設定

GitLab 11.9以降では、DASTを有効にするには、GitLabインストールの一部として提供されているDAST.gitlab-ci.yml テンプレート含める必要があります。11.9より前のバージョンのGitLabでは、そのテンプレートで定義されているジョブをコピーして使用することができます。

.gitlab-ci.yml ファイルに以下を追加してください:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: https://example.com

DASTがスキャンするURLを定義するには2つの方法があります:

  1. DAST_WEBSITE 変数を設定します。

  2. これをenvironment_url.txt プロジェクトのルートにあるファイルに environment_url.txt追加します。 これはenvironment_url.txt 動的環境でのテストに最適 environment_url.txtです。 GitLab CI/CDパイプラインenvironment_url.txt 中に動的に作成されたアプリに対してDASTを実行するには、アプリにそのドメインをファイルに保持 environment_url.txtさせ、DASTは自動的にそのファイルを解析してスキャンターゲットを見つけます。 この例はAuto DevOps CI YAMLで見ることができます。

両方の値が設定されている場合は、DAST_WEBSITE の値が優先されます。

内部テンプレートは、CI/CDパイプラインにdast ジョブを作成し、プロジェクトのソースコードに脆弱性がないかスキャンします。

結果はDASTレポートアーティファクトとして保存され、後でダウンロードして分析することができます。 実装上の制限により、常に利用可能な最新のDASTアーティファクトを使用します。 裏側では、GitLab DAST Dockerイメージが指定されたURLに対してテストを実行し、脆弱性の可能性がないかスキャンするために使用されます。

デフォルトでは、DASTテンプレートはDAST Dockerイメージの最新のメジャーバージョンを使用します。DAST_VERSION 変数を使用すると、DASTの更新方法を選択できます:

  • メジャーバージョン(1など)にピン留めすることで、DAST の新機能や修正を自動的にアップデートします。
  • マイナーバージョン (1.6など) に固定することで、修正のみを更新します。
  • 特定のバージョン(1.6.4など)に固定することで、すべてのアップデートを防止します。

DASTの最新バージョンは、リリースページでご確認ください。

DASTスキャンの実行時

DAST.gitlab-ci.yml テンプレートを使用する場合、dast ジョブは以下の例のように最後に実行されます。DASTが最新のコードをスキャンしていることを確認するために、CI dastパイプラインはジョブのdast 前のいずれかのジョブでウェブサーバに変更を dastデプロイするdast 必要が dastあります。

stages:
  - build
  - test
  - deploy
  - dast

パイプラインが各実行で同じウェブサーバにデプロイするように設定されている場合、別のパイプラインがまだ実行されている間にパイプラインを実行すると、あるパイプラインが別のパイプラインのコードを上書きするという競合状態が発生する可能性があることに注意してください。 スキャン対象のサイトは、DASTスキャンの期間中は変更から除外する必要があります。 サイトへの変更はDASTスキャナからのみ行う必要があります。 スキャン中にユーザ、スケジュールされたタスク、データベースの変更、コードの変更、他のパイプライン、または他のスキャナがサイトに加えた変更は、不正確な結果につながる可能性があることに注意してください。

機密情報を隠す

GitLab 13.1で導入されました。

HTTP リクエストヘッダとレスポンスヘッダには、クッキーや作成者を含む機密情報が含まれている可能性があります。 デフォルトでは、以下のヘッダはマスクされます:

  • Authorization.
  • Proxy-Authorization.
  • Set-Cookie (値のみ)。
  • Cookie (値のみ)。

DAST_MASK_HTTP_HEADERS 変数を使用すると、値をマスクしたいヘッダーをリストアップすることができます。 ヘッダーをマスクする方法の詳細については、「DAST設定のカスタマイズ」を参照してください。

認証

DASTチェックを行う前にユーザーを認証することも可能です。

DAST が使用する認証情報を渡すためにマスク変数を作成します。 ユーザー名とパスワードのマスク変数を作成するには、「UI でカスタム変数を作成する」を参照してください。 ユーザー名変数のキーはDAST_USERNAMEでなければならず、パスワード変数のキーはDAST_PASSWORDでなければならないことに注意してください。

認証スキャンに関連するその他の変数は以下のとおり:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: https://example.com
  DAST_AUTH_URL: https://example.com/sign-in
  DAST_USERNAME_FIELD: session[user] # the name of username field at the sign-in HTML form
  DAST_PASSWORD_FIELD: session[password] # the name of password field at the sign-in HTML form
  DAST_AUTH_EXCLUDE_URLS: http://example.com/sign-out,http://example.com/sign-out-2 # optional, URLs to skip during the authenticated scan; comma-separated, no spaces in between

結果はDASTレポートアーティファクトとして保存され、後でダウンロードして分析することができます。 実装の制約上、常に最新のDASTアーティファクトを使用します。

危険:本番サーバに対して認証スキャンを絶対に実行しないでください。 認証スキャンが実行されると、認証されたユーザが実行できるあらゆる機能を実行する可能性があります。 これには、データの変更および削除、フォームの送信、リンクのたどりなどのアクションが含まれます。 テストサーバに対してのみ認証スキャンを実行してください。

フルスキャン

DASTは、同じターゲットウェブサイトに対してパッシブスキャンとアクティブスキャンの両方を含むZAPフルスキャンを実行するように設定することができます:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_FULL_SCAN_ENABLED: "true"

ドメインの検証

DASTジョブはどこででも実行できるため、誤って稼働中のウェブサーバを攻撃し、ダメージを与える可能性があります。 本番環境をダウンさせる可能性さえあります。 そのため、ドメイン検証を使用すべきです。

ドメイン認証はデフォルトでは必須ではありません。環境変数 DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED"true"に設定することで必須とすることができます。

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_FULL_SCAN_ENABLED: "true"
  DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED: "true"

ZAP フルスキャンはターゲットアプリケーションをアクティブに攻撃するため、DAST は事前にターゲット(通常、DAST_WEBSITE またはenvironment_url.txtで定義)に ping を送信します。

  • DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIREDfalse または未設定の場合、pingに対する応答にGitlab-DAST-Permissionヘッダーの値がdenyでない限り、スキャンは続行されます。
  • DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIREDtrueの場合、pingに対する応答にGitlab-DAST-Permission ヘッダーの値がallowでない限り、スキャンは終了します。

Rails、Django、Node (Express を使用) でレスポンスにGitlab-DAST-Permission ヘッダを追加する例をいくつか示します。

Ruby on Rails

Rubyon Railsでカスタムヘッダを追加する方法を示します:

class DastWebsiteTargetController < ActionController::Base
  def dast_website_target
    response.headers['Gitlab-DAST-Permission'] = 'allow'

    head :ok
  end
end
Django

Djangoでカスタムヘッダーを追加する方法を示します:

class DastWebsiteTargetView(View):
    def head(self, *args, **kwargs):
      response = HttpResponse()
      response['Gitlab-Dast-Permission'] = 'allow'

      return response
ノード

以下はNodeでカスタムヘッダーを追加する方法です(Expressを使用)

app.get('/dast-website-target', function(req, res) {
  res.append('Gitlab-DAST-Permission', 'allow')
  res.send('Respond to DAST ping')
})
プロキシ経由のドメイン検証ヘッダ

プロキシ経由でGitlab-DAST-Permission ヘッダーを追加することも可能です。

NGINX

以下の設定では、NGINXがリバースプロキシとして動作し、Gitlab-DAST-Permission ヘッダを追加します:

# default.conf
server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://test-application;
        add_header Gitlab-DAST-Permission allow;
    }
}
アパッチ

Apacheをリバースプロキシとして使ってGitlab-DAST-Permission ヘッダを追加することもできます。

そのためには、httpd.confに以下の行を追加します:

# httpd.conf
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost *:80>
  ProxyPass "/" "http://test-application.com/"
  ProxyPassReverse "/" "http://test-application.com/"
  Header set Gitlab-DAST-Permission "allow"
</VirtualHost>

このスニペットには、リモートプロキシとして動作し、Gitlab-DAST-Permission ヘッダを追加するように設定された完全なhttpd.conf ファイルが含まれています。

APIスキャン

GitLab Ultimate12.10で導入されました

スキャンのターゲットとしてAPI仕様を使用することは、APIをスキャンするためのURLの種を蒔くのに便利な方法です。 APIスキャンにおける脆弱性ルールは、通常のウェブサイトスキャンにおけるものとは異なります。

仕様書フォーマット

API スキャンは OpenAPI V2 と OpenAPI V3 仕様をサポートしています。これらの仕様はJSON またはYAMLを使って定義できます。

URLからのAPI仕様インポート

API仕様がURLでアクセス可能な場合は、そのURLを直接ターゲットとして渡すことができます。 仕様は、テスト対象のAPIと同じホスト上でホストされている必要はありません。

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_API_SPECIFICATION: http://my.api/api-specification.yml

ファイルからのAPI仕様インポート

API仕様がリポジトリにある場合、仕様のファイル名を直接ターゲットとして指定することができます。仕様ファイルは/zap/wrk ディレクトリにあることが期待されます。

dast:
  script:
    - mkdir -p /zap/wrk
    - cp api-specification.yml /zap/wrk/api-specification.yml
    - /analyze -t $DAST_WEBSITE
  variables:
    GIT_STRATEGY: fetch
    DAST_API_SPECIFICATION: api-specification.yml

フルスキャン

APIスキャンは完全スキャンをサポートしており、環境変数DAST_FULL_SCAN_ENABLEDを使用して有効にできます。ドメイン検証はAPI完全スキャンではサポートされていません。

ホストのオーバーライド

仕様では多くの場合、ドメイン名とポートを含むホストを定義します。 参照されるホストは、APIのレビュー・インスタンスのホストと異なる場合があります。 このため、不正なURLがインポートされたり、不正なホストでスキャンが行われたりする可能性があります。これらの値を上書きするには、環境変数DAST_API_HOST_OVERRIDE を使用します。

例えば、OpenAPI V3 の仕様にコンテナが含まれている場合:

servers:
  - url: https://api.host.com

API のテストバージョンがhttps://api-test.host.comで実行されている場合、以下の DAST 設定が使用できます:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_API_SPECIFICATION: http://api-test.host.com/api-specification.yml
  DAST_API_HOST_OVERRIDE: api-test.host.com

DAST_API_HOST_OVERRIDE 、URLでインポートされた仕様にのみ適用されることに注意してください。

ヘッダーを使った認証

リクエストヘッダ内のトークンは、APIリクエストを認証する方法としてよく使われます。 これはDAST_REQUEST_HEADERS 環境変数を使うことで実現できます。 ヘッダはDASTが行うすべてのリクエストに適用されます。

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_API_SPECIFICATION: http://api-test.api.com/api-specification.yml
  DAST_REQUEST_HEADERS: "Authorization: Bearer my.token"

DAST設定のカスタマイズ

Deprecation:GitLab 13.0から、onlyexceptの使用はサポートされなくなりました。テンプレートをオーバーライドする場合は、代わりに](../../../ci/yaml/README.md#rules) を使用する必要があります。

DAST 設定は、.gitlab-ci.ymlvariables パラメータを使用して、環境変数で変更することができます。 これらの変数は、available variablesに記載されています。

使用例:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_WEBSITE: https://example.com
  DAST_SPIDER_MINS: 120

テンプレートはパイプライン設定の前に評価されるので、変数の最後の記述が優先されます。

利用可能な変数

DASTは環境変数を使って設定することができます。

環境変数 タイプ 説明
SECURE_ANALYZERS_PREFIX URL アナライザーをダウンロードするDockerレジストリのベースアドレスを設定します。
DAST_WEBSITE URL スキャンするウェブサイトのURL。省略した場合は、DAST_API_SPECIFICATION を指定する必要があります。
DAST_API_SPECIFICATION URLまたは文字列 インポートするAPI仕様。仕様は、URLでホストされているか、/zap/wrk ディレクトリに存在するファイル名です。省略した場合は、DAST_WEBSITE を指定する必要があります。
DAST_AUTH_URL URL 対象ウェブサイトのサインイン HTML フォームを含むページの URL。DAST_USERNAMEDAST_PASSWORD がログインフォームと共に送信され、認証スキャンが作成されます。 API スキャンではサポートされていません。
DAST_USERNAME ウェブサイトで認証するユーザー名。
DAST_PASSWORD ウェブサイトで認証するためのパスワード。
DAST_USERNAME_FIELD サインインHTMLフォームのユーザー名フィールドの名前。
DAST_PASSWORD_FIELD サインインHTMLフォームのパスワードフィールドの名前。
DAST_MASK_HTTP_HEADERS マスクするリクエストヘッダとレスポンスヘッダのカンマ区切りリスト (GitLab 13.1 で導入されました)。 マスクするヘッダをすべて含める必要があります。デフォルトでマスクされるヘッダのリストを参照してください。
DAST_AUTH_EXCLUDE_URLS URL カンマ区切りで、間にスペースを入れないでください。 APIスキャンではサポートされていません。
DAST_FULL_SCAN_ENABLED ブーリアン ZAP ベースラインスキャンではなくZAP フルスキャンを実行するには、true に設定します。 デフォルト:false
DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED ブーリアン true に設定すると、DAST フルスキャンを実行する際にドメイン検証を要求します。 API スキャンには対応していません。 デフォルト:false
DAST_AUTO_UPDATE_ADDONS ブーリアン ZAPアドオンは、DAST Dockerイメージの特定のバージョンに固定されています。 スキャン開始時に最新バージョンをダウンロードするには、true に設定します。 デフォルト:false
DAST_API_HOST_OVERRIDE API 仕様ファイルで定義されたドメインをオーバーライドするために使用します。 例:example.com:8080
DAST_EXCLUDE_RULES カンマで区切られた脆弱性ルール ID のリストに設定し、スキャンレポートから除外します。 現在、除外されたルールは実行されますが、そのルールからのアラートは抑制されます。 ルール ID は番号で、DAST ログまたはZAPプロジェクトで確認できます。例えば、HTTP Parameter Override のルール ID は10026です。
DAST_REQUEST_HEADERS リクエストヘッダの名前と値をカンマで区切ったリストに設定します。 ヘッダはDASTが行うすべてのリクエストに追加されます、Cache-control: no-cache,User-Agent: DAST/1.0
DAST_DEBUG ブーリアン デバッグメッセージ出力を有効にします。 デフォルト:false
DAST_SPIDER_MINS 番号 スパイダースキャンの最大時間を分単位で指定します。無制限の場合は0 に設定します。 デフォルト:1 分、またはスキャンがフルスキャンの場合は無制限です。
DAST_HTML_REPORT スキャン終了時に書き込まれるHTMLレポートのファイル名。
DAST_MARKDOWN_REPORT スキャン終了時に書き込まれるMarkdownレポートのファイル名。
DAST_XML_REPORT スキャン終了時に書き込まれるXMLレポートのファイル名。
DAST_INCLUDE_ALPHA_VULNERABILITIES ブーリアン アルファのパッシブおよびアクティブスキャンルールを含めるには、true に設定します。 デフォルト:false
DAST_USE_AJAX_SPIDER ブーリアン true に設定すると、従来のスパイダーに加えて AJAX スパイダーを使用します。JavaScript を必要とするサイトのクロールに便利です:false
DAST_ZAP_CLI_OPTIONS 例えば、-Xmx3072m は、Java の最大メモリ割り当てプール・サイズを設定します。
DAST_ZAP_LOG_CONFIGURATION ZAPサーバーの追加のlog4jプロパティのセミコロンで区切られたリストを設定します。 例えば、以下のようになります、log4j.logger.org.parosproxy.paros.network.HttpSender=DEBUG

DASTコマンドラインオプション

すべてのDAST設定が環境変数で利用できるわけではありません。 すべての可能なオプションを確認するには、以下の設定を実行してください。 利用可能なコマンドラインオプションはジョブログに出力されます:

include:
  template: DAST.gitlab-ci.yml

dast:
  script:
    - /analyze --help

次に、script コマンドを上書きして、適切な引数を渡す必要があります。 たとえば、パッシブスキャンを遅延させるには、オプション-Dを使用します。 次の構成では、パッシブスキャンを 5 分間遅延させます:

include:
  template: DAST.gitlab-ci.yml

dast:
  script:
    - export DAST_WEBSITE=${DAST_WEBSITE:-$(cat environment_url.txt)}
    - /analyze -D 300 -t $DAST_WEBSITE

カスタムZAProxy設定

ZAProxyサーバーには、多くの有用な設定可能値が含まれています。-config の多くのキー/値は文書化されていませんが、可能性のあるキーの未検証リストがあります。 これらのオプションはDASTではサポートされておらず、使用するとDASTスキャンが壊れる可能性があることに注意してください。TOKEN 、Authorizationヘッダー値を書き換える方法の例を以下に示します:

include:
  template: DAST.gitlab-ci.yml

variables:
  DAST_ZAP_CLI_OPTIONS: "-config replacer.full_list(0).description=auth -config replacer.full_list(0).enabled=true -config replacer.full_list(0).matchtype=REQ_HEADER -config replacer.full_list(0).matchstr=Authorization -config replacer.full_list(0).regex=false -config replacer.full_list(0).replacement=TOKEN"

プロジェクトのリポジトリのクローン

DASTジョブは実行時にプロジェクトのリポジトリが存在する必要はないので、デフォルトではGIT_STRATEGYnoneに設定されています。

DASTジョブのデバッグ

DASTジョブには2つの実行プロセスがあります:

  • ZAPサーバー。
  • ZAPサーバーを起動、制御、停止する一連のスクリプト。

スクリプトのデバッグモードは、DAST_DEBUG 環境変数を使用して有効にすることができます。これは、ジョブのトラブルシューティング時に役立ち、スキャンの何パーセントが完了したかを示すステートメントを出力します。 変数の使用の詳細については、DASTテンプレートのオーバーライドを参照してください。

ZAPサーバーのデバッグモードは、DAST_ZAP_LOG_CONFIGURATION 環境変数を使って有効にすることができます。 次の表は、設定できる値の例と、それらがログに記録される出力に与える影響の概要です。 セミコロンで区切って複数の値を指定することができます。

ログ設定値 効果
log4j.rootLogger=DEBUG すべてのデバッグ・ロギング文を有効にします。
log4j.logger.org.apache.commons.httpclient=DEBUG ZAP サーバーによるすべての HTTP リクエストとレスポンスをログに記録します。
log4j.logger.com.crawljax=DEBUG Ajax Crawlerのデバッグ・ロギング文を有効にします。
log4j.logger.org.parosproxy.paros=DEBUG ZAP サーバー・プロキシ・デバッグ・ロギング文を有効にします。
log4j.logger.org.zaproxy.zap=DEBUG 一般的なZAPサーバー・コードのデバッグ・ロギング文を有効にします。

オフライン環境でのDASTの実行

インターネットを通じた外部リソースへのアクセスが制限されている、制限されている、または断続的な環境にある自己管理型 GitLab インスタンスでは、DAST ジョブを正常に実行するためにいくつかの調整が必要です。 詳細については、オフライン環境を参照してください。

オフラインDASTサポートの要件

オフライン環境でDASTを使用するには、以下のものが必要です:

**pull policy 注意:**GitLab Runnerのデフォルトのalways、つまりRunnerはローカルに利用可能なDockerイメージがある場合でも、GitLabコンテナレジストリからDockerイメージをプルしようとします。ローカルに利用可能なDockerイメージのみを使用したい場合は、オフライン環境でGitLab Runnerのpull_policyif-not-presentに設定することができます。 しかし、CI/CDパイプラインで更新されたスキャナを使用することができるため、オフライン環境でない場合はプルポリシーの設定を](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy) に維持することをお勧めします。

GitLab DASTアナライザーイメージをDockerレジストリで利用可能にします。

DASTの場合は、registry.gitlab.com 、以下のデフォルトDASTアナライザーイメージをローカルのDockerコンテナレジストリにインポートします:

  • registry.gitlab.com/gitlab-org/security-products/dast:latest

DockerイメージをローカルのオフラインDockerレジストリにインポートするプロセスは、ネットワークセキュリティポリシーに依存します。 外部リソースをインポートしたり、一時的にアクセスしたりすることができる承認済みのプロセスについては、IT担当者にご相談ください。 これらのスキャナは定期的に新しい定義に更新されるため、定期的な更新を自分で行うことができるかどうかを検討してください。

Dockerイメージをファイルとして保存・転送する方法の詳細については、Dockerのドキュメントdocker save,docker load,docker export,docker importを参照してください。

ローカルDASTアナライザを使用するためのDAST CIジョブ変数の設定

以下の設定を.gitlab-ci.yml ファイルに追加します。image を、ローカルの Docker コンテナレジストリにホストされている DAST Docker イメージを参照するように置き換える必要があります:

include:
  - template: DAST.gitlab-ci.yml
dast:
  image: registry.example.com/namespace/dast:latest

DAST ジョブは、DAST アナライザのローカルコピーを使用して、インターネットに接続しなくてもコードをスキャンし、セキュ リティレポートを生成できるようになります。

あるいは、変数SECURE_ANALYZERS_PREFIX を使って、dast イメージのベースレジストリアドレスを上書きすることもできます。

オンデマンド・スキャン

  • GitLab 13.2 で導入されました
  • フィーチャーフラグで有効・無効を切り替えることができ、デフォルトでは無効になっています。
  • GitLab.comでは無効になっています。
  • プロジェクトごとに有効/無効を設定できます。
  • GitLabセルフマネージドインスタンスで使うには、GitLab管理者に頼んで有効にしてもらいましょう。

パッシブDASTスキャンは、DevOpsライフサイクルの外側で、対象ウェブサイトに対してオンデマンドで実行することができます。 これらのスキャンは、常にプロジェクトのデフォルトブランチまたはmaster ブランチに関連付けられ、結果はプロジェクトダッシュボードで確認できます。

DAST On-Demand Scan

オンデマンドスキャンの有効化または無効化

On-Demand Scansは開発中であり、本番環境ではまだ使用できません。デフォルトでは無効になっている機能フラグの後ろにデプロイされています。GitLab RailsコンソールにアクセスできるGitLab管理者は、インスタンスでOn-Demand Scansを有効にしたり無効にしたりすることができます。

有効にするには:

# Instance-wide
Feature.enable(:security_on_demand_scans_feature_flag)
# or by project
Feature.enable(:security_on_demand_scans_feature_flag, Project.find(<project id>))

無効化するには:

# Instance-wide
Feature.disable(:security_on_demand_scans_feature_flag)
# or by project
Feature.disable(:security_on_demand_scans_feature_flag, Project.find(<project id>))

レポーター

DASTツールはデフォルトでJSON形式のレポートファイルを出力しますが、Markdown、HTML、XML形式のレポートを生成することもできます。 詳細については、DASTレポートのスキーマを参照してください。

スキャンされたURLのリスト

DASTがスキャンを完了すると、マージリクエストページにスキャンされたURLの数が表示されます。詳細を表示]をクリックすると、スキャンされたURLのリストを含むウェブコンソール出力が表示されます。

DAST Widget

JSON

注意:JSONレポートのアーティファクトはDASTの公開APIではなく、その形式は将来変更されることが予想されます。

DASTツールは常にgl-dast-report.json というJSONレポートファイルを出力します。サンプルレポートはDASTリポジトリにあります。

JSONレポートには、並べて使用される2つのデータ形式があります:

  • いずれは非推奨となる独自のZAPフォーマット。
  • 将来的にデフォルトとなる共通フォーマット。

その他のフォーマット

レポートは、Markdown、HTML、XMLで生成することもできます。 これらは、以下の設定を使用してアーティファクトとして公開することができます:

include:
  template: DAST.gitlab-ci.yml

dast:
  variables:
    DAST_HTML_REPORT: report.html
    DAST_MARKDOWN_REPORT: report.md
    DAST_XML_REPORT: report.xml
  artifacts:
    paths:
      - $DAST_HTML_REPORT
      - $DAST_MARKDOWN_REPORT
      - $DAST_XML_REPORT
      - gl-dast-report.json

セキュリティダッシュボード

セキュリティダッシュボードは、グループ、プロジェクト、パイプラインに存在するすべてのセキュリティ脆弱性の概要を把握するのに適した場所です。セキュリティダッシュボードについてもっと読む。

最先端の脆弱性定義

alpha betaDASTは betaデフォルトで定義をbeta使用 beta alphaしますalphaalpha定義をalpha 要求 alphaするには、以下の設定のようにDAST_INCLUDE_ALPHA_VULNERABILITIES 環境変数を使用します:

include:
  template: DAST.gitlab-ci.yml

variables:
  DAST_INCLUDE_ALPHA_VULNERABILITIES: true

脆弱性との対話

脆弱性が見つかったら、その脆弱性と対話することができます。 脆弱性と対話する方法については、こちらをお読みください。

脆弱性データベースの更新

脆弱性データベースの更新の詳細については、メンテナンステーブルを確認してください。

DASTの最適化

デフォルトでは、DASTはパイプライン内の以前のジョブによって定義されたすべてのアーティファクトをダウンロードします。DASTジョブがテスト対象のURLや以前のジョブで作成された他のファイルを定義するためにenvironment_url.txt に依存していない場合は、アーティファクトをダウンロードしないことをお勧めします。アーティファクトのダウンロードを回避するには、gitlab-ci.yml ファイルに以下を追加します:

dast:
   dependencies: []

トラブルシューティング

メモリ不足

デフォルトでは、DASTが依存するZAProxyには、ホスト上の総メモリの25%に相当するメモリが割り当てられています。 スキャン中、ZAProxyはほとんどの情報をメモリ上に保持するため、大規模なアプリケーションのスキャン中にDASTがメモリ不足になる可能性があります。 この結果、以下のエラーが発生します:

[zap.out] java.lang.OutOfMemoryError: Java heap space

幸いなことに、DAST_ZAP_CLI_OPTIONS 環境変数を使用することで、DAST で使用可能なメモリ量を簡単に増やすことができます:

include:
  - template: DAST.gitlab-ci.yml

variables:
  DAST_ZAP_CLI_OPTIONS: "-Xmx3072m"

ここでは、DAST に 3072 MB が割り当てられています。-Xmx 以降の数字を必要なメモリ量に変更してください。