ツールに「任せて」安心していませんか？SASTを武器にするための現場の極意
「SAST（静的解析ツール）を入れておけばインジェクション攻撃は防げる」――そう信じているなら、今すぐその認識を改めたほうがいい。
現場で数々のインシデントを見てきた私から言わせれば、SASTは「優秀な番犬」だが、「飼い主（エンジニア）」が適当な指示を出していれば、番犬はただ吠えるだけで、泥棒を家の中に招き入れてしまう。今日は、SQLインジェクションやOSコマンドインジェクションをSASTで根絶するための、現場のリアルな戦術を共有しよう。
—
1. なぜ「ツール」だけでは攻撃を防げないのか？
多くの開発現場でSASTが形骸化するのは、「警告の多さ」に辟易して、開発者がアラートを無視し始めるからだ。
攻撃者は、ツールが検知しやすい「露骨な脆弱性」を狙うのではない。ビジネスロジックの隙間や、フレームワークの薄いラッパー関数を潜り抜けるようなコードを狙ってくる。SASTを導入するゴールは、「エラーをゼロにする」ことではなく、「脆弱性が混入したコードを、デプロイ前にCI/CDのパイプラインで自動的に突き返す（Fail Fast）」という鉄の掟を作ることにある。
—
2. 実践的防御：インジェクションを根絶する実装
インジェクションの根本原因は「データの解釈を誤らせること」にある。これを防ぐには、コードレベルでの「型」の強制が最も有効だ。
【PHP】PDOによるプリペアドステートメントの強制
「文字列連結」でSQLを作るのは、自宅の鍵を玄関先に置いておくのと同じだ。
// 悪い例：変数をそのまま結合している（SASTも即座に反応するはずだが、すり抜けることも多い）
// $db->query(“SELECT FROM users WHERE id = ” . $_GET[‘id’]);
// 良い例：プリペアドステートメントを使用
try {
$stmt = $pdo->prepare(‘SELECT FROM users WHERE id = :id’);
// 型を明示することで、悪意ある文字列を単なる値として扱う
$stmt->bindValue(‘:id’, $_GET[‘id’], PDO::PARAM_INT);
$stmt->execute();
$user = $stmt->fetch();
} catch (PDOException $e) {
// エラーログは出すが、詳細なSQLエラーを画面に出してはいけない（情報漏洩の隙になる）
error_log($e->getMessage());
}
【Node.js】OSコマンド実行の回避
child_processでのOSコマンド実行は、入力値を直接渡せば即死級の脆弱性になる。
const { execFile } = require(‘child_process’);
// 悪い例：exec() はシェルを経由するため、セミコロンでコマンド連結される
// exec(“ls ” + userInput);
// 良い例：execFile を使い、引数を配列として分離する
// これにより、入力値がコマンドとして解釈されることを防ぐ
execFile(‘/bin/ls’, [userInput], (error, stdout, stderr) => {
if (error) {
console.error(‘実行エラー:’, error);
return;
}
console.log(stdout);
});
—
3. CI/CDパイプラインへの統合：SASTを「門番」にする
GitHub ActionsやGitLab CIにSASTを組み込む際、最も重要なのは「ビルドを失敗させる閾値の設定」だ。
例えば、SonarQubeやSemgrepを導入する際、以下のような設定をsemgrep.ymlに加えることで、脆弱な関数をコミットした瞬間に開発者の手を止めることができる。
.github/workflows/sast.yml のイメージ
jobs:
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Semgrep Scan
run: semgrep –config=p/security-audit –error # –errorフラグが重要！
ポイント: 警告レベル（Warning）ではなく、エラーレベル（Error）でビルドを停止させること。これが定着すると、チームは「どうすればこの警告を消せるか」を考え始め、自然とセキュアコーディングが身につく。
—
4. 最後に：セキュリティは「泥臭い努力」の積み重ね
どんなに優れたツールを入れても、インフラ層での防御が甘ければ意味がない。
- WAFの活用: ModSecurityやAWS WAFで、典型的なSQLiパターン（
' OR 1=1 --など）をエッジで叩き落とす。 - 最小権限の原則: DB接続ユーザーには、必要なテーブル以外へのアクセス権を与えない。これだけで、万が一SQLiを食らっても被害は最小限に抑えられる。
結局のところ、「ツールはあくまでサポート、最終的な責任を負うのは我々エンジニアの設計」という意識を忘れないでほしい。
SASTのアラートを「ノイズ」と切り捨てるか、それとも「成長の糧」として受け入れるか。その差が、あなたのシステムが「標的」になるか「要塞」になるかを決めるんだ。次のデプロイの前に、まずはパイプラインのログを眺めてみることから始めよう。健闘を祈る。
コメント