CASAのTier2のセキュリティ評価を静的スキャンで完了させた備忘録

はじめに

Google の制限付きスコープに該当する API を使用するために、この記事で言及するセキュリティ評価というものを受ける必要がありました。

Google の制限付きスコープに該当する API の OAuth 検証の体験談は以下の記事で紹介しています。
https://zenn.dev/makumaaku/articles/google_restricted_api

実績

現状Tier2のセキュリティ評価を２度経験しています。

• 2023年7月
• 2023年12月

4 ~ 5ヶ月ほどしか経っていないのですが、審査を通すまでの手順が若干変化していました。

対象読者

• Tier2 のセキュリティ評価を受ける必要のある方
• Google の制限付きスコープに該当する API を使用予定の方

セキュリティ評価が必要な理由

制限付きスコープに該当する GoogleAPI を使用する場合は、年に 1 回セキュリティ評価を受ける必要があります。
Google の OAuth 検証の最終段階としてセキュリティ評価を受けるようにメールで通達されました。

For final approval, you are required to complete a Tier 2 verified self security assessment and be issued a Letter of Validation for your application by your due date {1 October, 2023}. This assessment is required annually and applies to all apps requesting restricted scopes. To learn more, please visit the CASA website.

CASA(Cloud Application Security Accessment)の web ページを参考に約 3 ヶ月以内にセキュリティ評価を完了させるように指示を受けました。

The due date is to complete your assessment and receive a Letter of Validation. It can take up to 6 weeks to complete the CASA assessment, so it is important to initiate your assessment as early as possible.

最大 6 週間かかるから早めに始めたほうが良いという忠告も。

どうしたらセキュリティ評価を通過できるのか

以下の Tier2 のセキュリティ評価には以下の 3 つのプロセスがあり、全てを完了させる必要があります。

• Initial Review
• Detailed Review
• Final QA and Completion

これらのプロセスはCASA ポータルというサイトを使って進めていきます。

審査の流れ

審査フローイメージ図

Initial Review

• Fortifyスキャン or 静的スキャン or 動的スキャンにてセキュリティの脆弱性のチェック。スキャン結果の提出
• 初回アンケートの提出

Detailed Review

Initial Review の内容を深掘りされるようです。
僕たちは特に何の質問ややり取りもなく、Detailed Review を通過しました。
Initial Reviewで提出したアンケートの情報の不備などを確認されるくらいのイメージです。
セキュリティ的に問題ありと回答してしまうと、評価担当者ともう少し細かなやり取りが発生する可能性があります。

Final QA and Completion

最終確認の段階です。
何か確認事項があれば聞かれるのかもしれませんが、こちらも何のやり取りもなく通過しました。

アプリのスキャンについて

(現在は古くなっているため参考になりません↓)
https://appdefensealliance.dev/casa/tier-2/ast-guide?hl=ja

~~ スキャンガイドに従い、~~

• 静的スキャン
• 動的スキャン
• カスタムスキャン
  のどれかを選択します。

静的スキャン、動的スキャンが CASA の推奨ツールだったようなので、僕たちは静的スキャンを選択しました。

注意

※こちらの公式ドキュメントっぽいものは古くなっているため、CASAポータルで示されている内容が最新かと思います。
2023年12月現在ではFortifyスキャンというものが推奨のスキャン方法となっています。

2023年12月時点では、参考画像のようにサポート言語が限られています。
僕たちが審査を通したものはFlutter(Dart)プロジェクトであったため、以前推奨されていた静的スキャンで審査を進めることができるように評価担当者に連絡をしました。

動的スキャンを使用している参考記事

https://qiita.com/rbrf7321/items/a2812f634bf5c1a74ae0

静的スキャンの具体的な手順

Fluid Attacks というオープンソース CLI を使用し、アプリのソースコードを自動でスキャンすることで、セキュリティの脆弱性がある箇所を指摘してもらえます。

基本的には以下の静的スキャンのガイドに沿って進めれば OK です。
※2023年12月時点では以下の記事の情報は古くなっているため参考になりません。
https://appdefensealliance.dev/casa/tier-2/ast-guide/static-scan?hl=ja

代わりに以下を参考にすると良いです。
https://docs.fluidattacks.com/tech/scanner/standalone/casa/

僕が対応した当時は手順通りにやってもエラーになり、以下のGithubのissueを参考に解消しました。
https://github.com/NixOS/nixpkgs/issues/240509#issuecomment-1791722919

consfig.yamlの作成

参考までにconfig.yamlの中身を載せておきます。
必要に応じて中身を修正してください。

# 参考: https://docs.fluidattacks.com/tech/scanner/standalone/casa/
# 分析対象のリポジトリ名。名前は任意。
namespace: hogehoge

# EN(英語)と ES(スペイン語)の2言語がサポートされています(2023/11月時点)
language: EN

# 静的スキャン(tatic Application Security Testing)を有効にする。
# サポートされている言語のソースコードをチェックできる
sast:
  # スキャンしたいファイル、フォルダの指定
  include:
    - .

# スキャン結果の出力に関する設定
output:
  file_path: ./Fluid-Attacks-Results.csv
  format: CSV

# checksを指定しない場合は、全検証項目のスキャンになります。
# 公式的にchecksを指定しないことが推奨されています。
# checks:
#   - F001
#   - F004

静的スキャン結果の CSV ファイルの出力

審査対象プロジェクトのルートディレクトリにて

1. Docker イメージをプルしてくる

# <arch>には、amd64 or arm64が入ります
docker pull ghcr.io/fluidattacks/makes/<arch>:latest

Intel製のMacはamd64,Apple Silicon製のMacはarm64になるかと思います。

2. スキャン結果の出力

# <arch>には、amd64 or arm64が入ります
# --privilegedはgithubのissueを参考に付与しています。
docker run --privileged -v .:/working-dir ghcr.io/fluidattacks/makes/<arch>:latest m gitlab:fluidattacks/universe@trunk /skims scan ./config.yaml

以下のようなログが出ていれば成功です。

[INFO] An output file has been written: /usr/scan/Fluid-Attacks-Results.csv
[INFO] Summary: No vulnerabilities were found in your targets.

───────────────────────────────── 🎯 Success! ──────────────────────────────────

上記のコマンド実行後には<project>/SAST-Results.csvが生成されます。

具体的に指摘された項目

2023 年時点の静的スキャンでは以下の 2 点を指摘されました。

• AndroidManifest ファイルの allowBackup に false を指定する必要がある。(参考)
• Firebase Emulator Suiteで起動する local 環境用 の google-services.json に(ダミーの)apiKey が含まれてしまっている。(実在しない環境のものなのでコミットしていましたが、指摘を受けました。)

上記の 2 点を修正後に、セキュリティの脆弱性が 0 の状態で 、CASA のポータルサイトからSAST-Results.csvを提出しました。

追記

別件対応時はAndroidManifestファイル内にてusesCleartextTrafficを明示的にfalseに指定していないことを指摘されました。

android:usesCleartextTraffic="false"

参考
https://docs.fluidattacks.com/criteria/vulnerabilities/403/

最後に

セキュリティ評価の前の Google による OAuth 検証はとても厳しいものでしたが、Tier2 のセキュリティ評価は 2 ~ 3 週間ほどで完了できるものでした。
最大 6 週間かかると脅されていたのでほっとひと安心でした。
この記事がどなたかの参考になれば幸いです。
(Fortifyスキャンも経験せねば..)

Twitter では Flutter を中心とする技術関連の情報を発信しています！
https://twitter.com/marksaito4

セキュリティ評価の対応など、お仕事の依頼は以下のメールアドレスまでご連絡をよろしくお願いします。
mark.saito@jp-gx.com