「シフトレフト」だけでは不十分：ソフトウェアセキュリティを極めるための「スタートレフト」という考え方

デジタル化が進む現代において、私たちはかつてないほどデータ盗難のリスクにさらされています。貴重な情報の管理を担う大企業が、厳格なセキュリティ基準を導入する必要性を認識し始めています。

「シフトレフト」、つまり開発プロセスのより早い段階でセキュリティを導入するという取り組みの多くは、根本的な解決には至っていません。そこには、依然として間違った方法でプロセスを開始し、最終的にソフトウェアの安全性を確保するために後戻りしているというニュアンスが含まれています。私たちは「スタートレフト」の考え方に切り替え、開発チームを前向きに巻き込み、現在不足している知識を身につけさせるという文化的な変革を起こさなければなりません。ただし、すべてのトレーニングやツールが同等に有効なわけではありません。

本記事では、セキュリティ意識向上担当者や開発マネージャーといった主要なリーダーが、開発者チームを真にエンパワーし、コストのかかるサイバー攻撃に対する防御の最前線へと変革する方法を探ります。

シフトレフトとスタートレフト：重要な違い。

世界で最も信頼されている組織でさえ頻繁にデータ侵害が発生する時代において、企業のリーダーたちは、攻撃による経済的損失、評判の失墜、そして事業停止という壊滅的な事態を回避するための指針をセキュリティ業界に求めてきました。

長らくの間、私を含むAppSec（アプリケーションセキュリティ）の専門家は「シフトレフト」の必要性を説いてきました。DevOpsのベストプラクティスに沿い、ソフトウェアのセキュリティを向上させるために、ソフトウェア開発ライフサイクル（SDLC）のより早い段階でセキュリティを組み込むべきだと提言してきたのです。セキュリティは、コストのかかる最終工程であるべきではありません。ソフトウェアプロジェクトが立ち上がる初期段階からAppSecチームが関与し、プロセスの開始地点に近づけるべきなのです。

これは決して悪いアドバイスではなく、従来のやり方（盗まれたデータの量や、それらを盗むために使われた脆弱性の古さを考えれば、機能していないことは明らかです）よりは確実に優れています。しかし、もし私たちが実際にスタートレフトを実践すれば、セキュリティの成果はより確実なものとなるでしょう。

シフトレフトとスタートレフト、その違いは何でしょうか。違いは、開発チームをどのように巻き込むかにあります。開発チームこそが、後工程でのツールチェーンや手動のコードレビューよりもはるかに低コストで、より安全なソフトウェアを実現するための鍵です。理想的な世界では、ソフトウェアを書くすべての開発者が、最初から安全にコーディングするための知識とツールを備えているはずです。彼らは潜在的な欠陥を見抜き、コミットする前に修正するでしょう（コミット後の修正はコストが大幅に跳ね上がります）。そうすれば、何十年も放置されてきたセキュリティバグ、つまり攻撃者に裏口を許してしまう原因となるバグが劇的に減少するはずです。SQLインジェクション、クロスサイトスクリプティング、認証不備といった攻撃の入り口は閉ざされることになります。今なお攻撃者に裏口を許してしまう原因となるバグが劇的に減少するはずです。SQLインジェクション、クロスサイトスクリプティング、認証不備といった攻撃の入り口は閉ざされることになります。

しかし現状では、職業教育レベルでのセキュリティへの重点的な取り組みが不足しており、現場でのセキュアコーディング教育もバラつきがあります。その結果、開発者が組織の「スタートレフト」を可能にするために必要なものを備えていることは稀です。今こそリーダー層が協力し、より広範なセキュリティ意識の向上を提唱すべきです。開発者と直接的な知識や接点を持つリーダーこそが、効果的なプログラムを推進する鍵となります。結局のところ、開発マネージャー自身もかつては現場でツールを使い、セキュリティという複雑な領域に頭を悩ませていた経験があるはずなのです。

開発者は（まだ）セキュリティを好んでいませんが、対話を変えることは可能です。

よくある話ですが、一般的な開発者に「セキュリティ」という言葉を持ち出すと、せいぜい呆れ顔をされるか、最悪の場合は困惑されるのがオチです。一般的に、セキュリティの問題は「誰か他の人の仕事」と見なされています。

開発者の主な責任は、機能的で革新的な機能に溢れ、厳しい納期内にソフトウェアを納品することです。コーディングレベルでセキュリティが優先されることは稀であり、迅速なデリバリーや創造性を阻害する面倒な存在と見なされることさえあります。AppSecの役割は、コードを細かくチェックし、ペネトレーションテストを行い、悪いニュースを報告することです。それは、すでにコミットされ、本来なら問題なく動作しているはずのコードに脆弱性があるという報告です。リソースや時間に追われる環境において、これはコストのかかるプロセスであり、最終的な目標は同じはずなのに言語が全く異なる二つのチームの間に溝を生む原因となります。

このような状況下では、義務的なセキュリティトレーニングに対する反応は冷ややかなものになりがちです。しかし、すべての開発者にセキュリティマインドを植え付けることは夢物語ではありません。適切なトレーニングとサポートがあれば、彼らはソフトウェアにセキュリティを組み込み、自分たちがコントロール可能なセキュリティ成果に対して責任を持つようになります。開発者自身が一般的なバグに対処できれば、高価な専門家はより複雑な問題の解決に集中できるようになります。開発チームを管理する立場にあるなら、このギャップを埋め、チームがそのメリットを理解できるよう手助けする重要な役割を担うことができます。

すべてのトレーニングが同等に有効なわけではありません。

最後に何か新しいことを学んでワクワクしたのはいつですか？その時、「義務」「コンプライアンス」「17時間のビデオ視聴」といった言葉は思い浮かばなかったはずです。

開発者も同じです。彼らは賢く、創造的で、問題を解決することが大好きです。セキュリティ脆弱性に関する延々と続くビデオを見ることが、彼らの意欲をかき立て、内容を記憶に留めさせ、日々の役割や責任に直結するとは考えにくいでしょう。私がSANSのインストラクターを務めていた際、最高のトレーニングとは実践的であり、参加者に知的挑戦を強いるものであると早い段階で確信しました。現実世界の例を用いて脳を刺激し、既存の知識を積み上げていくのです。ゲーミフィケーションや健全な競争も、新しい概念を浸透させる強力なツールであり、同時に実用的で役立つものとなります。

もう一つの懸念材料は、多くのセキュリティトレーニングが監視されていないことです。誰しも「ビッグブラザー」に見張られているような気分は好まないものですが、その教育が適切かどうかを誰も確認していないのであれば、時間と金と労力を費やす意味があるのでしょうか？

適切なソリューションを選べば、セキュアコーディングを楽しく、関連性が高く、魅力的で、測定可能なものにできます。開発者に挑戦を与え、敬意を持って接し、特別なイベントにしましょう。ゲーミフィケーションを取り入れたトレーニングは脳の報酬系を刺激します。学習を継続し、知識の境界を広げ、より高い水準のソフトウェアを構築するためのインセンティブを提供することは、双方にとっての勝利（Win-Win）となります。

セキュリティ文化の健全性チェック：あなたの組織は生命維持装置に繋がれていませんか？か？

セキュリティ文化が希薄な環境で安全なソフトウェアを作ることは、足首に岩を繋いでマラソンを走るようなものです。事実上不可能であり、不必要に困難なことなのです。

ゲーミフィケーションを取り入れたトレーニングや対戦型トーナメント、そして開発者のセキュリティスキル向上への継続的な支援は、ポジティブなセキュリティ文化を醸成する上で非常に大きな役割を果たします。これにより、AppSecチームと開発チームは互いの日常業務をより深く理解できるようになります。良好な関係が築かれることで、同じ些細なバグの修正に追われ続ける「終わりのない悪循環」に貴重なセキュリティ予算を浪費することもなくなります。

さらに、もう一つの大きなメリットとして、これまで気づかなかった「セキュリティチャンピオン」の存在が明らかになることが挙げられます。全員が参加し、かつ詳細な評価が可能な適切なトレーニングを行うことで、セキュリティの適性があるだけでなく、情熱を持って取り組む人材を発掘できます。こうしたチャンピオンは、チーム間の連携役として勢いを維持し、同僚をサポートしながらベストプラクティスを浸透させる重要な存在です。表彰や経営層の支援を含む強固なチャンピオンプログラムを導入することは、組織にとって大きな誇りとなるだけでなく、個人のキャリアにとっても強力な武器となります。

ポジティブなセキュリティ文化を確立すれば、責任を分かち合い、より高いレベルでセキュアなソフトウェア開発を実現できます。結局のところ、ソフトウェア開発ライフサイクルに関わるすべての人が、「セキュアでなければ、それは良いソフトウェアではない」というシンプルな原則を共有すべきなのです。

ぜひ情報を共有してください。