0日目は開発の1日目でした

コロンビア大学の最近の研究によると、私たちは1日に70以上の決断に悩まされているそうです。 これは重要なものだけを数えた場合の話で、コーネル大学の以前の研究では、私たちは毎日、食べ物に関してだけで 200 以上の決定を下していることが判明しています。

私たちが一日に下す決断の多くは、長期的には重要ではありません。 影響は最小限であり、ほとんどは「良い」または「悪い」に分類できません。 それらは単に私たちが選択したものにすぎません。 しかし、いくつかの選択は重大な結果をもたらします。 いくつかは意図的で、事前に考えて作られています。 その他は意図せず、後からわかることもあります。

後から考えれば明らかないくつかの意図しない結果は、アプリケーションのセキュリティに関連しています。 

選択肢: プラットフォーム、フレームワーク、コンポーネント  

開発の初日から選択が行われています。 こうした選択の多くは、プラットフォームやフレームワーク、ライブラリ、サードパーティのコンポーネントを中心に展開されます。 開発中にこのような選択が数多く行われます。 現在、アプリケーションの 80 ～ 90% はオープン/サードパーティ ソース コンポーネントで構成されていると推定されています。 オープン/サードパーティソースのコンポーネントを組み込むことにつながる各選択には、特にアプリケーションのセキュリティに関して潜在的な結果が伴います。 Black Duck Software の分析によると、商用ソフトウェア 1 台あたり平均 105 個のオープン ソース コンポーネントが含まれています。

表面的には、その結果はそれほど恐ろしいものではありません。 結局のところ、 Contrast Security の調査によると、ソフトウェア ライブラリが脆弱性のわずか 7% を占めていることがわかりました。  Black Duck は、アプリケーションごとに平均 22.5 件のオープン ソースの脆弱性を発見しました。 これらの脆弱性の 40% は「深刻」と評価されました。 それでも、アプリケーションの残りの 10 ～ 20% (カスタム コード) がアプリケーションの脆弱性の大部分の原因であることを考慮すると、これは最小限です。

残念ながら、脆弱性の大部分は CVE を通じて公開されておらず、サンプルのエクスプロイト コードは攻撃者が簡単にアクセスできる状態になっています。 同じコンポーネントやライブラリが何千もの Web アプリケーションで使用されている環境では、攻撃者はターゲットを見つけるためにそれほど努力する必要はありません。 現在、アプリやウェブサイトの構築に使用されるテクノロジーの使用状況を追跡しているbuiltwith.comでは、Apache Strutsに依存するライブサイトが約4万件あると数えています。 Apache Struts 2 の公開された脆弱性が悪用され、インターネット上で軽いパニックが引き起こされたことは、ほとんどの人が知っています。 OpenSSL など、他の頻繁に使用されるオープンソースおよびサードパーティ ライブラリに関連する重大な脆弱性の公開によっても同様のパニックが発生しています。

しかし、問題になる可能性があるのは、ライブラリやサードパーティのコンポーネントを含めるか、オープンソース フレームワーク上にアプリを構築するかという選択だけではありません。 開発中に行ったその他の選択も、特に安全でない開発手法につながる場合には、深刻な影響を及ぼす可能性があります。

選択肢: セキュリティとスピードのトレード

セキュリティがスピードと引き換えにされたと聞いても、驚くことはありません。 それは常にそうでした。 2014 年に 504 人のセキュリティ専門家を対象にマカフィーが実施した調査では、「調査対象となった組織のおよそ 3 分の 1 のオペレーターが、ファイアウォールのセキュリティ機能を定期的に無効にすることでネットワーク パフォーマンスの向上を試みていることを認めた」ことが判明しました。

結局のところ、開発も同じです。 実行速度ではなくパイプライン速度に重点を置いています。 よりタイムリーなアプリケーションリリースや市場へのアップデートの要求に応えるために、開発中のセキュリティを完全に省略していることを認める企業が多くあります。 2017 年に Arxan | IBM がモバイルおよび IoT 開発者を対象に実施した調査では、回答者の 26% がモバイル アプリのセキュリティ問題をまったくテストしておらず、ほぼ半数 (48%) が IoT アプリをテストしていないことがわかりました。  セキュリティがしばしば省略される理由として、69% が成果を出すことへのプレッシャーを挙げました。

今年の夏に開催された当社の顧客向けイベント「Agility」の参加者に対するアンケートで、これが現実であることが再確認されました。 半数以上（62%）が、組織内でセキュリティをスピードと交換したことを認めました。

そして、発見された脆弱性に組織がどのように対処するかに関して選択が行われます。 Black Duck の分析により、2018 年にスキャンされたアプリケーションの 10% が依然として2014 年の Heartbleed 脆弱性に対して脆弱であることが明らかになりました。 Ponemon が実施した ServiceNow の調査では、驚くべきことに、侵害被害者の 57% が、利用可能なパッチをインストールすることで侵害を防ぐことができたと回答しました。 

選択には結果が伴う

開発初日から導入後まで、アプリケーション スタック全体のセキュリティに関して行う選択は重要です。 これらの選択は、昼食にハンバーガーやサラダを食べるのと同等ではありません。IT 部門やビジネス部門だけでなく、アプリ プロバイダーがセキュリティを真剣に受け止めていることに依存している顧客にも影響を及ぼす可能性がある決定です。 

自分のデータが漏洩したことを知らせる「アプリユーザー様」宛ての手紙を一度も受け取ったことがないと断言できる人はほとんどいないでしょう。 これはセキュリティを怠ってよいということではありません。逆に、私たちは顧客の個人情報やプライベートな情報をより良く保護するよう努めるべきです。

そのための最善の方法は、開発初日からのすべての選択が、開発するアプリケーションのセキュリティを向上させる機会であることを認識することです。 意識的に、そして賢明に選択してください。