開発チームに一番必要なのは、オーバーヘッドを増やすことだ。だから、「セキュアなソフトウェア開発ライフサイクル」と聞いて、あなたが最初に思い浮かべるのは、チェックリストの増加、ブロッカーの増加、チケットの増加かもしれない。しかし、ほとんどのセキュリティ上の痛みは、問題を発見するのが遅すぎたことに起因している。スプリントで修正できたはずのバグが、突然、ホットフィックスや書き換え、あるいはプロッドでの緊急パッチを必要とする。
セキュア SDLC (SSDLC)はそれを裏返します。それは、初日からセキュリティを念頭に置いてソフトウェアを構築することです。ボトルネックとしてではなく、計画、コーディング、テスト、デプロイの方法の一部としてです。これは、より少ないサプライズでより速く出荷し、なおかつあなたのプレートに積み上げられたコンプライアンス、顧客、セキュリティの要求を満たす方法です。
プレースホルダ画像 画像の説明SDLC と SSDLC の時系列比較。SSDLC における開発の各段階 (計画、コーディング、テスト、デプロイ) でのセキュリティチェックを示す。
古い方法と安全な方法:SSDLCの本当の意味
伝統的な SDLC では、セキュリティは最後にやってきます。コードが書かれ、アプリがデプロイされ、ユーザがすでに API をつついた後です。そして、誰かがスキャンを実行し、多くの問題が見つかり、全体が止まってしまいます。セキュアな SDLC では、セキュリティは最初から統合されています。セキュリティは計画に組み込まれ、コードレビューでチェックされ、CI でテストされ、リリースの前に検証されます。事後的にセキュリティを後付けするのではなく、問題が発生する前に予防するのです。ドラマが減る。ベロシティが向上する。
報酬:SSDLCが単に仕事を増やすだけではない理由
リスクを削減する(そしてニュースで取り上げられるような企業にならないようにする)
情報漏えいの見出しに載るような企業?全員が無知なわけではない。ほとんどの企業はスキャナーを持っていた。彼らに欠けていたのはタイミングだった。SSDLCは、ハードコードされた秘密、安全でない入力、許可されすぎた役割のような脆弱性を、本番環境に近づく前に検知する。ゼロデイスクランブルは少なくなる。PRの悪夢が減る。
お金を節約する(早めの修理は安い、生産中の修理は財布を圧迫する苦しみ)
開発部門でバグを修正するのに30分かかるかもしれない。開発部門でバグを修正する場合、30分かかるかもしれない。それは、インシデントコール、ホットフィックス、リグレッションテスト、もしかしたらセキュリティ監査になるかもしれない。SSDLCは、このような火災ドリルを削減する。情報漏えいをデバッグするよりも、PRをスキャンする方が安上がりだ。
信頼の構築(顧客は実際に安全なソフトウェアを求めている。)
企業顧客は現在、安全なコーディングの実践と、あなたのチームが prod に YOLO コードをしていないことの証明を求めています。SSDLC は、構造化、監査証跡、そして、調達担当者が "XSS をどのように防止していますか?" と質問したときの回答を提供します。気まずい沈黙は必要ありません。
ネイル・コンプライアンス (ペーパーワークを減らし、コーディングを増やす。Aikido これを自動化するのに役立ちます!)
コンプライアンスはなくならない。SOC 2であれ、ISO 27001であれ、GDPRであれ、監査人はワークフローに組み込まれたコントロールを見たがります。SSDLCは、証拠収集の自動化を支援します。特に、Aikido ようなツールが、パイプライン全体にわたって、SASTから秘密情報、IaCの誤認識まで、すべてを追跡する場合に役立ちます。
実際に機能するセキュアな SDLC の主なアイデア
セキュリティ・バイ・デザイン(後付けではなく、1行目からセキュアを考える)
すべての機能の決定には、セキュリティ上の意味がある。トークンの保存方法から、ユーザがパスワードをリセットする方法まで。SSDLCとは、コードの最初の行が書かれる前に、「ここで何が間違う可能性があるのか?
左にシフトする(雪だるま式に悪化する前に問題をキャッチする)
コードを書きながらスキャンする。PRでSASTを実行する。インフラがデプロイされる前に、設定ミスを見つけよう。発見が早ければ早いほど、修正費用は安く、簡単になる。
深層防御(レイヤーが増える=ハッカーの頭痛の種が増える)
コントロールは1つでは十分ではない。SSDLCは、入力検証、アクセスコントロール、ネットワークセグメンテーション、ランタイムアラートなど、複数のレイヤーを推奨している。何かが失敗しても、別のレイヤーが背中を押してくれる。
最少特権(全員に王国の鍵を渡すな)
スタック全体のアクセスを制限する。開発環境に完全な開発権限を与えない。必要でない限り、サービス同士を会話させない。パーミッションが少ないということは、攻撃者が横に移動する方法が少ないということだ。
セキュアなデフォルト(簡単な道を安全な道にする)
開発者に "作業 "と "セキュア "の二者択一をさせるな。セキュアバイデフォルトのテンプレート、CIパイプライン、コンフィグを設定する。最も抵抗の少ない道が正しいのであれば、人はそれに従う。
セキュアな開発はブロッカーではありません。それは、最新のチームが常に肩越しに監視することなく、迅速に作業を進める方法なのです。SSDLCをフローに組み込めば、バックグラウンドで静かに動作します。
次のページ:これらの責任は誰が負うのか?ヒント:AppSecチームだけではありません。