なぜ日本企業でDevSecOpsは進まないのか？｜セキュア開発推進の課題と実践のヒント

インシデントレスポンスやエンドポイントセキュリティのように、わかりやすく、またビジネスとして成り立ちやすい事業に比べ、セキュア開発の推進という、効果が出るまで時間がかかり、なかなか理解の得にくい領域にNRIセキュアがコミットしてきたのは素晴らしいことですね。

7年後の今はDevSecOps事業の責任者ですね。この事業では、どのように課題の解決を行っているのでしょう？

当時はまだDevSecOpsという言葉もそれほど知られていなかったと思います。どのようなお客様から受け入れられていったのでしょう？

DevSecOpsやセキュア開発について議論しようにも、「それは一体何を意味しているのか」という前提が漠然としており、人によって解像度が異なりますよね。

僕も福澤さんと同じくエンジニア出身で、さまざまな経験の中から「やられないシステム作り」の重要性を認識するようになりました。そしてアスタリスクという会社を通して、やられない、あるいはやられても強いシステムにするためにどうすべきかの経験や知見を提供し、プロダクトチームとタッグを組んでセキュリティを中から作っていくための伴走をしてきました。

ただ、セキュリティはお客様の急所を取り扱う大事な仕事なので、表立って詳細を話すことはあまりできません。このため、目の前で相対している方の先にいるエンジニアや、スポンサーである意思決定層との間にギャップが存在し、「なんであんなことにお金と時間を投じるんだ」といった後ろ指を指されながら走らざるを得ないこともあります。

この状況を打開するには、「どこから始めるか」を決める必要があります。その指針としてちょうどいいのがOWASP Top 10です。つい先日、2025年版の日本語訳を作成し、リリースしたばかりです。OWASPというコミュニティは、アプリケーションセキュリティを実現するには共通言語が必要だ、という問題意識のもとで2001年に生まれ、僕もプロジェクトのコントリビュータとして活動してきました。最近では、AIに尋ねてもOWASPが参照されることが多く、こうした活動に貢献できたことをうれしく思っています。

セキュリティへの解像度がまだ低い人たちも含め、多くの企業や開発者が「セキュリティを開発プロセスの中に当てはめるとはどういうことか」を理解していくには、コンサルティングだけでは追いつかず、こうしたパブリックなガイドが必要だと考えています。

システムというのは生まれた瞬間が価値のスタートですから、その後のことを考えないわけにはいきませんよね。

僕は2017年頃から「シフトレフト」の必要性を大声で叫び続けてきました。けれど多くの方には「要するに要件定義から頑張れということだな」と認識されるだけで終わってしまい、「どうやったらセキュリティを考慮に入れた要件定義ができるかわからない」と行き詰まってしまったように思います。

これに対し僕は、今動いているシステムのセキュリティ運用課題をインプットすればいいじゃないか、とアドバイスしています。

たとえば、運用していてブルートフォース攻撃で認証を突破しようとする攻撃があっても気づけず、CPUを食い潰してからやっと把握できた、といったシステムがあったとします。この問題を解決するには、WAFにシグネチャを追加したり、モニタリングレベルを上げるといった手段があります。それを要件としてインプットすればいいんです。現状ではそもそも運用課題を洗い出せていないため、「次に開発をするときは、こういった事柄に対応できる必要がある」という要件が決められないんですよね。

皆さんもDevOpsの概念を表現する、ぐるっと八の字型のサークルになった図を見たことがあると思いますが、あの図を見ても、設計の前段階にインプットできるものは運用課題しかないんですよ。線形ではなく終わりと始まりがつながっているのですから、運用の人と話して課題を洗い出し、要件に取り入れることが大事です。運用課題はそのまま、インシデントの火種になります。

2025年版のOWASP Top 10の10番目の項目には「 例外の不適切な処理」が取り入れられました。しっかり取り組めば被害を抑えられるはずの運用課題に取り組んでいないことが、セキュリティ上の重要な問題だと認識されるようになったわけです。

もう1つ、セキュリティを開発に取り込むDevSecOpsという言葉には「セキュリティは余分なものだ」と思われてしまう功罪があったのではないかとも感じています。

僕の考えでは、開発にセキュリティを取り込むという言葉には2つの意味があります。

1つは、認証やログ、入力値検証、暗号といった共通のセキュリティ機能を作り込むことです。セキュリティは一般に「非機能要件」と思われがちですが、この場合はむしろ運用のための「共通機能要件」と呼ぶべきだと思っています。共通機能要件であることが認識されれば、これらを実装するためのエンジニアがアサインされていくでしょう。

OWASPでは、こうした共通機能を実現するライブラリを「ESAPI」（Enterprise Security Application Programming Interface）と定義し、組織の中で共有することを推進した時期がありました。この概念は今も適切だと思っていて、入力値検証のような機能をバラバラに作るよりも、予算を付け、担当を付けていいものを作って他のチームにも共有することで、皆がハッピーになれるんじゃないかと思っています。

この「共通機能を実装する」というのが、開発にセキュリティを取り込むことの定義その1です。その2は何だと思いますか？

プロセスです。「こういう段取りで作ればセキュアに作りやすく、検証しやすい」という進め方の話です。

たとえば、いかに早くレビューを受けるか、他のモジュールと結合したときにいかに早く検証するか、外から適当に拾ってきたコンポーネントを使わないようにするか、という具合に、進め方一つを改善するだけで、システムは相当セキュアになると思うんです。これは、DevOpsやアジャイルと同じことを別の言い方で表現しているとも言えるでしょう。

こんな風にプロセスが焦点になると、プロジェクトマネジメントの観点で議論できるようになります。すると「あの進め方は非常に効率よく脆弱性を撲滅することに成功できていていいじゃないか」と、他のチームにもどんどん共有されるようになっていくんじゃないかと思います。

となると、教え合いを必然的にやらざるを得ない仕組み作りも必要かもしれませんね。技術的な仕組みと同時に、それをうまく活用することに対し、インセンティブが働くような組織的な裏付けも必要かもしれません。

たとえば、各チームから知見を持つ人が集まり、ノウハウを共有するCoE（Center of Excellence）という仕組みがあります。クラウド活用に関してはCloud CoEがありますが、セキュリティに関しても、Security CoE、あるいはQuality CoEのような取り組みが必要ではないかと思っています。

けれど、第三者として介入することで、うまく貢献できたこともありましたよね？

10個、20個とプロジェクトが並行して進んでいる会社の場合、まずパイロットケースとなるチームで実践し、その知見を他のチームにも展開していく、というやり方を提案しがちですが、特定の優れたプレイヤーに依存している実情が浮き彫りになることもあります。OWASP SAMMというフレームワークでは、そうしたボトルネックを解消し、多少遅れを許容してでも全体で成熟度を高めるための方法論を提示しています。

何らかの観点に基づいて、ざっくりとしたシステムのプロファイリングや、グレーボックステストにそうしたツールを使うのはいいことじゃないかなと思っています。NRIセキュアでもサービスにAI技術を盛り込む計画はあるんですか？

AIのリスクは幅広く、さまざまな観点がありますが、たとえばOWASPのGenAI Security Projectでは、セキュアなMCPサーバ開発に関するガイドを出したばかりです。NRIセキュアの皆さんにもますますこうしたプロジェクトに参加し、ドキュメントへのフィードバックなどに関わっていただければと思います。

以前、海外のカンファレンスで「開発エンジニアがセキュリティを嫌いな理由、Top10」というタイトルのセッションがあり、まったくその通りだと思いながら聴いたことがあります。開発者としてはいいものを作りたいと思っているのに、後出しじゃんけんのような形でダメ出しをされると面白くはありませんよね。

ですから、セキュリティ至上主義ではアプリケーションセキュリティは難しいかもしれません。セキュリティに携わる人がもの作りや開発を知ること、そして事業そのものに詳しい人がセキュリティを知ることが大事だと思っています。

特に、事業やビジネスに詳しい人が、システムに対する脅威のシナリオや悪用されうる技術のメカニズムを学ぶのがいいかもしれませんね。事業に詳しく、愛着を持てる人材はなかなか外から調達できません。しかしセキュリティに関する知識ならば、今はAIの支援もありますから、頑張れば半年程度である程度学べます。そうして勘所を押さえることで、「ここにセキュリティ対策が必要だ」と直感的に理解できるようになり、セキュア開発が進むのではないかと思います。

いいですね。僕も同感です。

OWASP Top 10 2021には「安全が確認されない不安な設計」という項目が含まれていました。ビジネス観点から見たリスクや優先順位付けができないと、適切なアーキテクチャや設計ができない、という指摘です。「前にやったことがあるから」とか、「あの会社のアーキテクチャがかっこいいから」という理由で設計されては困るんですよね（笑）

もう一つ付け加えると、日本ではシステム開発を請け負うアウトソーサーやシステムインテグレーターの存在を無視できません。けれど、外注に丸投げしている間はDevSecOpsなんて無理なんじゃないかと思います。

もちろん最近では、丸投げせずにオーナーシップを持つ企業が増えたと思っています。開発や運用の主体はあくまで企業側にあり、振り返りを実施しながらしっかり推進していく企業は確実に増えてきたなと思いますね。

大規模なインシデントを受け、この3ヶ月ほどで、セキュリティの重要性が急激に認識されました。一方で、「こうすればみんなの役に立つ」という方法が見つかっても、それを人にシェアする方法はなかなかありません。Hardening Projectのような形で競技を設計したり、プレゼンテーションの機会を提供したりといろいろ挑戦してきましたし、「こういう進め方をするといいよね」というコンセンサスを集めたものが、OWASP SAMMをはじめとするOWASPのドキュメント類なんです。ですので今後もこうした活動を頑張っていきたいと思います。

OWASP Top 10には、「エンジニアが、自分の持つコードに対する責任の大きさというものは概して認識されていないものです」と記されています。コードの書き方に関する自由度は非常に高いのですが、その責任の重さはなかなか認識されていません。同時に、開発者に任せる側も、どれだけ重いことを任せているのかが分かっていないという問題もあり、これは非常に大事なポイントだと思います。

僕は「セキュリティを開発に取り込むことは、お金とリソースに余裕がある人たちだけの作業だ」という勘違いをどうにかしたいんですよ。セキュリティは余裕ができたら頑張るものではなく、はじめからやらないといけないものなんです。時間もお金もないからセキュリティができないのではなく、セキュリティをやらないから時間もお金もなくなるのだ、と言いたいですね。逆に言えば、セキュリティを開発体制と技術の両面から取り組むことは、ビジネスの成長を守る、必須の、そして一番の近道なんです。