回答。

アプリケーションのセキュリティチェックの自動化のアイデアは、サイバー脅威の増加に伴って発展してきました。最初はセキュリティテストはほぼ完全に手動でしたが、DevOpsと自動化の発展により、CI/CDパイプラインにセキュリティチェックを統合することが可能になりました。

問題の歴史

最初の数年間は、手動侵入テスト（ペンテスト）とスキャナーが脆弱性チェックの唯一のツールでした。その後、開発では個別の自動スキャナーが登場し、その後はプロセスに統合されるプラットフォームが登場しました。

課題

• セキュリティテストはしばしば実行に長い時間がかかり、更新されるのは稀です。
• 多くの「偽陽性」が発生します。
• インフラストラクチャとアプリケーションに対して複雑な設定が必要です。
• すべての脆弱性を自動的に見つけることはできません — 一部のチェックは専門的な分析を必要とします。

解決策

1. CI/CDの段階で自動化されたセキュリティテストを組み込む：DAST/SAST分析ツール、自動スキャナー（OWASP ZAP、SonarQube、Checkmarxなど）を使用する。
2. レポートとテストシナリオを定期的に更新し、偽陽性の処理を設定する。
3. 自動化を定期的な手動監査と振り返りと組み合わせる。

主な特徴：

• SAST/DAST/RASPスキャン
• CI/CDとの統合
• インシデントへの反応の処理と自動化

答えにくい質問。

すべての脆弱性を自動テストだけで見つけることは可能ですか？

いいえ、自動テストはセキュリティリスクの一部（例えば、XSSやSQLインジェクション）のみをカバーしています。完全性を確保するためには、手動監査も必要です。

質の高い保護のためにはSASTまたはDASTのいずれかのスキャナーがあれば十分ですか？

いいえ、SASTはアプリケーションの実行前にコードを静的に分析し、DASTは実行中のアプリケーションの挙動を分析します。両方を使用し、追加の方法も考慮する必要があります。

デプロイを早めるためにCI/CDでセキュリティテストを無効にすべきですか？

いいえ、そのようなアプローチは危険です — 製品のセキュリティを危うくします。

一般的なエラーとアンチパターン

• スキャナーのレポートの無視（偽陽性疲労）
• 手動と自動的アプローチの統合不足
• セキュリティプロセスの一部だけの自動化

実生活の例

ネガティブケース

リリース段階で安全性が手動分析と時折スキャナーでのみチェックされ、レポートがCI/CDに統合されていません。

利点：

• 難解な脆弱性の「ライブ」監査

欠点：

• 問題の発見が遅れる
• 修正コストが高い

ポジティブケース

CI/CDで自動化されたセキュリティテストが展開され、重大な脆弱性はリリースをブロックし、偽陽性にはフィルタリングルールが設定され、四半期ごとに追加のペンテストセッションが行われます。

利点：

• 重大な脆弱性の迅速な発見
• コード変更時の分析の確保

欠点：

• DevOpsおよびセキュリティ専門家のリソースを必要とする
• 一部の脆弱性（論理的なもの）は手動でのみ発見される