あなたの組織は本当にDevSecの準備ができていますか？テストしてみましょう。

2020年も半分が過ぎようとしていますが、データ侵害の記録はすでに悲惨な状況を更新するペースで進んでおり、盗難データ量は2019年上半期と比較して273%も増加しています。今日では、どれだけのデータが盗まれたかではなく、どれだけのデータがまだ盗まれていないかを問う方が正確かもしれません。COVID-19パンデミックのような世界的な出来事により、こうした攻撃の頻度と威力は増すばかりで、標的はますます脆弱になっています。

これは以前から誰もが知っていたことですが、セキュリティはもはやオプションではなく、先制攻撃的なアプローチが不可欠です。それを効果的に行うには、SDLC（ソフトウェア開発ライフサイクル）に関わる全員がセキュリティ意識を持つ必要があり、特に開発者はその筆頭です。これこそが「DevSecOps」における「DevSec」の部分であり、DevSecOpsは現代の状況に理想的なソフトウェア開発手法ですが、多くの組織はこれを効果的に実行する準備が完全には整っていません。

ご自身の組織を念頭に置き、ご自身の役割という文脈でこれらの問いを考えてみてください。DevSecのテストに直面したとき、組織はどのように対応できるでしょうか。

DevSec自己診断：あなたの組織のSDLCは、セキュリティ意識の高いエンジニアを育てる土壌になっていますか？

1. 社内の開発プロセスにおいて、セキュリティは最優先事項になっていますか？
   CISO（最高情報セキュリティ責任者）を悩ませるサイバーセキュリティのリスク要因は多岐にわたりますが、懸念すべき現実は、多くの企業がセキュリティを優先しつつも、その社内アプローチが潜在的な災害（あるいは、少なくともAppSecチームの多大な苦労やソフトウェア出荷の遅延）を回避するには不十分である可能性があるということです。
   DevSecOpsは現在のセキュリティの理想郷かもしれませんが、この手法を実践できている企業はごくわずかです。もし現在もアジャイル、あるいはウォーターフォール開発を行っているなら、セキュリティは依然としてプロセスから切り離された専門家の領域と見なされ、SDLCの終盤になってようやく介入し、コードの修正を強いて開発者を困らせる存在になりがちです。このような環境では、DevSec文化を推進するのは困難です。開発者は機能開発を愛し優先するものであり、セキュリティを魅力的なスキルアップの道と見なすほどの実践経験を積む機会がないからです。実際、セキュリティとの接点はフラストレーションやネガティブなものになりがちです。ソフトウェア開発プロセスに関わる全員がセキュリティを最優先に考えられるよう、この状況を早急に改善しなければなりません。
   ‍
2. あなたの組織は、脅威モデリングにおいて後手に回っていませんか？
   中小企業の60%がサイバー攻撃を受けてから6か月以内に廃業に追い込まれるという統計は深刻です。他の災害と同様、適切な計画がなければその影響は計り知れません。
   脅威モデリングはセキュリティのベストプラクティスにおいて極めて重要な要素であり、AppSecの専門家が攻撃対象領域の全容を把握し、適切な防御策、対策、計画を構築することを可能にします。DevSecOpsを完全に導入している企業では、CI/CDパイプラインの初期段階でセキュリティが組み込まれており、以前のように生産性を低下させることはありません。セキュリティ、セキュアコーディング、継続的デリバリーはすべてプロセスの一部であり、開発チームには、堅牢なコードを生み出すエンジンとなるために必要なリソースと経験が提供されています。
   ‍
3. 開発マネージャーはセキュリティのベストプラクティスを優先していますか？
   好むと好まざるとにかかわらず、開発マネージャーはチームのロールモデルです。それはオフィスでサンダルを履くといった文化的な側面や「上司への報告」といったことだけではありません。彼らの仕事の優先順位は必然的にチームメンバーに浸透します。もしセキュリティが主要な目標に含まれておらず、トレーニングやサポートの計画もなければ、部下のエンジニアは成長の機会を逃し、ビジネスは本来あるべき以上のリスクにさらされることになります。
   ‍
4. 開発者にセキュリティを気にかける理由を与えていますか？
   私の経験上、相手を反発させる最も早い方法は、理由を説明せずに、現在のやり方とは異なることを強いることです。
   
   「変えろ」と言われると、これまでのやり方が間違っていたかのように聞こえますが、多くの場合、それは将来的に作業をより簡単かつ効率的にするための改善に過ぎません。DevSecの動きを真に受け入れるには、まず開発者にセキュリティを気にかける理由を与える必要があります。結局のところ、多くの組織では依然としてセキュリティは「誰か他の人の問題」（つまり、遠く離れた別の部屋に閉じこもったAppSecの魔法使いの問題）と見なされているからです。
   
   セキュリティが共通の責任でなければ、DevSecOpsは機能しません。開発者が自分の役割を果たすには、適切なツール、サポート、トレーニングが必要です。そして、これらを全体的なセキュリティプログラムの一部として展開し、完成させるには時間が必要です。最悪のアプローチは、開発者を圧倒し、疎外感を与えることです。これは、開発者が競合する優先事項を抱え、それを管理する助けがない場合に起こり得ます。これは文化的な変革であり、一朝一夕には成し遂げられません。
   ‍
5. 少数の魔法のようなセキュリティのユニコーンに、多くのタスクを押し付けていませんか？
   セキュリティ専門家は極めて不足しており、現在利用可能な人数よりもはるかに多くの人材が必要です。それは当然のことですが、セキュリティに重点を置いた役割に移行する開発者が増えています。通常、彼らは「セキュリティエンジニア」や「DevOpsエンジニア」といった肩書きで呼ばれます（いずれはDevSecOpsエンジニアという肩書きに変わっていくでしょう！）。優秀なDevOpsエンジニアは、真のCI/CDパイプラインを使用してデプロイしながら、事実上あらゆるアプリケーションの機能を開発できます。彼らはエンドツーエンドですべてをこなし、通常、高いセキュリティ意識を備えています。その意味で、彼らは魔法使いのような存在であり、それゆえに希少です。しかし、一部の企業は、こうした専門エンジニアを雇ってチームに放り込み、開発プロセスのあらゆる段階でセキュリティの問題をすべて解決してくれることを期待するという間違いを犯します。これこそが万能薬だと考えているのです。DevSecOpsの魔法使いに過度な負担をかければ、結局は元の木阿弥となり、彼らが本来行うはずだったチェックやバランス、セキュリティの精度を欠いたまま、安全でないコードを出荷することになります。開発チーム全体がスキルアップし、前向きなセキュリティ環境で育成され、責任を分担できる体制を整えることが何よりも重要です。
   
   

組織に起こしたい変化を見つけましょう。

セキュリティプログラムの一環として強固なトレーニングを導入すれば、開発チームの中に隠れた才能を発見できるはずです。日々の業務でネガティブな経験をしていても、セキュアコーディングやセキュリティのベストプラクティスに情熱を抱いている人々がいます。彼らはチーム内の「セキュリティチャンピオン」の有力候補です。セキュリティとエンジニアリングの橋渡し役として、他のメンバーの模範となり、意識を高め、エンゲージメントの取り組みを支援してくれます。彼らの対人スキルは、セキュリティの重要性を広め、開発者のニーズを経営陣やセキュリティチームに代弁する上でも非常に重要です。

「自分にとって何の得があるのか？」という問いかけは、前向きな一歩です。

どんなに高潔な人間であっても、馴染みのない領域に足を踏み入れるときや、学習曲線が険しい活動に取り組むときには、何らかの「ニンジン」が必要です。
「開発者」から「DevSec」へ飛躍することは、開発者のキャリアにとって素晴らしい後押しとなります。セキュリティ意識の高い開発者は、セキュリティを理解し、自分が制御できる範囲で責任を持ち、安全なコードこそが唯一の高品質なコードであるという認識のもとで業務を行います。一般的に、開発者は成長し、新しい課題に取り組み、同僚の中で際立つような優れた機能を作りたいと願っています。彼らがより高いレベルのソフトウェア開発に到達するための道筋を示せば、双方にとっての勝利となります。

DevSecのドリームチームを作るのに遅すぎることはありません。

開発者を管理している方、AppSec意識向上チームを率いている方、あるいはセキュリティプログラムの戦略を練っている方、今こそ「シフトレフト」の先を目指すべき時です。適切なトレーニング、ツール、環境があれば、開発者のためのセキュリティ育成の場を作り出し、すべての関係者に大きな利益をもたらすことができます。このチェックリストで改善点が見つかったなら、SDLCの最初からリスクを軽減できる、DevSec主導のエンジニアリング部門へと組織を変革する絶好の機会です。