何を見るチェックか
SAST は Static Application Security Testing の略で、 コードを動かさずに、書かれた内容から問題を探すやり方のことです。
Scorecard は、直近の Pull Request に静的解析ツールの実行記録が付いているか、 または設定ファイルがあるかを調べます。
認識される代表的なツールは次のとおりです。
- CodeQL（GitHub の
github/codeql-action） - Snyk
- Sonar / SonarCloud
- Qodana
- PySA（Python）
- 一部の pre-commit フック
実行の記録が Pull Request に付いていた割合が点になります。
点が低いと何を意味するか
点が低いということは、自動でコードを検査する仕組みが確認できない、という意味です。
静的解析が拾えるのは、たとえば次のような書き方です。
- 入力をそのまま SQL やコマンドに渡している
- 例外を握りつぶして処理を続けている
- 使われていない変数や到達しない分岐
- 暗号関連の古い書き方
人のレビューでも見つかるものですが、機械は毎回同じ精度で見ます。 Code-Review と CI-Tests が どちらも薄いプロジェクトで、さらにこれも無い場合、 変更を検査する仕組みが1つも無いということになります。
誤解しやすい点
Scorecard が認識できるツールの一覧は限られています。ここが最大の落とし穴です。
たとえば、次のような構成は静的解析として十分に機能しますが、 Scorecard では評価されないか、されにくいものです。
- PHPStan / Psalm（PHP の静的解析）
- mypy / Ruff / Bandit（Python）
- golangci-lint / staticcheck（Go）
- ESLint の型安全系ルール + TypeScript の
strict - Clippy（Rust）
日常的に最も使われている型検査やリンタが、この項目にはほとんど入っていません。 つまり、実際にはかなり厳しく検査しているプロジェクトが 0点 になります。
また逆に、CodeQL を有効にしただけで一度も指摘を直していなくても 10点 になります。
もう1つ。SAST は「脆弱性が無いこと」を示しません。 静的解析が得意なのは既知のパターンの検出で、 設計上の問題や、複数のファイルにまたがるロジックの誤りは苦手です。
この項目は、他の項目より「点数と実態のずれ」が大きいと考えてください。
採用する側が確認すべきこと
-
リポジトリの CI 設定を実際に開く。
.github/workflows/を見れば、型検査やリンタが走っているかが分かります。 Scorecard が認識しないだけで、実は厳しく検査していることは珍しくありません。 -
言語ごとの定番ツールがあるかを見る。 PHP なら
phpstan.neon、Python ならpyproject.tomlの[tool.ruff]や[tool.mypy]、 Go なら.golangci.ymlといった設定ファイルの有無が実質的な指標になります。 -
リポジトリの
Securityタブを見る。 CodeQL が有効なら、検出結果と対応状況が見えることがあります。 -
この項目単独では判断しない。 CI-Tests、Code-Review と 合わせて「検査の仕組みが何かしらあるか」を見るのが実用的です。
メンテナーなら何を改善できるか
Scorecard の点を上げたいだけであれば、CodeQL を有効にするのが最短です。
GitHub のリポジトリ設定 Security → Code scanning → Set up から数クリックで入ります。
name: CodeQL
on:
push:
branches: [main]
pull_request:
schedule:
- cron: '0 3 * * 1'
permissions:
contents: read
security-events: write
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: github/codeql-action/init@v3
with:
languages: javascript # 対応言語を指定
- uses: github/codeql-action/analyze@v3
ただし、点のためだけに入れることは勧めません。 指摘を誰も見ないなら、CI の時間を使うだけになります。
実質的に価値があるのは、その言語で標準的な静的解析を CI に入れ、 失敗したらマージできない状態にすることです。 PHPStan や mypy を厳しめの設定で通すほうが、 CodeQL を有効にして放置するより、コードの質にはずっと効きます。
両方やるのが理想ですが、順番としては後者が先です。