この記事のバージョンは、次のように掲載されました。 Infosecurity Magazine.この記事は更新され、ここにシンジケートされています。

‍

この2年間は、まあ、誰にとっても火の洗礼のようなものでしたが、私たちの多くが事実上一晩でリモートワークのモデルに落とされたため、ほとんどの組織のサイバーセキュリティの青写真が試されることになったのです。特に、パンデミックが始まって以来、サイバー犯罪の報告件数が300%も増加したことを受け、私たちは業界として、より高度に適応する必要がありました。

私たちは皆、いくつかの教訓を学びました。一般的なサイバーセキュリティだけでなく、コードレベルのソフトウェアのセキュリティと品質もより真剣に受け止められているという事実に、私は安心感を覚えています。ソフトウェアのサプライチェーンの安全性に関するバイデンの大統領令は、特にSolarWindsの大量侵入事件をきっかけに、重大な問題を浮き彫りにしました。私たち全員がセキュリティにもっと関心を持ち、 測定可能なセキュリティ意識を持って脆弱性を減らす努力をする必要があるという考え方は、間違いなく会話の中でもっと大きな部分を占めています。

しかし、サイバー犯罪者との戦いにおいては、できるだけ彼らと歩調を合わせ、予防的な考え方で彼らの遊び場を先取りすることが必要です。 

来年から波に乗ってきそうなのは、こんなところでしょうか。

メタバースは新たな攻撃対象

メタバースはインターネットの次の進化かもしれませんが、ソフトウェアやデジタル環境のセキュリティに対する多くの産業の取り組み方において、同様の変革はまだ実現されていないのです。 

フィッシング詐欺のような一般的なサイバーセキュリティの落とし穴は避けられないだろうが（そして、誰もがメタバースに足を踏み入れる間は、おそらくたくさんある）、この没入型の仮想世界を実現する実際のインフラとデバイスは、安全でなければならないだろう。スマートフォンが私たちのオンライン生活を助けたように、VRヘッドセットのような周辺機器は、ユーザーデータの山への新しいゲートウェイとなるのです。IoTガジェットを安全にするためには、ますます複雑化する組み込みシステムのセキュリティが必要ですが、メインストリームのVR/ARという勇敢な新世界も例外ではありません。Log4Shellの悪用で明らかになったように、コードレベルの単純なエラーは、脅威の仕掛け人のためのバックステージパスへと発展し、シミュレーションされた現実では、すべての動作が盗まれる可能性のあるデータを作り出します。  

メタバースの成功には、暗号通貨の実用化（最新のミームコインの乱発ではなく）と、NFTのような価値あるアイテムの導入が必要です。つまり、私たちの現実の富、アイデンティティ、データ、生活は、人々を危険にさらす新しい「ワイルド・ウエスト」に開放される可能性があるのです。私たちエンジニアは、壮大な機能や拡張に狂奔する前に、この新しい広大な攻撃対象領域をゼロから最小化することを優先させるべきです。

Log4Shellをきっかけとした法整備

多くの開発者が大混乱に陥り、広く使われているログ記録ツールLog4jの悪用可能なバージョンのインスタンスや依存関係を見つけようと躍起になっていましたが、この休暇が楽しいものであったとは思えません。 

このゼロデイ攻撃は、6年以上たった今でも悪用されている壊滅的なHeartbleed OpenSSL脆弱性とLog4Shellが比較され、過去最悪の攻撃とされています。このタイムラインが何であれ、私たちは将来にわたってLog4Shellの二日酔いに悩まされることになるでしょう。Heartbleedから学んだ教訓、少なくともできるだけ早くパッチを配布し、実装する必要性という点では、多くの組織が自らを保護するために十分迅速に行動していないことは明らかです。企業の規模にもよりますが、パッチ適用は非常に困難で官僚的であり、部門横断的な文書化と実装を必要とします。IT部門や開発者は、使用されているすべてのライブラリ、コンポーネント、ツールについて百科事典のような知識を持っていないことが非常に多く、混乱やアプリケーションのダウンタイムを最小限に抑えるための厳しい導入スケジュールに阻まれています。このような作業方法には正当な理由がありますが（誰も作業に支障をきたして何かを壊したくはない）、パッチが遅すぎるということは、カモにされているのと同じです。

SolarWindsの攻撃がソフトウェアのサプライチェーンのゲームを変えたように、Log4Shellの後にも同じようなことが起こると私は予想している。一部の重要な業界では、すでにパッチ管理の義務付けや推奨が行われていますが、広く法制化されるかは別の話です。予防的なソフトウェア・セキュリティは、緊急のセキュリティ・パッチを完全に回避するための最善の方法ですが、セキュリティのベスト・プラクティスでは、パッチ適用が譲れない優先事項であることが規定されています。私は、このことが話題になり、迅速かつ頻繁にパッチを適用するようにという微妙な勧告につながると考えています。 

アーキテクチャのセキュリティがより重視される（そして開発者はまだ準備ができていない）

OWASP Top 10 2021では、新たにいくつかの重要な項目が追加され、またインジェクションの脆弱性が首位から3位に転落するというサプライズもありました。これらの新しい項目は、開発者が安全なコーディングとセキュリティのベストプラクティスを身につけるための「第2段階」のようなもので、悲しいことに、適切に訓練されない限り、ほとんどの人はリスクを減らすためにプラスの影響を与えることができないのです。

コードによくあるセキュリティ・バグに対処するには、開発者がセキュリティ・スキルを身につける必要があることは以前から分かっていましたし、組織も開発者主導の予防を前提にした方が反応がよいです。しかし、「安全でない設計」が OWASP トップ 10 に入っており、単一のタイプのセキュリティバグではなく、アーキテクチャのセキュリティ問題のカテゴリであることから、開発者は、一度習得した基本をさらに押し進める必要があります。脅威のモデル化に関する学習環境（理想的にはセキュリティチームのサポートが必要）は、開発者のスキルアップに成功すれば大きなプレッシャーとなりますが、現状ではほとんどのソフトウェアエンジニアにとって大きな知識格差となっています。

このような事態に対処するには「村が必要」であり、組織は、開発者のワークフローを大きく崩すことなく、彼らの好奇心を誘い、前向きなセキュリティ文化を作り出す役割を果たすことができる。

この記事のバージョンは SCマガジン.この記事は修正され、ここにシンジケートされています。
泥棒に入られたことがある人

なら、「何か変だ」という最初の沈んだ気持ちと、その後に「本当に泥棒に入られたんだ」という実感を理解できるはずです。その結果、フォートノックスに匹敵するようなセキュリティ対策に軸足を移すことは言うまでもありません。

今、あなたの家が泥棒に入られたとしましょう。泥棒は自分たちで鍵を作ってしまったのです。泥棒は好きなように出たり入ったりしながら、気づかれないように忍び足で移動します。そしてある日、冷凍庫に隠していた宝石がなくなっていること、金庫が空になっていること、身の回りのものが荒らされていることに気づくのが遅すぎるくらいです。これは、組織がゼロデイサイバー攻撃の犠牲になった場合に直面する現実と同じです。2020年、Ponemon Instituteの調査によると、成功したデータ侵害の80%はゼロデイ攻撃によるものであり、悲しいことに、ほとんどの企業はこの統計値を大幅に改善する能力がないままであることが明らかになりました。

ゼロデイ攻撃は、定義上、脅威の主体が最初に侵入したため、開発者が既存の脆弱性を発見し、パッチを適用する時間をゼロにするものです。被害が拡大すると、ソフトウェアとビジネスへの風評被害の両方を修正するために、猛烈な奔走が必要になります。攻撃者は常に優位に立っており、その優位性を可能な限り閉じることが重要です。 

誰も欲しがらないクリスマスプレゼント「Log4Shell」は、現在インターネット上で爆発的に広まっており、10億台以上のデバイスがこの壊滅的なJavaの脆弱性の影響を受けていると言われています。過去最悪の0day攻撃となりそうで、まだ始まったばかりです。公開の数日前から悪用が始まったとする報道もありますが、2016年のBlack Hat Conferenceで行われたプレゼンテーションによれば、これは以前から知られていた問題であったことが示唆されます。痛そう。さらに悪いことに、この脆弱性は悪用が非常に簡単で、地球上のあらゆるスクリプト・キディや脅威者がこの脆弱性を利用して大金を手に入れようと狙っています。

では、ソフトウェア開発プロセスで見落とされた脆弱性はもちろん、巧妙で邪悪な脅威から身を守るための最善の道とは何でしょうか？それを見てみよう。 

大規模なターゲットに対するゼロデイ攻撃は稀である（そして高価である）

ダークウェブではエクスプロイトの巨大市場が存在し、ゼロデイはかなりの金額で取引される傾向にあり、この記事の例では執筆時に250万ドルで取引されています。Apple iOSの悪用であると報告されている, それはセキュリティ研究者の提示価格が屋根を通してであることは驚くことではありません, 結局, これは確かに何百万ものデバイスを危険にさらすためのゲートウェイかもしれない, 何十億もの機密データの記録を収穫, そしてそれが発見されてパッチを適用する前にできるだけ長くそれを行う.

しかし、そんな大金、誰が持っているのでしょう？一般的に、組織化されたサイバー犯罪組織は、特に人気の高いランサムウェア攻撃など、価値があると判断されれば資金を調達します。しかし、世界各国の政府や防衛省は、脅威のインテリジェンスに利用できるエクスプロイトを求める顧客の一人であり、よりポジティブなシナリオでは、企業自身が災害を軽減できるように、潜在的なゼロデイエクスプロイトを購入する可能性があります。 

2021年にはゼロデイエクスプロイトのライブ発見の記録が更新されましたが、あらゆる弱点を探られる危険性が最も高いのは、大規模な組織、政府部門、インフラストラクチャです。ゼロデイ攻撃の可能性から完全に逃れる方法はありませんが、寛大で体系的なバグバウンティプログラムを提供することで、多少なりとも「勝負に出る」ことは可能です。ダークウェブ・マーケットプレイスであなたのソフトウェアの城の鍵が提供されるまで待つのではなく、合法的なセキュリティ専門家を味方につけ、倫理的な開示と修正の可能性に見合った報奨金を提供しましょう。

そして、それがたまたまゼロデイ脅威であった場合、Amazonギフトカード以上の出費が必要になると考えてよいでしょう（そうすることに意義があります）。

ツールは、セキュリティ担当者の責任になる可能性があります。

セキュリティツールの煩雑さは以前から問題視されており、平均的なCISOが管理するセキュリティツールは55から75にものぼります。Ponemon Instituteの調査によると、世界で最も分かりにくい（比喩的な）スイスアーミーナイフであることに加え、企業の53%はそれらが効果的に機能していることにさえ自信を持っていないことが分かっています。また、別の調査では、自社のセキュリティ対策が「完全に有効」と考えているCISOは、わずか17%であることが明らかになりました。

燃え尽き症候群、需要に応じたセキュリティ・スキルの人材不足、俊敏性の必要性などで知られるこの分野で、セキュリティ専門家がデータ、レポート、膨大なツールセットの監視といった形で情報過多の仕事を強いられるのは負担が大きいものです。これはまさに、重要なアラートを見逃す原因となるシナリオであり、Log4jの弱点を適切に評価することになったとき、そうであったかもしれないのです。 

予防的セキュリティには、開発者主導の脅威モデリングが必要です。

コードレベルの脆弱性は開発者によってもたらされることが多く、セキュアなコーディングスキルを構築するためには、的確な指導と定期的な学習経路が必要です。しかし、次のレベルのセキュアな開発者には、ソフトウェア作成プロセスの一環として脅威モデリングを学び、実践する機会が与えられています。

自分たちのソフトウェアを最もよく知っているのは、そこに座ってソフトウェアを作成した開発者であることは、驚くにあたらないでしょう。彼らは、ユーザがソフトウェアをどのように操作しているか、機能がどこで使われているか、そして、十分なセキュリティ意識がある場合には、ソフトウェアが破損したり悪用されたりする可能性のあるシナリオについて強力な知識を持っています。

Log4Shellの悪用に話を戻すと、残念ながら、専門家や複雑なツールセットによる検出を免れた致命的な脆弱性が、ライブラリがユーザー入力をサニタイズするように設定されていれば、全く発生しなかったかもしれないというシナリオが見えてきます。しかし、もしライブラリがユーザー入力をサニタイズするように設定されていれば、このような事態は起きなかったかもしれません。そうしなかったのは、利便性を高めるための不明瞭な機能だったようですが、そのために悪用するのが非常に簡単になってしまいました（SQLインジェクションレベル、確かに天才ではありませんね）。もし、脅威のモデル化が、セキュリティに精通した鋭い開発者のグループによって行われていたなら、このシナリオは理論的に検討されていた可能性が高いでしょう。

優れたセキュリティ・プログラムには感情的な要素があり、人間が作り出した問題を解決するためには、人間の介入とニュアンスが重要な要素となります。脅威のモデル化には共感と経験が必要であり、ソフトウェアやアプリケーションのアーキテクチャレベルで安全なコーディングと設定を行うことも効果的である。これは、開発者に一夜漬けでやらせるべきことではありません。しかし、この重要なタスクについてセキュリティチームのプレッシャーを軽減できるレベルまで開発者をスキルアップさせる明確な経路があれば理想的です（そして、それは両チーム間の信頼関係を築く素晴らしい方法なのです）。 

ゼロの日はイヌの日

ゼロデイに対処する次の段階は、できるだけ早くパッチを配布し、脆弱なソフトウェアを使用するすべてのユーザーができるだけ早く、そして確実に攻撃者に先を越される前にパッチを適用することを必死に願うことです。Log4Shell は、何百万ものデバイスに組み込まれ、ソフトウェアビルドに複雑な依存関係が生じる中で、その耐久性と効力はHeartbleed を凌ぐかもしれません。

現実的には、この種の陰湿な攻撃を完全に阻止する方法はありません。しかし、あらゆる手段を用いて高品質で安全なソフトウェアを作成し、重要なインフラストラクチャと同じ考え方で開発に取り組むことで、私たち全員が戦うチャンスを得ることができるのです。

開発者は、さまざまな方法で自分のコードを作成し、テストしています。その一つがユニットテストです。ユニットテストは、自分のコードの最小部分をテストする非常にポピュラーな手法です。ユニットテストがうまく書かれていれば、コードの品質を向上させるだけでなく、コストや開発期間の削減にもつながります。テスト駆動開発（TDD）の一環として行われるかどうかに関わらず、ユニットテストは現代の開発手法の重要な部分を占めており、その重要性から多くのテストフレームワークが作られています。

しかし、適切なテストフレームワークやガイダンスがない場合、ユニットテストは、品質や読みやすさよりもカバレッジや量に焦点が移ることで、複雑で読みにくいものになってしまいます。これは、多くのユニットテストを持つ大規模で活発なコードベースでは特に顕著です。

優れたテストフレームワークは、シンプルで品質テストに特化した読みやすいテストを作成するのに役立ちます。また、コードの使用方法を文書化するのにも役立ちます。そのようなフレームワークの一つがAssertJです。

AssertJは、Javaでユニットテストを書くための流暢なAPIです。AssertJでは、文脈を考慮したオートコンプリートを使用して、英語のように読みやすいテストアサーションを書くことができます。多数のテストがあり、その読みやすさを向上させる必要がある場合は、すべてのテストをAssertJに移行し、将来のテストでもAssertJを最大限に活用できるようにするとよいでしょう。

しかし、完全な移行を手動で行うには膨大な労力と時間がかかるため、他の開発作業のために省略されたり、後回しにされたりすることがよくあります。そこで、私たちはSensei を作成しました。これは、高度にカスタマイズ可能な IntelliJ プラグインで、現在のユニットテストを AssertJ に移行し、今後のテストを正しい方法で記述できるようにします。このプラグインは、Senseiの開発チームが作成した多数のレシピ（ルール）を用いて行われます。Sensei では、一度だけの移行を行うことも、一度に一つのテストを AssertJ に移行する漸進的なアプローチを取ることも簡単です。AssertJに移行した後も、レシピは開発者がユニットテストを書く際に迅速な修正を適用するのに役立ち、ユニットテストがコードベース全体で均一、標準、一貫性のあるものになります。

‍

についてSensei

Sensei は、入力中に望ましくないコードをスキャンして修正するための高度にカスタマイズ可能な IntelliJ プラグインで、何百ものダウンロード可能なコード変換と移行レシピ（ルール）に加え、独自のコードを作成する機能も備えています。Sensei を使用することで、開発者は入力中に不適切なコードパターンを修正することができ、高品質なコードをより早く提供することができ、最終的にはチームやプロジェクト全体で一貫した標準的な方法でコードを記述することができます。

ここでは、Sensei がどのようにしてユニットテストを AssertJ を使用するように移行するのに苦労しないかを理解するのに役立つと思われるサンプル移行の例を紹介します。

なぜAssertJはユニットテストを書くのに最適なフレームワークなのか？

このJUnitのアサーションのようなテストを書くのではなく

のように、AssertJで書くことができます。

つまり、アサーションを英語の文章のように左から右に読むことができ、どちらが期待されているか（この場合はサイズ3）が明確になります。このようにアサーションを間違った方向に書いてしまったことが何度かありませんか？

これらは簡単な例に過ぎません。チェックやアサーションが複雑になればなるほど、 AssertJ はテストをシンプルで読みやすいものにするのに役立ちます。また、IDE のオートコンプリートともうまく連携しています。と入力するとすぐに

を実行すると、myResult のタイプに応じて、チェックできるすべての項目がポップアップ表示されます。コレクションであれば、その内容やサイズ、特定の値や型を含んでいるかどうかなどを確認できます。

AssertJは、プリミティブとそのボックス型、アトミック型、コレクション、配列、マップ、日付、java.time、Futures、ファイル/パス、入力ストリーム、Throwable、URLをすぐにサポートします。また、Hamcrest用のお気に入りのカスタムMatcherがあれば、HamcrestConditionを介してAssertJで使用することができます。

読みやすいユニットテストは、開発者が通常の英語でコードを読むことを容易にするため、カバレッジを高めるだけでなく、間違いを見つけることも容易になります。

従来のユニットテストをAssertJに移行するためのレシピ

AssertJを使って一貫したコードを書くためのクックブックを作成しました。このクックブックは、以下のフレームワークからアサーションをAssertJに移行する際に役立ちます。JUnit 3、JUnit 4、JUnit 5、FEST-Assert。

このクックブックは、Sensei で設定してすぐに使用することができます。また、Sensei 用のインストール手順はこちらをご覧ください。

コードを書きながらより良いユニットテストを書く - JUnitの品質を徐々に向上させる

Sensei AssertJのクックブックは、他のフレームワークからの移行を支援するだけではありません。テストの書き方を改善したり、古い習慣を断ち切ったり、よりイディオム的なAssertJテストを書いたりするのに役立つレシピが掲載されています。

例えば、次のようなテストを書いたとします。

おそらく、上記の移行レシピの一つを使って、このJUnitスタイルのアサーションから移行したのではないでしょうか。

Sensei の AssertJ のクックブックには、この古いスタイルのアサーションも検出できるレシピがあり、これへの変換を提案しています。

別のレシピでは、次のように変換できます。

にしました。

一度だけの移行で、チーム間で統一されたコーディング作業が可能になります。Sensei

上記の例から、AssertJを使用するためにユニットテストを手動で移行することは、より良いテストを書くために費やすべき多くの労力と時間を必要とすることがわかります。Sensei を使用すれば、自信を持ってユニットテストをAssertJに簡単に移行することができます。Sensei は、このような柔軟性を提供することで、コードの移行を容易にします。

ユニットテストの移行は、プロジェクト全体で一貫性のあるコードを書くためにSensei を利用する多くの方法の一例に過ぎません。アンチパターンや、プルリクエストや自分でコーディングする際に頻繁に遭遇する手動でのコード変換には常に注意を払う必要があります。開発者が見落としがちなコーディングガイドラインがあれば、そのガイドラインをレシピ化することで、開発者が自信を持って承認されたコード変換を適用できるようになります。

ご質問があれば、ぜひお聞かせください。sensei-scw.slack.comのSlackにご参加ください。

コード（レガシーコード）の移行は楽しいものではありません。移行には膨大な計画と努力が必要です。開発者にとって最もエキサイティングでモチベーションの上がる仕事ではないが、レガシーコードを新しいライブラリバージョンに移行するには、決意と適切な経験が必要だ。Joda-Timeからjava.timeへの移行は、綿密な計画と実行を必要とする移行の一つである。

もしあなたのJavaプロジェクトがJava SE 8以前に開始され、日付/時刻処理を使用しているなら、おそらくJoda-Timeを使用しているでしょう。Joda-Timeは優れたライブラリであり、SE 8以前の日付/時刻機能を処理するためのデファクトスタンダードです。

Java SE 8では、新しく改良された標準的なDate and Time API、通称「java.time (JSR-310)」が導入されました。Joda-Timeプロジェクトでは、java.time (JSR-310)への移行を推奨しています。

java.time(JSR-310)はJoda-Timeに大きな影響を受けていますが、下位互換性はなく、概念や用語も変わっています。そのため、Joda-Timeからjava.timeへの移行には、変更するコードの1行1行に注意を払う必要があります。これは時間のかかる作業であり、もっと簡単で自動化された移行方法があればと思ってしまいます。

私たちは、Sensei を使用してそれを作成しました。これは、お客様が定義したレシピ（ルール）に従ってコード変換を自動的に実行する IntelliJ プラグインです。再利用可能なレシピを定義することに時間を使い、反復的な移行作業を行う必要はありません。この自動化は、レガシーのJoda-Timeコードを変換するだけでなく、チームがIDE上でガイドラインに従って新しいコードを書くのにも役立ちます。

皆様のお役に立てるよう、Joda-Timeからjava.timeへの移行をより簡単に行うためのレシピを掲載した公開Sensei クックブックStandardization on java.time (JSR-310)を作成しました。これは、Joda-Timeからjava.timeへの移行をより簡単にするためのレシピが含まれており、今後もレシピを増やしていく予定です。

ここでは、Sensei がいかにレガシーコードの移行を容易にするかを理解していただくために、サンプルの移行例をご紹介します。

反復的な手動移行から自動化されたコード変換へ

Joda-Timeからjava.timeにコードを1行移行する際に、いくつかの隠された罠を示す、新しいDateTimeの作成例を見てみましょう。次に、Standardization on java.time (JSR-310) cookbookからSensei レシピの一つを見て、どのようにこれらの情報を取得するかを紹介します。そうすることで、どの開発者でも同じ移行を繰り返し利用することができます。

この例では、DateTimeフィールドの値を表す7つのint型引数からJoda-TimeのDateTimeを作成しています。

これをjava.timeと同等のものに移行するにはどうしたらいいでしょうか？

このコンストラクタのJoda-Timeのjavadocにはこう書かれています。

デフォルトのタイムゾーンでISOChronologyを使用して、datetimeフィールドの値からインスタンスを構築します。

まず、java.timeの中にDateTimeクラスがあると思いがちですが、そんなものはありません。migrate from joda time to java time」でググると、Stephen Colebourne氏のブログ記事「Converting from Joda-Time to java.time」がヒットします。

これで良いスタートが切れ、java.time.ZonedDateTimeやjava.time.OffsetDateTimeを使う方向になりました。ここで最初の質問ですが、どちらを使えばいいでしょうか？Stephenのコメントから、おそらくZonedDateTimeだと思います。

ZonedDateTimeのjavadocを見ても、コンストラクタが全く見当たりません。Stephenのブログ記事に戻り、さらに下を読んでみます。

コンストラクションjava.timeにはファクトリーメソッドしかないので、文字列用のparse()メソッドは用意されていますが、変換はユーザーの問題です。

そこで、スタティックなファクトリーメソッドがあるはずです。スタティックメソッドを検索すると、似たようなものが見つかりますが、正確には同じではありません。

Joda-TimeのDateTimeコンストラクタと同様に7つのint型パラメータがありますが、注意して見ないと重要な点を見逃してしまいます。 これはJoda-Timeよりもjava.timeの方が精度が高く、ナノ秒単位で瞬間を測定するからです。これは、java.timeがJoda-Timeよりも精度を上げ、瞬間をナノ秒単位で測定するようになったためです。さらに、このメソッドはZoneIdを要求しますので、今までなぜZoneIdを必要としなかったのか、そして今なぜZoneIdを必要としているのかが気になるところです。

オリジナルのコンストラクタのjavadocには、デフォルトのタイムゾーンを使用すると書かれていましたが、デフォルトのZoneIdを取得する方法があるのでしょうか？

ZoneId の javadocにはコンストラクタが記載されていませんが、スタティック・メソッドを見ると、systemDefault()が使用できることがわかります。

さて、ZoneIdを整理したところで、ミリ秒からナノ秒への変換はどうすればいいのでしょうか。java.util.concurrent.TimeUnitを使って変換してみましょう。

このメソッドはlongを返しますが、私たちのメソッドはintを期待しているので、変換問題も解決しなければなりません。何か簡単なことをやってみましょうか。掛け算ですか？

これは動作しますが、少し違和感があります。すでにお気づきではないかもしれませんが、たった1行のコードを移行するために、かなりの時間と労力を費やしています。しかし、ご想像のとおり、このような編集を手作業で何度も行っており、なかなか改善されません。

しかし、java.time APIをもう少し詳しく見てみると、もう少し流暢に見える解決策を見つけることができます。

ZonedDateTimeにはミリ秒を設定する明確な方法はありませんが、ChronoField.MILLI_OF_SECONDをTemporalFieldとして使用し、with(TemporalField field, long newValue)メソッドを使用して設定することができます。

また、javaのドキュメントには、ナノ秒への変換を行ってくれると書かれています。

このフィールドで値を設定する場合は、NANO_OF_SECONDに1,000,000を乗じた値を設定するのと同様の動作になります。

そこで、ファクトリーメソッドでナノ秒に0を指定し、withメソッドで元の値とミリ秒の両方を持つZonedDateTimeを作成するだけでよいのです。

最終的な結果を見ると、たった1行のコードを変更しただけのように見えますが、これではたった1回のマイグレーションに費やした労力を示すことはできません。

‍

レシピを作成することで、より早く、より簡単に移行することができます。

Sensei は、この苦労して得た情報を他の開発者と共有するための方法を提供しています。これらの要件をすべて把握したレシピを作成することで、Sensei のユーザーは、マウスをクリックするだけでこの移行を実行できるようになります。

Sensei レシピは主に3つのセクションで構成されています。

• メタデータ
• 検索
• 利用可能な固定具

この呼び出しをjava.timeに相当するものに移行するためのSensei レシピ（YAMLレシピとも言えます）を見てみましょう。

DateTime foo = new DateTime(year, monthOfYear, dayOfMonth, hourOfDay, minuteOfHour, secondOfMinute, millisOfSecond);

メタデータセクション

メタデータセクションには、レシピとその使用方法に関する情報が含まれています。

検索セクション

Sensei レシピの検索セクションでは、このレシピがどのコード要素に適用されるかを指定します。

search:
instanceCreation:
args:
1:
type: int
2:
type: int
3:
type: int
4:
type: int
5:
type: int
6:
type: int
7:
type: int
argCount:7
type: org.joda.time.DateTime

‍

この検索セクションでは、私たちは

• instanceCreation（コンストラクタの使用法）を検索します。注：この他にも様々な検索対象があります。
• コンストラクタには7つの引数が必要で、これはargCountプロパティで指定します。
• 引数1～7はint型であること
• org.joda.time.DateTimeタイプのコンストラクタを探しています。

‍

修正プログラムのページ

availableFixesセクションでは、一致するコード要素に適用可能な1つまたは複数の修正を指定できます。各修正は複数のアクションを持つことができ、今回のケースでは、2つのアクションを実行する1つの修正があります。

‍

• クイックフィックス」メニューには、ユーザーがこのクイックフィックスを適用した場合に何が起こるかを示す修正プログラムの名称が表示されます。
• アクションリストには、このクイックフィックスで実行されるアクションが表示されます。
• rewriteアクションは、mustache テンプレートを使用してコード要素を書き換えます。変数や文字列置換関数を利用することができます。
• modifyAssignedVariableアクションは、このコンストラクタが変数への値の割り当てに使用されているかどうかを確認します。使用されている場合、このアクションは、変数がtype

‍

レシピを使ってコード変換を行う

レシピが書き込まれて有効になると、コードをスキャンして適用可能なセグメントをハイライトします。

以下のスクリーンショットでは、対象のコンストラクタがSensei によってマークされていることがわかります。マークされたコンストラクタにカーソルを合わせると、Recipe shortDescriptionとQuickfixオプションMigrate to java.time.ZonedDateTimeが表示されます。

‍

java.time.ZonedDateTimeへの移行」というクイックフィックスを選択すると、レシピで指定したアクションに応じてコードが変換されます。

‍

一度だけの移行で、チーム間で統一されたコーディング作業が可能になります。Sensei

Sensei は、その知識を実用的なレシピやクックブックにして、チーム内で共有することができます。一度だけの移行スプリントを計画することもできますし、Joda-Timeのコードに出会ったときにjava.timeに瞬時に変換するという漸進的なアプローチをとることもできます。移行を論理的な段階やステップで行う方法として、レシピを有効/無効にしたり、Sensei でスキャンするファイルの範囲を拡大/縮小したりすることができ、コードの移行を苦痛に感じさせない柔軟性があります。

ライブラリの移行は、プロジェクトを標準化するためにSensei を利用できる多くの方法の一例に過ぎません。アンチパターンや、プルリクエストや自分でコーディングしているときに頻繁に遭遇する手動のコード変換を常に探しておくことができます。開発者が見落としがちなコーディングガイドラインがあれば、そのガイドラインをレシピに変換して、開発者が承認されたコード変換を自信を持って適用できるようにすることができます。

ご質問があれば、ぜひお聞かせください。sensei-scw.slack.comのSlackにご参加ください。

開発者であれ、QAであれ、エンジニアリング・リードであれ、あるいはAppSecの専門家であれ、何らかの形でソフトウェアを扱っていれば、セキュリティは仕事の一部であることは間違いありません。ソフトウェアの脆弱性を指摘するのはセキュリティチームの仕事ですし、そもそも欠陥のないコードを書くように最善を尽くすのは開発者の仕事です。しかし、これらの仕事をできる限り効率的かつ効果的に行うためには、アプリケーションが実行されるコードから始めて、すべての関係者がセキュリティの脅威に対して協力することが重要です。 

しかし、セキュアコーディングを効果的に学び、その知識を維持することは、本質的に難しいことのように思われがちです。適切なツールがあれば、その必要はありません。しかし、適切なトレーニングに投資することをステークホルダーや上司に納得させるのは、必ずしも容易ではありません。トレーニングは、コンプライアンス上の問題を解決するためだけに選択されることが多く、開発者の日常業務とは無関係であることが多いのです。しかし、もし開発者がリアルタイムで、自分が日常的に使用している言語やフレームワークを使って、楽しみながらセキュリティについて学ぶことができたらどうでしょうか？そして、その上、さらに組織は同時に業界標準に準拠することができます。

私たちはあなたを応援します。ここでは、開発者に焦点を当てたセキュリティ・コーディング・トレーニング・プログラムに賛同してもらうために、組織内の同僚、リーダー、最終的な意思決定者から忠誠心を得るための戦略を紹介します。   

ソフトウェアの脆弱性を最初から回避することで、計り知れないほどの時間と費用を節約できる

繰り返されるセキュリティ問題の発見、報告、修正に多くの時間を費やしていませんか？それはあなただけではありません。 

次のようなシナリオを想像してみてください。AppSecが脆弱性を発見して開発に報告すると、開発者は関連するトレーニングレッスンに参加し、その欠陥を修正する方法だけでなく、将来同じ過ちを犯さないようにする方法を学びます。その結果はどうなると思いますか？その開発者は、関連性のあるそのレッスンを覚えている可能性が高く、同じミスを繰り返す可能性は低くなります。つまり、あなたがセキュリティチームで働いている場合、その開発者が知らずに再びその脆弱性を作る可能性が1人減り、同じ開発者が戻って再び修正しなければならない可能性が1人減るということです。

お客様であるContrast Security社のビデオでは、同社の開発チームにとってリアルタイムのトレーニングがいかに強力であるかが紹介されています。

もし、すべての開発者が定期的なセキュアコードトレーニングに参加し、セキュリティ問題をリアルタイムで学べるツールを手に入れたとしたら、素晴らしいソフトウェアを作成したり、セキュリティプログラムに取り組んだりするために取り戻せる時間は計り知れないものになるでしょう。このようなツールに投資することは、あなたの組織にとってかなり良いことだと思いませんか？ 

もし、あなたがセキュリティのスキルアップのために使いたいと思う素晴らしいツールを見つけたら、次のようなことが考えられます。 Secure Code Warriorこれは、あなたの組織内のCISOやCTOに売り込むための素晴らしい議論です。 

権限を与えられた開発者は、より良い結果をもたらし、彼らはより幸せになります。

経営陣にとって、時間とお金はもちろん重要ですが、仕事の満足度も重要です。満足度の高い社員は、より良い結果をもたらし、仕事を長く続け、ポジティブな職場環境に貢献します。だからこそ、キャリア形成やトレーニングは、コストではなく投資なのです。そして、そのトレーニングが実際に楽しく、関連性のあることを教えてくれるとしたら？それこそが、成功への金字塔なのです。 

素晴らしいことに、開発者は自分の仕事にとってセキュリティがいかに重要であるかを知っているため、一般的にセキュリティを学ぶことに高いモチベーションを持っています。私たちは、Evans Data Corporationとの共同研究で、世界中の開発者を対象に調査を行い、開発者がセキュリティを学びたい理由を明らかにしました。 

1. 生産性や効率性が向上する
2. 好奇心旺盛で、個人的に興味を持って学んでいる
3. 安全でないコードに起因する問題を回避したい。
4. キャリアアップの可能性があると理解している
5. 人的資源をより効率的に活用することができる
   

(ホワイトペーパーの全文はこちらからダウンロードできます)

唯一の問題は、ほとんどの安全なコーディングトレーニングが彼らを失望させていることです。日々の仕事とは関係がなく、正直言って退屈なのです。これらの特徴は、情報の保持と実際の学習という点で、通常は良い結果をもたらさない。しかし、learning platform が開発者中心で、楽しく、魅力的で、仕事に関連したものであれば、実際に結果を出すことができ、安全なコードを書きたいと思う力のある個人を生み出すことができるのです。開発責任者であれ、CISOやCTOであれ、あなたの上司が、開発者が安全なコードを書くことに興味を持ち、そのためのスキルを持つことを望まないわけがありません。

セキュリティへの理解がエンジニア全体のレベルアップにつながる 

エンジニアは、ソフトウェアがどのように攻撃されやすいかを理解すると、そのことを念頭に置いて仕事をするようになります。

それだけでなく、質の低いコードにはソフトウェアの脆弱性が含まれている可能性が高く、開発者が知らず知らずのうちにそのコードに脆弱性を混入させてしまうこともあります。なぜか？なぜなら、開発者の仕事の多くは、コードを読み、変更することだからです。コードが不完全に構成されていたり、お粗末なロジックが使われていたりすると、それらの作業に時間がかかり、何かを変更して誤って重大なセキュリティバグを混入させてしまうことになるのです。

セキュリティへの理解があり、問題を回避する方法がわかっていれば、コードの全体的な品質や、偶然に簡単にバグが発生しないような書き方についても真剣に考えるようになります。セキュリティトレーニングはWin-Winの関係です。開発者は、安全なコーディングについて学ぶだけでなく、その間に優れたエンジニアになることができるのです。 

数には力がある

セキュアコーディング（learning platform ）を採用するためにリーダーから賛同を得るためのもう一つの優れた戦術は、同僚に協力してもらうことです。セキュリティの知識を高めることに関心のある開発者が多ければ多いほど、経営陣やC-suiteに投資をするよう説得することが容易になります。

では、どうすればいいのでしょうか？ほとんどの開発者が、セキュリティを向上させる必要性を理解し、学びたいと思っていることを考えると、それほど難しいことではないはずです。secure code warrior の開発者向けショーケースを見て、私たちの製品を少しだけ見て、安全なコーディングスキルを試してみることもできます。安全でないコードがもたらす影響を目の当たりにし、セキュリティを学ぶことが楽しいことだと知れば、もっと学びたいという気持ちになるでしょう。

適切なツールを採用した後は、健全な競争によって開発者の意欲を高めるのがよいでしょう。まずは、tournament でトレーニングプログラムを開始してみてください。 

Nelnetが社内にセキュリティ文化を築くためにtournaments を使ってどのように工夫したかをご覧ください。

継続的なセキュリティトレーニングが望ましい企業文化を促進する

トレーニングが退屈なものである必要はありませんし、そうあるべきだと思います。講義には費用がかかり、特に分散したチームでは開催するのが難しく、そこから多くのことを得られる可能性が低いことはわかっています。しかし、企業は開発者にセキュアコーディングのトレーニングを提供し続けており、それは毎年のコンプライアンスのためにボックスをチェックするだけのものです。現状を維持するだけではもはや十分ではありません。今こそ、開発マネージャとAppSecが協力して、継続的で魅力的な学習を促進するトレーニングツールを導入し、ゲームをステップアップする時です。そのためには、まず意思決定者を納得させることから始めなければなりません。

実践的なトレーニングを継続的に行う必要があるのには、さまざまな理由があります。サイバーセキュリティの脅威は常に進化しているため、その脅威に対抗するためのトレーニングも継続的に行われるのは当然のことなのです。それだけでなく、前述したように、リアルタイムに学ぶことで、学んだことをより定着させることができます。セキュリティを考慮したコーディングを行うことは困難です。なぜなら、開発者が約1年前に文脈を無視してスライドショーから学んだことを思い出すことを期待するのは現実的ではないからです。しかし、あるソフトウェアの脆弱性が報告された瞬間に、その脆弱性を回避する方法を学び、同時にゲームをしているような気分になれるとしたら、それは全く新しいゲームになるでしょう。 

実践的で適切なトレーニングが実施されると、セキュリティは企業文化の一部となり、もはや後回しにされることはありません。ソフトウェア開発のライフサイクルの最初から、開発プロセスに組み込まれているのです。 

あなたは何を待っているのでしょうか？組織内のセキュリティを向上させ、企業や顧客の重要なデータを保護するための旅を始めましょう。開発者や上司の協力を得て、組織内の安全なコーディングを次のレベルに引き上げる。最初からセキュリティについて考えることで、何度も同じような脆弱性を経験することはありません。 

もっとリソースが必要ですか？

Complete "Convince your CISO / CTO kit" ダウンロード

10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？

自分で試してみませんか？ 

私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。

パス・トラバーサルの脆弱性について 

この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。

また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。

URLエンコーディング

最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。 

パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。

しかし、それには問題があります。

もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。

cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。

予防と緩和

この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。

2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。

また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。

そのインパクトを体感してください。

何が起こったのか、自分で試してみたいと思いませんか？ 

‍

マイケル・マルティネスは、学生ローンの管理と返済、教育金融サービスを扱う米国のコングロマリット、Nelnetのサイバーセキュリティ・アナリスト兼撮影監督です。彼は、開発者向けのセキュアコーディングに関するトレーニングプログラムの作成を任された際、チームを巻き込むための独創的な方法に取り組みました。私たちは、彼の安全なコードトレーニングプログラムの運営方法に感銘を受け、彼に話を聞きました。 

肝心なところは？ 

セキュリティの文化を作り、開発チームの中から社内のセキュリティ・チャンピオンを育て、"善の力 "となる。 

"安全なコードに注力することで、会社をより強く、より安全にすることができました。" 

Nelnetでは、Michaと彼のセキュリティチームは、最初から安全なコードを構築することの重要性を理解していました。彼らは、魅力的で、関連性があり、やりがいのある方法でこれを達成したいと考えていました。彼は、セキュア・コーディングに強い関心と熟練度を持つ開発者を特定し、彼らをセキュリティ・チャンピオンに育てることで、これらのチャンピオンが、セキュリティ・トレーニング全体の考え方を変えるきっかけになることを発見しました。このような人材は、より多くの支援を必要とする同僚をピア・ツー・ピアで指導し、組織内でセキュアコードの実践に変化をもたらすリーダーとなる。 

ここでは、Micha氏と彼のチームがどのようにしてセキュリティ対策に関する考え方や文化を変え、それによって会社が「より強く、より安全」になったのかについて、Micha氏のコメントを紹介します。

大切なのは、自慢できるかどうか...そして脆弱性を減らすこと

マイケルは、普通のセキュリティトレーニングプログラムを運営しているわけではありません。彼は、競争と彼の映画撮影の才能を利用して、「tournaments 」を非常に魅力的で成功したものにしています。開発者が得られるのは、より強固な安全なコードにつながる、関連性の高い実用的な知識です。 

製品がより安全になり、ソフトウェアの脆弱性に対してより高いレベルの保護を提供できるようになれば、企業にとってもメリットがあります。ソフトウェアセキュリティの学習は、単に項目をチェックするだけの典型的で退屈な学習である必要はありません。開発者が求めているのは、没入感があり、やりがいがあり、日々の仕事に関連したトレーニング体験です。 

Micha氏が、レスリング・マニアのような物理的なチャンピオン・ベルトを賞品として含む、tournaments を通じて、どのようにしてセキュア・コーディング・トレーニングを楽しくするかについて語っています。彼のチームがセキュリティを最重要視するために必要なのは、ちょっとした健全な競争です。 

自慢話をしたくない人はいないでしょう。 

‍

セキュアコーディングを中心とした文化を受け入れる...ツールだけでは不十分

マイケルは、彼がSecure Code Warrior を勧める理由について、最後に考えを述べてくれました。このプラットフォームは、彼が予防的な文化と積極的な学習を生み出すきっかけとなったものです。トレーニングプログラムを構築するのに時間がかかり、また、トレーニングをして成果を上げる開発者に投資するのにも時間がかかりました。安全なコーディングのための予防的アプローチを採用するためのスキルを各開発者に身につけさせるには、変革をもたらす文化が必要です。 

ここでは、安全なコーディングの文化を取り入れることで、なぜSecure Code Warrior が大きく変わるのかについて、Micha 氏が語っています。

Secure Code Warrior は、開発者向けに、没入型で魅力的なセキュアコーディングlearning platform を提供します。デモをご希望ですか？下記よりご予約ください。 

この混沌とした世界では、人々が信頼できるいくつかの定数が常に存在していました。太陽は朝に昇り、夜に沈む。マリオはソニック・ザ・ヘッジホッグよりもかっこいい。インジェクション攻撃は、Open Web Application Security Project（OWASP）が発表した、攻撃者が積極的に利用する最も一般的で危険な脆弱性トップ10の中で、常にトップの座を占めている。

しかし、2021年に更新された悪名高いOWASPリストでは、インジェクション攻撃が1位の座から転落しています。最も古い攻撃の形態の1つであるインジェクション脆弱性は、コンピュータネットワークとほぼ同じくらい古くから存在しています。ブランケット脆弱性は、伝統的なSQLインジェクションからOGNL（Object Graph Navigation Libraries）に対して仕掛けられるエクスプロイトまで、幅広い攻撃の原因となっています。また、OSのコマンドインジェクション技術を利用したサーバへの直接攻撃も含まれます。インジェクション脆弱性は、攻撃者にとって汎用性が高く、また、潜在的に攻撃される可能性のある場所の数も多いため、このカテゴリーは長年にわたって上位にランクインしています。

しかし、射出王は倒れた。王様万歳です。 

これでようやくインジェクションの脆弱性問題が解決したと言えるでしょうか？そんなことはありません。OWASPのリストでは、インジェクションはセキュリティ上の敵の第1位から大きく後退することなく、第3位にとどまっています。しかし、他の脆弱性カテゴリーがインジェクションを上回ったことは、OWASPの新たなトップドッグが実際にどれほど広く普及しているかを示しており、開発者が今後も細心の注意を払う必要があることを意味しています。

しかし、最も興味深いのは、OWASP Top 10 2021が大幅に改訂され、新しいカテゴリーが導入されたことです。安全でない設計」、「ソフトウェアとデータの整合性の障害」、そしてコミュニティの調査結果に基づいた項目です。サーバーサイドリクエストフォージェリ」です。これらは、アーキテクチャ上の脆弱性への注目が高まっていることを示しており、ソフトウェアセキュリティのベンチマークとして、表面上のバグだけではなく、その先を見据えたものとなっています。

壊れたアクセスコントロールが王座に就く（そして、その傾向が明らかになる

OWASPが発表した脆弱性ランキングのトップ10で、5位から1位に躍り出たのが「Broken Access Control」です。インジェクションや、新たに登場した「安全でない設計」などと同様に、「アクセス制御不能」という脆弱性には、さまざまなコーディング上の欠陥が含まれており、それらが複合的に被害をもたらすため、疑わしい人気となっています。このカテゴリーには、アクセス制御ポリシーに違反することで、ユーザーが意図した権限の範囲外で行動できる場合が含まれます。 

OWASP がこの脆弱性群をトップレベルに引き上げた理由として挙げている「アクセス制御の破壊」の例には、攻撃者が URL、アプリケーションの内部状態、あるいは HTML ページの一部を変更できるものがあります。また、ユーザーがプライマリアクセスキーを変更することで、アプリケーション、サイト、またはAPIが、より高い権限を持つ管理者など、別の人物であると思い込ませることができるかもしれません。さらに、攻撃者がメタデータの変更を制限されず、JSONウェブトークン、クッキー、アクセスコントロールトークンなどを変更できるような脆弱性も含まれています。

この脆弱性が悪用されると、攻撃者はファイルやオブジェクトの認証を回避してデータを盗んだり、データベースの削除など管理者レベルの破壊的な機能を実行したりすることが可能になります。このように、アクセス・コントロールの破壊は、ますます一般的になっているだけでなく、決定的に危険なものです。

認証とアクセス制御の脆弱性が、攻撃者にとって最も攻撃しやすい環境になっていることは、非常に説得力があり、かつ驚くべきことではありません。ベライゾン社が発表した最新の「Data Breach Investigations Report」によると、アクセスコントロールの問題は、ほとんどすべての業界、特にITとヘルスケアの分野で広く見られ、全侵害のうち85％が人的要素を含んでいることが明らかになっています。人的要素」には、エンジニアリングの問題ではないフィッシング攻撃なども含まれていますが、報告書によると、侵入の3％には悪用可能な脆弱性が含まれており、古い脆弱性や、セキュリティの設定ミスなどの人的ミスが主な原因となっていました。

XSSやSQLインジェクションのような老朽化したセキュリティバグが開発者を悩ませている一方で、最近では、中核的なセキュリティ設計が失敗していることが明らかになってきており、アーキテクチャ上の脆弱性が生じています。 

しかし問題は、基本的な知識以上のトレーニングやスキル開発を受けているエンジニアが少なく、また、開発者が最初に引き起こしたコードレベルの局所的なバグを超えて、本当に知識や実用性を高めているエンジニアも少ないということです。

ロボットがほとんど見つけられないバグの防止

新たにグループ化されたアクセスコントロールの破壊された脆弱性のファミリーはかなり多様です。アクセスコントロールの破壊の具体的な例と、それを阻止する方法については、弊社のYouTubeチャンネルとブログで紹介しています。

しかし、この新しいOWASPトップ10を称賛することは重要だと思います。実際、このトップ10はより多様で、スキャナでは必ずしも拾えないものを含む、より幅広い攻撃ベクトルを網羅しています。コードレベルの弱点が発見されるたびに、より複雑なアーキテクチャ上の欠陥が発見されますが、自動化されたシールドや武器がどれだけあったとしても、セキュリティ技術スタックのほとんどは気づかないでしょう。OWASPのトップ10リストの大部分は、依然としてスキャンデータに基づいて作成されていますが、安全でない設計やデータの整合性の失敗などをカバーする新しいエントリは、ロボットができないことを実現するためには、開発者のトレーニングの幅を急速に広げる必要があることを示しています。

しかし、セキュリティに精通した開発者のチームは、ベストプラクティスやビジネスのニーズに沿ってセキュリティIQを向上させることで、AppSecチームに計り知れないほどの貢献をすることができます。OWASP トップ 10 は優れたベースラインではありますが、脅威の状況は非常に速いペースで変化しているため（社内の開発目標の要求は言うまでもありません）、セキュリティに関する開発者のスキルアップをより深く、より具体的に行うための計画が必要であることを理解した上で、これを優れたセキュリティ・プログラムに織り込む必要があります。これを怠ると、必然的に早期修正の機会を逸することになり、予防的かつ人間主導のサイバーセキュリティへの全体的なアプローチを成功させる妨げとなります。

‍

OWASP Top 10 2021に対応していますが、これはほんの始まりに過ぎません。開発者には 高度なセキュリティ・スキル・パスウェイを今すぐ。

サイバー脅威の状況は、日に日に複雑化しています。攻撃者は常にネットワークをスキャンし、脆弱なアプリケーションやプログラム、クラウドのインスタンスを探していますが、最近の標的は、セキュリティ管理が甘いことが多いため、簡単に獲得できると考えられているAPIです。攻撃者は非常に執拗で、新しいアプリケーションが導入されてから数時間で侵害され、悪用されることもあります。Verizon 2021 Data Breach Investigations Report」によると、企業や組織を狙う脅威は、過去のどの時点よりも危険な状態にあることが明らかになっています。

作成されるソフトウェアを真に強固なものにする唯一の方法は、安全なコードに基づいて構築されていることを確認することであるということがはっきりしてきました。言い換えれば、脅威となる人物の侵入を阻止する最善の方法は、そもそもアプリケーションへの足掛かりを与えないことです。いったん戦いが始まれば、ほとんどの利点は攻撃者側に偏ります。

このような状況から、まずアジャイル開発とDevOpsが生まれ、その後、DevSecOpsの動き全体が生まれました。セキュリティは、開発からデプロイまでのソフトウェア作成プロセスに関わるすべての人が共有する責任です。しかし、このピラミッドの底辺であり、間違いなく最も重要な部分を占めるのは開発者です。ほとんどの開発者は、自分の役割を果たし、安全なコードを書きたいと思っていますが、彼らが働く組織の多くは、優先順位の大幅な変更を必要とする変化をあまり支持していません。

デザインによる敗北

長い間、開発者の主な役割は、ビジネスが止まることなく、お客様も眠らないような、目まぐるしい環境の中で、アプリケーションを素早く構築し、デプロイすることだと言われてきました。開発者は、より速くコーディングし、より多くの機能をデプロイできればできるほど、業績評価の面で価値があるとみなされていました。

セキュリティは後回しにされ、まったく考慮されていませんでした。その代わり、これらのことはすべてアプリケーションセキュリティ（AppSec）チームに任せられていました。AppSecチームは、完成したアプリケーションにセキュリティパッチを適用したり、脆弱性を修正するためにコードを書き換えたりするために、しばしば開発に戻されるので、多くの開発者に嫌われていました。また、開発者がすでに「完成」しているアプリの作業に1時間を費やすことは、新しいアプリや機能を作らない時間となり、パフォーマンス（そして、特に懲罰的な企業の目にはその価値）を低下させることになります。

そして、脅威の環境が、ほとんどの企業にとってのセキュリティの重要性と優先順位を変えてしまったのです。IBMとPonemon Instituteが最近発表した「Cost of a Data Breach Report」によると、現在、サイバーセキュリティ侵害の平均的なコストは、1件あたり約380万ドル（約3億円）ですが、これは上限値ではありません。ある企業では、自社のネットワークが侵害されたことにより、13億ドルの損害が発生しました。今日の企業は、DevSecOpsが提供するセキュリティを求めていますが、悲しいことに、その声に応えた開発者への報奨は遅れています。

開発チームにセキュリティを考慮するように言うだけではうまくいきません。特に、スピードだけでインセンティブを得ている場合はなおさらです。実際、このようなシステムでは、セキュリティについて学び、コードを保護するために時間をかけている開発者は、セキュリティ意識の低い同僚が獲得し続けている業績評価や高額なボーナスを実際には失っている可能性があります。これは、企業が知らず知らずのうちに自分たちのセキュリティの失敗のためにシステムを操作しているようなもので、開発チームに対する企業の認識に起因しています。開発チームをセキュリティの最前線として見ていないのであれば、彼らの労働力を活用するための実行可能な計画が実現する可能性は極めて低いでしょう。

これは、トレーニングの不足も考慮していません。非常に熟練した開発者の中には、何十年にもわたってコーディングの経験を積んでいる人もいますが、セキュリティに関してはほとんど何もしていません。企業が熟練したプログラマーに優れたトレーニングプログラムを提供していない限り、開発者が突然新しいスキルを身につけ、それを積極的に脆弱性を減らす意味のある方法で実行することは期待できません。

優れたセキュリティ対策を施した開発者への報酬

良いニュースは、圧倒的に多くの開発者が、仕事にやりがいを感じ、自分の立場が尊重されることを楽しみにして仕事をしているということです。生涯現役のプロのコーダーであるMichael Shpiltは最近、彼と彼の同僚が開発の仕事をする上でモチベーションとなるものをすべて書いている。その中には、金銭的な報酬も含まれていますが、それは意外と低い位置にあります。それよりも、新しいものを生み出すスリル、新しいスキルの習得、自分の仕事が直接人の役に立つという満足感を優先しています。また、会社やコミュニティの中で評価されていると感じたいとも語っています。要するに、開発者は自分の仕事に誇りを持っている多くの善良な人々と同じなのです。

Shpilt氏をはじめとする開発者は、脅威となる人物が自分のコードを危険にさらし、それを利用して自分の会社や、助けようとしているユーザーに危害を加えることを望んでいません。しかし、サポートなしにいきなりセキュリティを優先させることはできません。そうでなければ、システムが彼らに不利に働くようなものだからです。

開発チームがサイバーセキュリティの能力を向上させるためには、まず必要なスキルを教える必要があります。足場付き学習やJiT（Just-in-Time）トレーニングのようなツールを活用することで、このプロセスの苦痛を軽減し、適切な状況下で既存の知識を積み重ねることができます。 

例えば、JiTの開発者トレーニングツールは、プログラマーが安全でないコードを作成していることや、アプリケーションに誤って脆弱性を持ち込んでいることを検知すると、その問題を修正する方法や、将来同じ機能を実行するために、より安全なコードを書く方法を開発者に示すことができます。

スキルアップへの取り組みが行われていれば、スピードだけで開発者を評価するような古い方法は排除する必要がある。代わりに、開発者は安全なコードを作成する能力に基づいて報酬を受けるべきであり、優秀な開発者はチームの他のメンバーのスキル向上を支援するセキュリティ・チャンピオンとなるべきである。そして、そのチャンピオンには、会社の名声と金銭的な報酬の両方で報いる必要があります。また、開発者は一般的にセキュリティに関してポジティブな経験を持っていないことを忘れてはならない。ポジティブで楽しい学習や、開発者の興味を引くようなインセンティブによって開発者の気持ちを高揚させることは、知識の定着とスキルを向上させ続ける意欲の両方を確保するのに非常に有効である。

企業は、コーディングスピードを開発者の評価の一部に含めることができますが、特にコーダーが新しいスキルを習得している間は、安全なアプリケーションの開発に多少時間がかかることを想定しています。

DevSecOpsは、ますます危険になっていく脅威の世界のダークアートに対する究極の防御となり得ます。ただ、この新しい世界の覇者である、常に新しいコードを生み出している開発者は、その仕事に敬意を払い、報酬を得る必要があることを忘れてはいけません。

世界中の開発者を相手に、あなたのセキュリティスキルを試してみませんか？チェックアウト Secure Code Warrior’s デブリンピック2021をチェックしてみてください。私たちのグローバルなtournaments で大きな賞を獲得できるかもしれません !