瀬戸際対策から、学習するチームへの変化はいかにして成し遂げられるか
システムの長い開発期間を経て、ようやく連結し、まさに完成間近のタイミングだとしましょう。そこでセキュリティ脆弱性診断を受けます。セキュリティ問題がざくざくと発覚します。このままリリースすると、大事故に繋がるリスクがあることがわかりました。大至急修正しなければなりません。しかし、大抵の場合、開発チームにとってそれは大幅な手戻り、残念な、過剰に負荷の高い仕事の発生を意味します。….
一義的には、「シフトレフト (SHIFT LEFT)する」とは、指摘された脆弱性などの問題への、直接的な修正・対応だけにとどまらず、それ以前のプロセス、設計や実装の段階で何をすべきだったかに立ち戻って改善することが含まれます。それで、SASTツールだとか、コンポーネント分析だとかというより「右側」で実践すべきセキュリティテストの必要性を示すために用いられる傾向があります。
しかし、シフトレフトによる品質確保の考え方は、「テスト」を早くやることに主眼があるわけではありません。それは道具にすぎません。それに、ソフトウェア開発業界で初めてうまれた概念ではありません。いわゆる別名、いや、先輩がいます。製造業における「フロントローディング」、事業分析における「なぜ5回」、医療や芸術の世界の「レトロスペクティブ」もあります。この言葉はアジャイルでも使われていますね。
いずれも、何のためにやるのかというと、もっとこれから成長していくためにやるわけです。そういったことを志していくと、「シフトレフト」は単に「リリース前のデスマーチからの脱却」よりもむしろ、段階的に開発運用のチームが、学びを身につけていくプロセスなんだ、という考え方になるはずです。
一般に、うとまれがちなセキュリティの人たちと、ものづくりに集中したい開発のひとたちは、なじみにくいと考えられるかもしれませんが、ここは共にわかりあっていくことが重要です。
共通ゴールをハイリスク脆弱性をなくす、というような外面的な目標にするのがかえって緊張を産んでいるのかもしれません。双方に、リスクを軽減することが上手くいったときに、お互いを讃え合えるような目標づくりを進められると、素敵だと思います。そのためには脆弱性テストも、時系列の変化をとらえて評価することが必要かもしれません。
同じ脆弱性の数でも、これまでより減ってきたのか増えてきたのか、また前回からのコード増量を踏まえるとよくやれているのか、それともノーチェックのコードが混入しやすい体制になってしまっているのか、などの「レフト」部分を考えないと、いつまでも問題は減っていきません。
セキュリティチームが、相互理解を目指して推進できることはいろいろあります。
これらは、セキュリティだけでは不可能で、開発や運用の皆さんとがっぷり四つに組んではじめて推進できることです。協調のできる人たちで結果を出していくと、単に「セキュリティは邪魔で鬱陶しい」とかではなくみんなにとって安全で安心できる良いものを作る未来が描いていけるといいですよね。
セキュリティに怯んで、ものづくりを諦めてほしくない
ものづくりって本当に魅力的だと思いますが、一方でそれを悪用する人がいて、悪用したものをブラッシュアップする仕事というのが成り立っているわけでもあります。ですから、ひとつのメッセージとして、「ものづくりを諦めてほしくない」と本当に思いますし、「セキュリティ」がものづくりを諦めさせるための圧力と感じないでいただきたいんです。システムによる成功、これを共通目標としてWinしていただければと思う次第です。