政府のサプライチェーンにおけるサイバー脆弱性の実態を解明する

本記事はTechCrunchに掲載された記事を基に、更新・転載したものです。

‍

「名前を呼んではいけないあの年」に十分な混乱を経験したはずの私たちは、2021年の幕開けとともに、米国政府を揺るがす史上最悪のデータ侵害という衝撃的な事態に直面しました。SolarWinds事件は、国家レベルの攻撃者による極めて巧妙かつ壊滅的な攻撃であり、複数の政府機関や大企業がエンドポイントの保護に奔走するパニックを引き起こしました。SolarWindsのソフトウェアを利用するほぼすべてのユーザーが侵害され、ソフトウェアサプライチェーンにおけるサイバーセキュリティと防御がいかに重要であるかが浮き彫りとなりました。

サイバーセキュリティが重要であることは言うまでもありませんが、サプライチェーンという文脈において、それは具体的に何を意味するのでしょうか。

一般的な開発チームにおけるサイバーセキュリティの現状

日々膨大な量のソフトウェアが開発され、年間数十億行ものコードが生成されています。私たちのデジタルライフへの依存度が高まるにつれ、その需要は増すばかりです。世界の開発者人口は2024年までに約2900万人に達する見込みですが、現時点で、彼らのセキュアコーディング能力を評価・認定する公的な資格は存在しません。すべての開発者が脆弱なコードを書いたり再利用したりしているわけではありませんが、私たちがデータ管理を委ねているソフトウェアに、基本的なセキュリティ上の欠陥が混入し続けるリスクは確実に存在します。

開発者は、機能の実装速度やコードのリリース速度で評価されるのが一般的です。多くの組織において、セキュリティは成功の指標とは見なされてきませんでした。しかし、ソフトウェア開発の初期段階で一般的なセキュリティバグを防ぐことの重要性に気づく企業が増え、その風潮は変わりつつあります。とはいえ、認識と実践は別物です。大学等の教育機関ではセキュアコーディングの文脈がほとんど教えられていないため、その不足分を補うのは多くの場合、現場の役割となります。スキルアップや知識共有が不定期であったり、実務と乖離していたりすれば、効果は期待できません。こうして、スキル不足による脆弱性の連鎖という悪循環が続いています。

当然ながら、世界のサイバーセキュリティ問題を解決するのは、一般的なソフトウェア開発者の責任ではありません。高額な報酬を支払ってセキュリティ専門家を雇うのには理由があります。しかし、セキュリティの専門家は不足しており、開発者がその負担を軽減する役割を果たすことは十分に可能です。

では、壊滅的なサイバー攻撃を防ぐという観点において、私たちや、重要インフラや機密性の高い組織向けにソフトウェアを提供するベンダーは、どのような立場にあるのでしょうか。少なくとも、ソフトウェア調達の現状を根本から変える必要があります。

セキュアなソフトウェアサプライチェーンを阻む落とし穴

The tired adage of a chain only being as strong as its weakest link is, unfortunately, just as true when it comes to software supply. It really doesn’t matter if your company has come to the party with beefed up security best practices, investment in developer upskilling, and a move towards a functional DevSecOps environment (i.e. everyone sharing the responsibility for software being made as securely as possible); if you use software from a vendor that has security problems, you will inherit them into your ecosystem and bear the consequences.

Sure, the security team should be helping to assess the safety of third-party additions to the tech stack, but decisions can be made based on a business need with little choice among solutions. At this point, it can be a trust exercise. Does the vendor care about security as much as your company does? And can the vendor actually assess the risks as only you could understand them, as well as the assets you need to protect?

Transparency is an all-important factor in assessing the security viability of vendor software additions. Are they up-front with their own security practices? They should take pride in their approach to keeping data safe, and it should be a top priority. If the security practices are not published anywhere, or no information is available, there is a strong chance that security is not top-of-mind. The vendor should be able to answer technical questions, and independent certifications like ISO27001 and SOC2 wouldn’t hurt either. Also, if you can’t “look under the hood” and scan for vulnerabilities as part of your own internal due diligence and security practices, forget it. 

ソフトウェア需要の急速な高まり、特にベンダーのコードを既存システムに組み込んで新たな用途に活用する場合、ベンダーと購入者の双方が高い意識を持つ必要があります。そして双方とも、開発者が現場の最前線に立ち、リリース前に一般的なセキュリティバグや欠陥を摘み取れるようにしておくべきです。既存の複雑な技術スタックに新たな要素を追加すれば、何百、何千もの依存関係が侵害される可能性があり、小さな失敗が壊滅的な事態を招きかねません。

では、解決策は何でしょうか。すべて自社でゼロからコードを書くことでしょうか。1998年ならそれも理にかなっていたかもしれません。しかし、もはや最寄りの洗車場を探すのに「Ask Jeeves」を使わないのと同じように、現代の状況に即した現実的な保護策を導入する必要があります。

特効薬はありませんが、解決策は存在します

購入者にとって、ベンダーのソフトウェアや開発慣行のセキュリティ評価は、全体的なセキュリティプログラムおよびリスク軽減計画の優先事項であるべきです。ベンダーの認証、慣行、そして開発者のセキュリティに対する評判について問いかけてください。

ベンダー（およびソフトウェアを開発するすべての企業）は、セキュリティを最優先していることを証明する準備が必要であり、スキルアップに注力すべきです。セキュリティスキルを持つ開発者は需要が高く、適切なツールとサポートがあれば、既存のチームから育成し、一般的な脆弱性に起因する攻撃を防ぐ力を身につけさせることができます。ただし、ありきたりな研修を押し付けるのはやめましょう。既存のワークフローを補完するセキュリティツールを活用し、彼らが成長できる時間を与えてください。可能な限りハードルを下げ、ビジネスを支えるコードから厄介なバグが減っていく様子を見守りましょう。

結論として、ソフトウェアのリスクはサプライチェーンの一部となった瞬間に増幅され、すべてのユーザーや脆弱なコンポーネントを利用するシステムに影響を及ぼします。ベンダーが導入企業と同等のセキュリティ意識を持っていなければ、あるいは双方のセキュリティプログラムが不十分であれば、SolarWindsのような壊滅的で広範囲に及ぶサプライチェーン攻撃が常態化することは避けられません。これは、すべての人にとって重大な問題です。