1. 後付けのセキュリティ

ほとんどの組織では、開発者の数がセキュリティ スペシャリストの数を大きく上回ります。開発者がコードを作成し、開発サイクルの終盤でセキュリティ チームを関与させるのは、リリースのスピードと量からしても負け戦です。このアプローチには全てのアプリケーションを網羅できるほどの拡張性はなく、手遅れになるまで脆弱性を発見できないことから、脆弱性を含むコードが本番環境にプッシュされることになってしまいます。

ソリューション: セキュリティをシフト レフトしてセキュリティ取り組みを拡張し、開発の早い段階からすべてのアプリケーションを対象に含めます。

2. サイロ、および開発とセキュリティ間の摩擦

従来、開発者とセキュリティ チーム間のコミュニケーションは問題ベースまたはインシデント ベースである傾向があります。しかし、メール、PDF レポート、GitHub Issues による一括コミュニケーションは摩擦の原因となり、全員にとってフラストレーションがたまります。開発者にとっては、セキュリティから指摘された問題は日々の開発には関係ない場合や、既に完了したはずのプロジェクトへのフィードバックが含まれている場合があります。これらの問題を修正するのは、スプリントのタスクや取り組みの再スケジュールといったストレスが増すのみで、セキュリティがイノベーションの障壁になってしまいます。セキュリティ チームにとっては、アーキテクチャ、デザイン、開発の早い段階で関与できないことはフラストレーションが溜まります。また、長年にわたりセキュリティの専門知識を身につけたわけではない開発者に、組織的なリスクやアプリケーション セキュリティのリスクについて説明するのは困難な場合もあります。結果的に、コミュニケーション不足はコラボレーションや共感力の低下につながります。

ソリューション: 開発者ワークフローにツールを統合して、セキュリティを開発の一部として組み込みます。両チーム間での話し合いや非同期コラボレーションを促進します。

3. ただチェックしているだけのセキュリティ

組織ごとにセキュリティの重要度が異なるように、実際のセキュリティ手法も組織によって異なります。正式なセキュリティ ポリシーとその実践方法との違いは混乱を招く可能性があり、セキュリティ問題の優先順位付けが一層複雑になります。

また、アプリケーション セキュリティは組織の全般的なサイバー セキュリティ対策のほんの一部であり、開発および継続的インテグレーション/継続的デプロイからは分離されている傾向があることに注意する必要があります。このことは、次のような悪い習慣につながります。

質よりも量に価値を置くようになります。大量の低品質のセキュリティ スキャン結果や脆弱性に焦点を当てても、より大きな問題は解決されず、開発者の作業が増えるだけです。セキュリティを開発の問題にするようになります。未加工のセキュリティ スキャン結果を問題トラッカーに接続し、開発者が全て修正してくれることを想定していると、開発者はセキュリティ関連の問題に鈍感になります。価値を測定しなくなります。ほかのあらゆる取り組みと同様に、アプリケーション セキュリティ対策の価値と投資収益率は、継続的に測定して評価する必要があります。これを行わないと、データ不足により組織の活動が滞り、セキュリティが向上しているという証拠が示されなくなる可能性があります。

ソリューション: 修正を即時に行うため、大量の偽陽性を共有するのではなく、実際のセキュリティ問題を限られた数だけプッシュしてから、それらに優先順位を付けて開発者に提示することに焦点を当てます。より大きな規模では、新しいセキュリティ問題を「コード化」し、それらが本番ブランチにマージされるのを防ぐことができるセキュリティ ツールを探します。重要なのは、セキュリティ ツールによって実際にコードを改善することです。そのためには、アプリケーション セキュリティ プログラムの価値と影響を長期的に測定し続ける必要があります。