流れに身を任せながらOWASPの脆弱性を緩和する方法

GitHub Advanced Security が OWASP Top 10 脆弱性のいくつかにどのように対処できるかを見てみましょう。

セキュリティ脆弱性の発生ペースと規模が拡大しています。これは、チームが何年も前からコードの安全性を保とうとしてきたにもかかわらず、です。では、なぜ脆弱性がこれほどまでに問題なのでしょうか？チームが、開発者の体験を最適化しないセキュリティツールや戦略を使用すると、開発が遅くなります。これはフラストレーションを生み、顧客の使い勝手を悪くし、ビジネスの成功を妨げることになります。このようなツールや戦略を使用する企業は、結局、セキュリティの優先順位を下げ、ソフトウェアを早くシッピングすることに注力しています。

GitHubでは、開発者の生産性を高めながら、脆弱性を緩和するお手伝いをしたいと考えています。幸いなことに、Open Web Application Security Project (OWASP)がその手助けをしてくれます。OWASPは脆弱性のトップ10リストを提供しており、開発者や組織がアプリケーションのセキュリティやコンプライアンスリスクに対処するために必要な情報を提供しています。本日は、OWASP の脆弱性のいくつかと、開発者の生産性を維持し、さらに向上させながらソフトウェアを安全に保つための、開発者に最適な戦略について検討します。

ユーザビリティを犠牲にしたセキュリティは、セキュリティを犠牲にすることになるのです。

1.理想的なアプリケーションセキュリティ環境

まず第一に、開発チームには、成功を促進する環境が必要です。そして、その最も重要な部分は、開発者のワークフローにセキュリティを埋め込むことです。一般的に、セキュリティリスクを特定するために、サードパーティの異種ツールを使用します。しかし、これらのツールは遅く、ノイズが多く、生産性を低下させる可能性があります。しかし、セキュリティを開発者のフローに組み込むと、コードを迅速かつ容易に保護することができます。GitHub Advanced Security ebookで説明したように、その他の理想的な環境の構成要素は以下のとおりです。

• コード、シークレット、サプライチェーンにまたがるセキュリティ態勢の可視化。
• 軽量で文脈に応じたコミュニケーション・チャネルにより、容易なコラボレーションを可能にする。
• ビジネスニーズに合わせた拡張性

ビジネスの成熟度によっては、これらの機能を一度に実装することは不可能かもしれません。しかし、ビジネスの成熟度や継続的な改善に伴い、この理想的な環境を育成することで、脆弱性から保護し、安全なソフトウェアをより早くシッピングできるようになります。

2.OWASP 脆弱性のリスク軽減と予防

理想的な状態を説明したところで、いくつかの OWASP 脆弱性と、それを軽減するためのテクニックを見ていきましょう。

A02-Cryptographic Failures（暗号の失敗

開発者は、自分のソフトウェアを意図的にセキュリティの脅威にさらすことはありません。しかし、API キー、平文パスワード、セキュリティ・トークン、その他の機密データがコード内に残り、暗号の脆弱性につなが ることがあります。

理想的には、秘密が企業、組織、またはリポジトリに到達することはありません。しかし、それらはしばしば発生し、緩和される必要があります。幸いなことに、GitHub Advanced Securityが役に立ちます。

GitHub の秘密スキャン機能は、プッシュ保護機能を実装することで、コードをスキャンして公開されている秘密を探すだけでなく、プッシュで信頼度の高い秘密 (誤検出率の低い秘密) をチェックすることもできるようになります。検出された秘密はすべてリストアップされるので、それを見直して削除することができます。削除しないことが決定された場合、監査証跡が作成されます。

A03-Injection

クロスサイトスクリプティング、パスインジェクション、SQLインジェクション、NoSQLインジェクションは、長年アプリケーションを悩ませ、OWASPトップ10に入り続けている脆弱性のいくつかです。

これらの脆弱性に対処する戦略の1つは、一貫した効果的なセキュリティコードレビューを実施することです。コードがきれいになり、技術的負債やコード臭がなくなるだけでなく、より安全になるのです。これらの脆弱性をレビューすることは、既存のGitHubプルリクエストのワークフローの一部とすることができます。

コードスキャンは、機械学習の力を活用してインジェクションの脆弱性を発見し、開発者やセキュリティ専門家へのリスク伝達を支援することも可能です。CodeQLはコードスキャンを強化し、セキュリティ脆弱性がないかデータをスキャンします。

A04-Insecure Design

脅威のモデル化戦略を導入することで、開発者、セキュリティ専門家、さらにはリスク管理チーム間のコラボレーションを促進することができます。これにより、コードが一行も書かれる前に、アーキテクチャとデザインパターンが可能な限り安全であることを確認することができます。

A06-Vulnerable and Outdated Components (脆弱で古いコンポーネント)

オープンソースコンポーネントの採用が急速に進む中、ソフトウェアの構成を理解し、脆弱性のあるコンポーネントを更新できるようにすることが、これまで以上に重要になっています。

脆弱なコンポーネントや古いコンポーネントのリスクを管理するための最善の戦略の1つは、セキュリティ脅威が発見されたらすぐに開発者に警告し、通常のワークフローやツールの中で対策を講じることができるようにすることです。

Dependabotを活用することで、既知の脆弱性を持つソフトウェアの依存関係をリポジトリが使用する際にアラートを受け取ることができます。セキュリティチームからプルリクエストを起こすこともでき、セキュリティと開発者がコミュニケーションをとるためのシンプルで効果的な方法となります。

これらのツールの最も良いところは、すべてが GitHub の中で行われることです。そのため、生産性の低下や過度なコンテキストの切り替えを心配する必要はありません。

開発者の力を引き出すアプリケーション・セキュリティ

これらの戦略を実施することで、開発者組み込みの、コラボレーション可能でスケーラブルなアプリケーション・セキュリティ環境を構築し、サプライチェーン全体のリスク軽減を実現することができます。同時に、開発者の生産性に悪影響を与えないようにすることができます。