開発生産性 Conference 2024 で登壇してきました。

どうもセキュリティエンジニアリングの西川です。

先日、株式会社Flatt Security のCCO豊田さんにお誘いいただき、カミナシのセキュリティの取り組みや開発生産性をどのように考えているかをファインディ株式会社主催の開発生産性Conference 2024 にてお話させていただきました。

当日の資料は下記です。 speakerdeck.com ※自動でライトがつく OR 無灯火を知らせるのページで左側の運転手が寝ていますがそれに意味はありません

どういうことを話したか

ざっくりですが、下記のような話をしました

カミナシのサービスのセキュリティのオーナーシップは開発者が持っている
セキュリティエンジニアリングはイネーブルメントの役割を担っている
どうして Flatt Security 社の脆弱性診断を選んだか
セキュリティは力を持っているからこそ生産性を奪いかねない

ところで、セキュリティと開発生産性にどのような関係があるのか？と思われるかもしれないですが、この登壇とは関係なく、Security & Developer Productivity Engineering に部署名を変えようかという話が出るぐらい、私たちセキュリティエンジニアリングは開発生産性にこだわりを持っています。ただ、混乱を招きやすいかつ名前が非常に長いため、結局は部署名の変更はなさそうですが、常に開発生産性を意識していこうと話し合っています。

カミナシのサービスのセキュリティのオーナーシップは開発者が持っている

これは、予防的統制と発見的統制があった時にカミナシでは発見的統制を軸とし、セキュリティエンジニアはセキュリティに関する各種情報を提供し、それを実装するかどうかは開発者自身が選択するというスタイルをとっています。他人も開発者自らがリスクを評価し、対応するしないを自分たちで決定できる方を選択しています。もちろん相談にも乗っていますが、最終的な判断は開発チームに委ねられています。この辺りはカミナシにおけるセキュリティの文化の作り方 - カミナシエンジニアブログで記載の通りです。

セキュリティエンジニアリングはイネーブルメントの役割を担っている

私たちセキュリティエンジニアリングは

リスクマトリクスの作成
社内セキュリティ競技会の開催（年に1回）
セキュリティニュースの配信（月に1回）
各開発チームのセキュリティの定例（隔週に1回）

などを普段の業務としています。これ以外にも横断的なシステム開発もしているのですが、そういった取り組みをなぜやっているのか、どういったところに工夫してやっているのかという紹介をしました。

例えば、社内セキュリティ競技会の開催であれば、普段開発チームが使っている技術に関する脆弱性を探す問題や、もしセキュリティの知識や能力を獲得して欲しいのであれば、それに関連する問題を出題するようにしています。そうすることにより問題を解きながら必要な知識や能力を獲得できるというメリットがあります。

同様にセキュリティニュースの配信では、社内で確認された、もしくは発現しそうな問題や課題に関する内容を共有したりしています。ただ共有するだけではなく、より身近に感じてもらえるように世の中で配信されているニュースをそのまま配信するのではなく、より深掘りした内容を届けるようにしています。時に発見された脆弱性に関して、教訓を踏まえて、カミナシではこういう時に問題起こりそうだよねとか、カミナシではこういうところに気をつけないとねとか、そういうものを選択して他人事にはならない工夫をしています。

これらの取り組みを見てわかる通り、カミナシのセキュリティエンジニアリングは直接的にサービスをセキュアにするのではなく、開発者にセキュリティの知識や能力を身につける取り組みを普段からしているということです。

カミナシはどうして Flatt Security 社の脆弱性診断を選んだか

脆弱性診断って脆弱性対応の始まりにすぎないんですよね。ですので、運用設計をまずは始めました。例えば、脆弱性がたくさん見つかって、開発者に「あとは対応よろしく」というだけでは対応できないんですよね。開発の仕事も当たり前にやっている中で突然降って湧いてきた脆弱性対応に時間を取られる。これって本当に今やる必要があるのか、誰も納得しないで対応していると、やらされ感が生まれ、誰も幸せになれないばかりか開発生産性も落ちてしまいます。ですので、私たちがまず最初に作成したのがリスクマトリクスです。

これを作成して、影響度や可能性について定義をしていきました。

どういうものが高で、どういうものが中なのかなどです。これをすることにより開発者自らがリスクを評価できるようになるのと同時に、リスク値が高いから対応しないといけないということが開発チーム内で判断できるようになります。逆にこれがないと納得感が生まれません。

これが作成できたところで、ある程度運用設計ができたので業者選定を始めました。このあたりの内容は以前 Flatt Security 社のこちらの記事にも記載いただいておりますが、私たちはサービスをセキュアにする目的の一つとして脆弱性診断をお願いするわけですが、一般的なセキュリティベンダーは脆弱性診断をして、脆弱性を洗い出すことを目的とされていると認識しています。しかし、Flatt Security 社においては、私たちと同じように「カミナシのサービスをセキュアにすること」を目的とし、寄り添っていただけそうであることを強く感じたため、依頼させていただいたという背景があります。

セキュリティは力を持っているからこそ生産性を奪いかねない

これは前回の記事でも書いた通りです。カミナシのお客様の現場では、お客様は分厚い手袋をしていたり、大きいマスクをしていたりします。そういったデスクワーカーとは異なる制約の中で、開発者やサポートメンバーは単純に機能開発をするのではなく、現場と向き合いながら利便性まで考慮した開発を行なっています。開発者の制約でいうなら納期などもあります。この機能をいつまでにリリースしないとチャーンしてしまうかもしれないというプレッシャーと闘うこともあるでしょう。それなのにセキュリティエンジニアだけは制約を無視して「セキュリティはこうあるべき」「どうしてこんな当たり前なことができていないの？」と現場に寄り添わない態度を示して良いのでしょうか。また、スタートアップ企業である私たちにとってスピードは最優先事項の一つと言えます。機能やサービスを提供するのに MVP（Minumum Viable Product）を定義し、アジリティを出すために顧客と向き合っています。MVP を考える上で開発者は、この機能で最低限を満たしているか、削りすぎていないか、顧客に価値を届けられるか　などの不安と闘っているはずで、私たちセキュリティエンジニアリングがそれを無視していいはずはありません。また私たちセキュリティエンジニアリングにとっても MVP はあるはずで、それこそが開発生産性に寄与できるところだと思っています。それはつまり、リスクを受容できるギリギリのラインまで満たすことができたら、「それ以上の対策は現時点では必要ない」と言ってあげることだと考えています。もちろんそれで問題が起きた時はその発言をしたセキュリティエンジニアの責任ですが、彼らが抱く不安や痛みを私たちが引き受けられるところはそこしかないのです。それがカミナシのセキュリティエンジニアの役割であると自負しています。