この記事のバージョンは、以下のサイトに掲載されています。 DZone.この記事は更新され、ここにシンジケートされています。

‍

この時点で永遠とも思えるほど、私たちは、ソフトウェア開発の最初からセキュリティのベストプラクティスを考慮する、SDLCにおける「左遷」について議論してきました。DevSecOpsは、セキュリティに対する責任の共有と、セキュリティを意識した開発者がコードを書きながら一般的な脆弱性を阻止する力を強調したため、少なからず大きな飛躍を遂げました。 

また、開発者の参加とスキルアップのために選択するセキュアコードトレーニングの種類によって、大きな違いが生じることも、やはり何年も前からわかっています。規制遵守だけを動機とする労力の少ないソリューションでは、将来の優秀なセキュリティ人材を育成することはできませんし、ほとんどのセキュリティ意識の専門家はそのことに気付いています。動的で文脈に応じた学習が最適ですが、そのニュアンスを理解することが非常に重要です。 

脅威と戦うチャンスを得ようとするならば（脅威は常に組織に対して優位に立つ）、開発者には、ベストプラクティスに基づいたスキルを継続的に構築する階層的な学習による、総合的なトレーニング環境が必要なのです。

開発者主導の防御的なセキュリティ対策は、自動的には勝てない。

私たちの理念は、予防的なセキュリティ戦略の中心をなすのは開発者であり、コードレベル以上であることを中心に展開されています。これは当然のことで、セキュリティに精通した開発者は、お粗末なコーディングパターンに見られる一般的なセキュリティバグを阻止する最も簡単な方法を提供します（最近の破壊的な例としてLog4Shell のようなもの）。

しかし、開発者のスキルアップのために取り組むことのできる防御技術は、たとえ同じトレーニングバケットに正しく存在するとしても、さまざまです。 

例えば、ケーキを焼くときに、「こうしてはいけない」という指示だけで焼くとしたらどうでしょう。焼きすぎるな」「卵を忘れるな」では、解釈の余地があり、失敗の可能性が高く、最終的には「Nailed It! 失敗した!.同じことが、防御的なセキュリティ教育にも当てはまります。「してはいけないこと」は、会話のごく限られた部分であり、防御的な考え方で本当に行動するための実践的なアドバイスを提供するものではありません。

開発者は、脆弱性がどのように機能するか、なぜ危険か、どのようなパターンが脆弱性を引き起こすか、どのような設計やコーディングパターンが脆弱性を修正するかについて、彼らの世界で意味のある文脈で基礎的な理解がなければ、脆弱性削減にプラスの影響を与えることはありません。足場となるアプローチは、安全なコーディング、コードベースの防御、および、セキュリティを意識した開発者としての立場の意味を全体的に把握するために、知識の層を重ねることを可能にします。これは、脅威のモデル化と防御戦略において非常に重要な、水平思考スキルを磨くために重要です。 

コーディングの悪いパターンを強化してしまうことは、無視できない落とし穴です。

開発者の学習方法の中には、技術的にはコードの安全性を検証していても、「守り」の部分、つまり攻めの技術で構成されたトレーニングでは、悪い習慣を強化してしまうという残念な現実があります。 

高品質なコードを作成することは、すべてのソフトウェア開発における基本であるべきですが、「品質」の定義にはまだ議論があるようです。現実には、安全でないコードは、たとえそれが機能的で美しくても、高品質のコードと見なすことはできません。また、セキュア なコードが本質的に高品質であるわけでもないというのがキッカケです。言い換えれば、不適切なコーディングパターンは、セキュリティの問題を修正することができますが、その際に別の問題を引き起こしたり、ソフトウェアを完全に破壊してしまう可能性があります。 

壊れた認証の修正という形で質の悪いコードの例と、ベストプラクティスのための最も安全なバージョンを見てみましょう。

‍

を使用しています。

System.Collections.Genericを使用しています。

System.Linqを使用しています。

System.Threading.Tasksを使用しています。

Microsoft.AspNetCore.Authorizationを使用しています。

Microsoft.AspNetCore.Http.Libraryを使用しています。

Microsoft.AspNetCore.Mvcを使用しています。

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]を使用します。

    [ApiController】です。］

    public class AlertsController : ControllerBase.

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")】を参照してください。］

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            context.GetAlerts()を返します。

        }

‍

        [HttpGet(Name = "GetAlerts")】を参照してください。］

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]を使用します。

        public IEnumerable<Alert> GetBadFix()

        {

            context.GetAlerts()を返します。

        }

‍

        [HttpGet(Name = "GetAlerts")】を参照してください。］

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]。

        public IEnumerable<Alert> GetGoodFix()

        {

            context.GetAlerts()を返します。

        }

    }

}

‍

最初の例では、ユーザが認証されているかどうかを確認するチェックがありません。2番目は、認証チェックを行う点では優れていますが、割り当てられたロールと、要求された情報に対して十分な権限があるかどうかを調査することに失敗しています。3つ目は、ユーザーの認証と、そのユーザーが「Administrator」ロールを割り当てられているかどうかの両方をチェックします。最小権限のアクセス制御がほとんどの場合において標準であるべき時代において、情報を知る必要がある場合にのみアクセスできるように役割を設定し、確認することは非常に重要です。 

開発者にとっての最優先事項は機能を構築することであり、セキュリティが意図的に後回しにされているわけではありませんが、セキュリティバグにつながるお粗末なコーディングパターンを回避するスキルを必ずしも持っていませんし、優れたエンジニアのベンチマークにセキュリティコーディングの腕前が含まれることはほとんどありません。私たちは、機能が十分に素晴らしいものであれば、そのような悪い習慣を間接的に奨励しており、この考え方こそ変えなければなりません。問題は、いくつかの学習経路が実践的なコード修正を推奨しているため、安全ではあるが標準以下の品質のコードが強化される可能性があることです。これは安全だ／これは安全ではない」という二元的な判断でassessment 、バグを解決しソフトウェアの完全性を維持するために本当に最善の方法かどうかを深く検討しないため、細部にまで気がつかない悪魔が潜んでいるのです。 

セキュアコーディングの全プロセスを開発者に見せることなく、このアプローチは、解決しようとする同じ問題を永続させることになります。赤信号を無視して、生け垣の間を通り抜け、横断歩道を渡る歩行者をぎりぎりで見落としても、合格となります。赤信号を無視して、生け垣をすり抜け、横断歩道を渡る歩行者をギリギリで見落として、目的地に到着したのです。目標は達成しましたが、そこに至るまでの道のりが最も重要です。 

開発者は、安全なソフトウェアを作ることにもっと関心を持つようになる必要があります。

現代の開発者は多くの業務をこなさなければならないため、セキュリティトレーニングを退屈に感じるのは当然です。特に、平日の業務を考慮して実施されておらず、締切や優先事項から遠ざかっている場合はそうです。また、定期的で適切な学習機会や補助的なツールで培ったスキルがないのに、セキュアコーディングに重点を置くようにKPIを変更するのは完全に不当です。しかし、セキュアなソフトウェア開発の重要性はいくら強調してもし過ぎることはありませんし、開発者をセキュアコーディングの側に置くことは非常に重要です。 

元開発者である私たちは、一般に、優れた仕事をしたいと思う ものであり、アウトプットの品質という点で他の人より優れていると見なされることは、非常にモチベーションの高いことです。開発者に継続的なセキュリティスキル向上のインセンティブを与えることは当然のことであり、コードレベルのセキュリティの重要性を認識した開発者には報酬を与えるべきである。セキュリティチャンピオンプログラム、バグ報奨金、ハッカソンなどは、積極的なセキュリティ文化を構築する絶好の機会であり、腕まくりして参加した者は戦利品を手に入れるべきである。

この記事のバージョンは、SD Timesに掲載されました。 SDタイムズ.この記事は更新され、ここにシンジケートされています。

‍

私たちが進歩について語るとき、一般的にはデジタルの進歩が最重要視されます。私たちは、あらゆるものをより良く、より速く、より便利に、よりパワフルに、そして、より少ない費用、時間、リスクで実現したいと考えています。しかし、毎日、コードが世界を変えているのです。 

しかし、ソフトウェアの大きな広がりには大きな責任が伴い、現実には、セキュリティの観点からそれに対処する準備が整っていないのが現状です。クラウド、家電や自動車の組み込みシステム、重要なインフラ、そしてもちろんそれらをつなぐAPIなど、ソフトウェアがもたらすリスクのあらゆる側面を考慮すると、攻撃対象はボーダーレスで制御不能なものとなっています。 

しかし、業界として、コードレベルのセキュリティに対してより全体的なアプローチを採用することは可能です。

ここでは、手元にあるツールを使って、この無限に広がる攻撃対象領域をどのようにコントロールするかを考えてみましょう。

ビジネスリスクのレベルについて現実的に考える（そして、何を受け入れるか）。

完璧なセキュリティは持続可能ではありませんが、目隠しをしてすべてが青空であるかのように装うこともできません。私たちは、組織が脆弱なコードを承知の上で出荷していることをすでに知っています。そして、明らかに、これは新機能や新製品の市場投入までの時間に基づいて計算されたリスクなのです。 

特にDevSecOpsが標準的な開発手法でないところでは、スピードのあるセキュリティは難しいものです。しかし、最近のLog4Shellエクスプロイトを見るだけで、コードの中の比較的小さなセキュリティ問題が、いかに攻撃の成功の機会を広げているかを発見し、低品質のコードを出荷するために計算されたリスクの結果が、予測よりもはるかに大きくなり得ることを知ることができる。

アクセス）コントロールフリークになることに慣れよう

クラウドストレージの設定不備によるデータ漏えいの被害は驚くほど多く、アクセス制御の誤りによる機密データ流出の可能性は、ほとんどの組織のセキュリティチームを悩ませ続けています。 

2019年、フォーチュン500社のFirst American Financial Corp.は、このことを身をもって知りました。認証ミス、つまり比較的簡単に修正できるものでしたが、銀行明細書、住宅ローン契約書、写真付き身分証明書など、8億件を超える記録が流出する事態となりました。これらの文書へのリンクは、ユーザー識別やログインを必要としないため、ウェブブラウザさえあれば誰でもアクセス可能な状態になっていました。さらに悪いことに、これらの文書には連番で記録されていたため、リンク先の番号が変わるだけで、新しいデータレコードが公開されることになりました。 

このセキュリティ問題は、メディアで取り上げられる前に社内で確認されていましたが、高リスクのセキュリティ問題として適切に分類されず、経営陣に報告して緊急に改善させることができなかったため、現在もその影響は続いています。

開発者は、認証と権限に関するベストプラクティスを自分のビルドで実行し、機密データの公開を保護するためのチェックと対策を確実に行うために、検証されたセキュリティ意識と実践的なスキルを必要としています。 

APIは、設計上、他のアプリケーションと非常におしゃべりであり、開発チームはすべての潜在的なアクセスポイントを可視化する必要があります。結局のところ、より安全なソフトウェアを提供するための探求において、未知の変数やユースケースを考慮することはできないのです。

セキュリティ・プログラムの分析：予防にどの程度重点を置いているか？

セキュリティ・プログラムの大部分をインシデント対応とその対応に割くことは理にかなっていますが、多くの組織では、セキュリティ・インシデントを未然に防ぐために利用できるすべてのリソースを活用しないことで、貴重なリスク最小化を見逃しています。

確かに、問題のあるバグの発見を支援する包括的なセキュリティツールのスタックはありますが、ほぼ50％の企業が、脆弱性があるとわかっているコードを出荷していることを認めています。しかし、クラウド、アプリケーション、API機能、組み込みシステム、ライブラリ、そして、広がり続けるテクノロジーの中で、コードを保護する必要があるという事実は、現在のアプローチでは常に一歩遅れていることを保証しています。

セキュリティバグは人間が引き起こした問題であり、ロボットにすべての修正を期待することはできません。もし、あなたの開発チームが効果的にスキルアップされていないのであれば、単に年に一度のセミナーではなく、適切な教育の積み重ねが必要であり、低品質のコードを標準として受け入れ、それに付随するセキュリティリスクを常に抱えていることになります。 

開発者の即戦力を過大評価していませんか？

開発者は、セキュアコーディングの能力について評価されることはほとんどなく、それは彼らの優先事項ではありません（多くの場合、KPIでもありません）。もし、より良い方法を示されないなら、あるいは、それが自分の成功の尺度であると言われないなら、彼らは、お粗末なセキュリティ慣行の犠牲になることはできない。 

しかし、組織内では、提供されたガイダンスが、一般的なセキュリティリスクを軽減するための準備として有効であると想定されていることがあまりに多いのです。セキュリティのベストプラクティスを適用するためのトレーニングやその意識によっては、エンジニアは、望ましい最初の防御線となる準備ができていないかもしれません（そして、ペンテスト報告書を詰まらせる無限のインジェクション欠陥を阻止する準備ができていないかもしれません）。 

理想的な状態は、複雑さを増す学習経路を完了し、その結果得られるスキルが、実世界で開発者のために実際に機能することを確認することです。しかし、そのためには、開発者のことを最初から考え、正しく使えるようにする文化的基準が必要です。もし私たちが業界として、自分たちで作り上げたこの広大なコードの風景を守るために荒野に出るのであれば、得られるすべての助けが必要です...そしてそれは、私たちが思っている以上に、目の前にあるのです。

Secure Code Warrior 株式会社オクタと共同で、開発者のワークフローを保護するための新たな方法を発表

開発者は、これまで以上に質の高いコードを迅速に提供することが求められていますが、非現実的な納期がソフトウェア品質の低下や脆弱なコードの発生につながることは間違いないでしょう。67%の開発者が、厳しい納期のせいもあって、脆弱性のあるコードを出荷していると考えていることは、驚くには値しません（State of Developer-Driven Security 2022）。脅威と侵害が増え続ける中、セキュリティはもはや後回しにすることはできず、DevSecOpsサイクル全体に統合する必要があります。

組織と開発者がソフトウェア開発ライフサイクルの最初から安全なコードを書くことができるようにする、Secure Code Warrior Connector for Okta Workflowsを発表できることを嬉しく思います。SCWと、アイデンティティの独立系大手プロバイダであるOktaのこの新しいコラボレーションは、開発者をワークフローから移動させずに、チームが脆弱性を減らすために安全なコードをコミットしていると確信できるよう、AppSec管理者を強化するセキュリティ能力チェックを作成します。さらに、Secure Code Warrior と Okta のシングルサインオンを追加し、この素晴らしい新しいソリューションの活用をよりシンプルにしました。

脆弱性導入のリスクを低減する

開発チームは従来、セキュリティ上の問題を発見し修正するために、プラグイン、スキャンツール、コードレビューなど、開発サイクルの後半にある反応的または低速なプロセスに依存してきました。これらのアプローチには多くの利点がありますが、脆弱なコードや将来の手戻りに対するリスクが高すぎるだけです。私たちは、組織がセキュリティを左側にシフトし、後手に回るのではなく、先手を打つセキュリティスタンスをとることを支援します。新しいSecure Code Warrior Connector for Okta Workflows は、個々の開発者がコードをコミットするためのリポジトリアクセスを許可されるために必要なセキュアコーディングスキルを達成していることを確認することによって、セキュリティの考え方を開発サイクル全体に統合しています。この統合により、開発者はSCWの非常に魅力的なプラットフォームを通じて最新のセキュリティプラクティスを学ぶことができ、手動コードレビューの負担が軽減されるため、品質を犠牲にすることなく、より多くの機能を出荷するためにエンジニアリング時間を確保することができます。

AppSec とエンジニアリングリーダーは、SCW の広範なlearning platform を活用して、パーソナライズされた評価とパスを作成し、開発者が最優先の安全なコーディングニーズに集中し、正しい専門知識を獲得して、自信を持ってコードをチェックインできるようにします。コンテンツの幅と深さ、6500以上のインタラクティブなコーディングチャレンジ、56以上の言語：フレームワーク、150以上の脆弱性カテゴリを活用することで、あなたの組織のほぼすべてのニーズを満たすことができることを確認することができます。

チームのために適切な学習戦略を作成したら、assessment のスコアとコースの完了状況を使用して、開発者がセキュリティ優先のアプローチでソフトウェアを構築するための適切なスキルを持っているかどうかを判断することができるようになりました。Oktaとの新しい統合により、assessment のスコアに基づいて各開発者の権限を自動化し、コードのコミットに対する個々の開発者の承認を容易に拡大したり、スキルセットをさらに向上させる機会を特定したりすることができるようになりました。

SCWプラットフォームでの柔軟でインタラクティブな学習体験のおかげで、開発者は常に楽しみながら学習することができ、コンプライアンスのチェックボックスから説得力のある価値あるものへと、学習への取り組みが変化していることを実感しています。

その仕組み

Okta Workflows用Secure Code Warrior Connectorは、if-thenロジックを使用して、Okta WorkflowsのコードなしID自動化およびオーケストレーション設定を簡単に構築することができます。Connectorは、APIコールや構成設定の複雑さを気にすることなく、ワークフロータスクを実行できるよう、一連のActionを使用します。

開発者のワークフローを確保するためのシンプルな設計は、次のようなものです。

ここでは、ワークフローの全体設計の概要を説明します。

‍

それでは、順を追って説明します。

1.開発者のセキュリティ熟練度を判断するために使用されるassessment ID を設定します。また、設定の一環として、組織やリポジトリなどのGitHubの詳細を追加します。

2.CheckAssessment Completion For User というアクションを使用して、ワークフローは開発者が特定のassessment を正常に通過したかどうかをチェックします。

‍

3.希望するコース/assessment を完了した場合、または特定のスコアを達成した場合、GitHub Connector を使用してリポジトリへのアクセスを許可する。要件を満たしていない場合は、通知を生成するか、別のOktaワークフローをトリガーして適切なアクションを取ることができます。

‍

上記のチェックは、1回限り、定期的、または継続的に実行されるように設計することができ、適格な開発者のみを安全なワークフローに導き続けることができます。

SCW Connector Actionの他の可能なものは以下の通りです。

• ListAssessment Attempts For User - 特定のユーザーに対するすべての試行回数をリストアップします。assessment
• Check Course Completion For User - ユーザーが指定したコースを修了しているかどうかを判定します。
• List Course Enrollments For User - 特定のコースIDに対して、ユーザが持っているすべての登録情報をリストアップします。
• カスタムAPIアクション - 利用可能なActionで可能なもの以外のAPIコールを実行します。

高品質で安全なコードを自信を持ってより早くリリース

SCW Connectorは、ソフトウェア開発ライフサイクルの開始時に脆弱性が混入するリスクの低減を支援します。コードレビューやスキャンツールと同様に、開発者が最初から安全なコードを書いていることを確認するための品質ゲートとしての役割を果たします。その結果、コードのレビューや回避可能な問題の修正に費やす時間が減り、高品質のコードをより早く出荷することに重点が置かれるようになります。さらに、Connector は、開発者がセキュリティ能力を維持するために SCW のlearning platform に積極的に関与することを奨励することで、セキュリティ優先の文化を促進することにも役立っています。開発者が学習し、セキュリティ成熟度を向上させ続けることで、新しいコードに含まれる脆弱性が減少し続けるのです。これにより、アプリケーションセキュリティチームの修正サポートの負担が軽減され、組織全体のセキュリティ態勢の強化により注力することができます。

Secure Code Warrior Connector for Okta Workflowsと一緒に、私たちの learning platform開発チームのセキュリティ能力を向上させることで、セキュリティの左遷という目標をより早く達成することができるのです。

デモのご予約はこちらから、セットアップや設定の詳細については、ドキュメントをご覧ください。

‍

Secure Code Warrior 、私たちは常に革新を続け、顧客体験を向上させ、プラットフォームを通じて付加価値を提供しています。

今月は、Courses 管理者エクスペリエンスの新しいアップデート、待ち時間の少ない新機能への早期アクセス機能、SAP:ABAP コンテンツなどをリリースしました。

言語や脆弱性カテゴリにまたがる一括アクションを実行できる強力な表形式表示により、管理者はより簡単にCourses を管理できるようになり、エンドユーザーエクスペリエンスも向上しました。さらに、シンプルなオン・オフの切り替えで、新機能にいち早くアクセスできるようになりました。

もっと知りたい！という方は、飛び込んでみましょう。

新しいCourses 作成エクスペリエンスにより、courses をより簡単に作成・管理できます。

一括アクションにより、複数の学習経路や言語にわたってCourses を簡単に設計・展開できるようになりました。プロセスを再現するために時間をかける代わりに、開発者がより効果的に学習できるように、コンテンツと戦略にもっと焦点を当てることができます。

現在、Courses 作成フローの更新は、企業の管理者が利用できるようになっています。

パワフルな表形式表示と検索エクスペリエンスで、Courses の設計時間を短縮

すべての言語と脆弱性カテゴリにまたがるコース情報に1つのビューでアクセスできるようになり、異なる開発チーム向けにcourses を迅速に作成することが容易になりました。

新しい表形式の表示により、コンテンツの概要を一目で確認したり、詳細を掘り下げたりすることが容易になりました。また、コースコンテンツは言語や脆弱性のカテゴリーごとにグループ化され、各グループレベルでアクティビティの種類や難易度などの詳細が追加されているため、ナビゲーションが容易になりました。

また、検索機能やフィルターを適用することで、注目したい内容を絞り込むこともできます。さらに、表データは他のアプリケーションにエクスポートしたり、全行またはフィルタリングした行をCSVファイルにエクスポートしてさらに分析することができます。

‍

バルクアクションにより、少ないクリック数でより多くの操作を実現

すべての言語にわたって変更を適用するのではなく、一箇所からコースに一括して変更を加えることができます。一括変更により、管理者は時間を節約し、開発者のための適切なコース体験の設計という重要なことに集中することができます。

新しいバルクアクションは以下の通りです。

• OWASP Top 10や特定の脆弱性カテゴリなど、全言語を対象としたコースフォーカスの追加
• コースに言語を追加し、コンテンツを迅速に更新
• 選択した、またはすべての行のモジュールのコピー、ロック、ロック解除
• コースから言語やモジュールを削除する
• 歓迎とコース終了のメッセージを全言語で一括設定

‍

End-of-courseassessment pathways

各言語のコース終了時のassessment をカスタマイズし、一つのビューで管理できるようになりました。

言語やコースの種類に応じてカスタマイズされたassessment パスウェイを簡単に作成し、コース修了時にスキルを測定・評価することができます。

新機能への早期アクセス

‍

これまでは、新機能を知り、一般公開前に試したい場合は、カスタマーサクセスマネージャーに相談し、私たちのチームがお客様のために機能をオンにするのを待つ必要がありました。

いつ、どの機能をチームのためにオンにするかは、管理タブでトグルするだけで、コントロールできるようになりました。もう待ち時間は必要ありません。

次のURLからアクセスできます。 管理部門> もっと見る > アーリーアクセスをクリックしてお試しください。

この機能は、より多くの機能、特にユーザーエクスペリエンスに大きな変化をもたらすものに活用され、ユーザーエクスペリエンスをよりよくコントロールできるようにします。

早期アクセスにはどのような機能があるのでしょうか？現在のオプションの一部をご覧ください。

> より統一感のあるトップページ表示への改良

>Courses を更新しました。

1. プレビューステータスモード
2. コースコンテンツへの一括アクション
3. グローバルウェルカムメッセージ
4. コース終了時のアクティビティ改善

現在、アーリーアクセスのオプションは、企業の管理者が使用することができます。

新しくリリースされたトレーニングコンテンツでABAPアプリケーションを安全に

ABAPでコーディングする開発者が、非常に魅力的で適切なセキュアコーディングトレーニングに参加することができるようになりました!この新しいトレーニングは、開発者のセキュアコーディングスキルを向上させ、ABAPコードの脆弱性を低減させるのに役立ちます。

Secure Code Warrior コーディングチャレンジとMissions （ハンズオンラボ）で、カバーするプログラムを提供することができます。

1. 開発者が必要な時に楽しめるセルフペーストレーニング
2. コンプライアンス、セキュリティフレームワーク、開発者 のスキルレベルに合わせて、的を絞った学習パ スウェイを設定することができる
3. 楽しいコーディングコンテスト
4. セキュア・コーディング・コンピテンシー・アセスメント

ABAPトレーニングの内容については、こちらをご覧ください。

------

Secure Code Warrior を試してみたいけれど、まだアカウントを持っていない？今すぐ無料トライアルアカウントにサインアップして始めましょう。

今月の新機能の紹介はこれで終わりですTwitterでSecure Code Warrior をフォローすると、最新のリリースや改善に関する最新情報を入手できます。

本日、SAP:ABAP のトレーニングコンテンツがSecure Code Warrior で利用できるようになったことをお知らせします !ABAP開発チームが、より迅速に、より少ない手直しで、より少ない脆弱性で高品質のコードを出荷するために必要なサポートを確実に得ることができます。

• 自習型トレーニング
• ターゲットを絞った学習経路
• 楽しいコーディングコンテスト
• セキュア・コーディング・コンピテンシー・アセスメント
• セキュアコーディングスキルの長所と短所をパーソナライズしたレポート

ABAP (Aアドバンスト Bビジネス Aアプリケーション Pプログラミング）は、19,000 社を超える企業が SAP プラットフォーム上でビジネスアプリをコーディングするための主要言語です。これらの企業は、世界全体の商取引の最大87%（46兆ドル）を生み出しています。そのため、ABAPのセキュリティ確保はこれまで以上に重要です。

Secure Code Warrior では、ABAP のようなニッチな言語で書かれたものから Java のような一般的なものまで、あらゆるビジネスクリティカルなアプリケーションのセキュリティを確保できるよう、開発者に働きかけています。

‍

‍

既存のお客様は、Training,Courses, およびTournaments のコンテンツにアクセスできるようになりました。ご不明な点がございましたら、カスタマーサクセスマネージャーまでお気軽にお問い合わせください🙂。

Secure Code Warrior は、ビジネスクリティカルなABAPアプリケーションのセキュリティをどのように支援するのでしょうか。

ABAPはニッチな言語であるため、トレーニングプラットフォームに含まれることはほとんどありません。そのため、企業が開発者を育成しようとする場合、単発のワークショップのような過度に高価で非効率的なプログラムによって行われます。

Secure Code Warrior, 継続的かつ効果的なトレーニングソリューションが得られます。

当社のトレーニングコンテンツは、開発者が好む形式、つまりコードスニペットやサンプルで提供されます。そのため、開発者がコンテンツを利用し、楽しむことができると確信することができます。

さらに、ABAP開発者は、当社のコンテンツの深さと広さ、および段階的な学習システムにより、セキュアコーディングスキルを段階的に向上させるために必要な継続的なサポートを受けることができます。このような段階的な学習により、開発者は筋肉記憶を形成し、学習したことをプロジェクトで実践することができます。

‍

コーディングチャレンジを通じて、脆弱性の特定とセキュアなコードパターンを学ぶ

‍

私たちは、開発者が使い慣れた環境の中で最もよく働くことを知っています。そのため、私たちはコードエディターのようなインターフェイスで、コーディングの課題を提示します。

開発者は、ファイルやコードラインをナビゲートして、機能しているコードベースのABAPの脆弱性を探し出し、特定し、修正することができます。トレーニングの間、開発者は脆弱性のあるコードパターンと正しい修正方法を認識することを学び、その結果、脆弱性の早期発見と迅速な修正につなげることができます。

ABAPは、私たちが提供する言語の中で最も新しいものです。 私たちがプラットフォームでカバーする他の57言語（およびカウント）でも、同じ特典が利用できます。

Secure Code Warrior®トレーニングを展開した結果、開発者が「Secure Code Warrior®トレーニングで『これ』を学んだのを思い出したので、ここにセキュリティ上の懸念を解決するためのチケットを作成します」などと言い出し、脆弱性の修正が直接的に行われるようになりました」

Nicole Smith, Head of Security, Komodo Health

没入型シミュレーションでセキュリティに強い開発者になる

‍

ABAP開発者は、基本的なセキュアコーディングの実践に慣れることができます。をプレイすることで、セキュリティチャンピオンになることに挑戦することができます。 Missions.

Missions は、開発者が特定の脆弱性を悪用するためのシミュレーションプレイグラウンドです。悪用されたアプリがどのように機能するのかをリアルタイムで確認することで、攻撃的なセキュアコーディングスキルを身につけ、自分のプロジェクトを守るために活用することができます。

ABAPのコーディングに挑戦

ABAPの最新コンテンツで、開発者向けの先進的なトレーニングプログラムを簡単かつ効果的に提供することができます。

Secure Code Warrior の既存のお客様は、以下の方法でトレーニングコンテンツにアクセスできます。 トレーニング, Courses, Tournamentおよび Assessmentプレイモードをご利用いただけます。

もし、あなたのチームがまだ私たちのソリューションを導入していないなら、今すぐ 私たちのABAPコーディングチャレンジを試してみてはいかがでしょうか？

ABAPは、利用可能な多くの言語のうちの1つです

最も人気のある言語（Java、C++）や新星言語（GO、Typescript）を含む57の言語について、トレーニングコンテンツを提供しています。サポートされている言語の全リストをご覧いただき、選択したフレームワークでのコーディングに今すぐ挑戦してください。

2022年4月19日、Neil Maddenは、Oracle Java 15から18、およびOpenJDK 15、17、18における脆弱性を公開しました。この脆弱性は、ECDSA署名の暗号にあり、攻撃者はこれらの署名の署名チェックを完全にバイパスすることが可能です。 

ECDSA署名があまり知られていないため、この脆弱性に関する見出しを目にしても、すぐに見過ごしてしまいがちです。しかし、ECDSA署名は、認証のような重要なタスクにおいて、インターネット上のシステムを保護する上で重要な役割を担っています。

詳細について説明する前に、ハッカーがどのようにサイキックシグネチャを悪用するのかを実際に体験してみたいという方は、無料のラボに直接アクセスしてみてください。無料のラボ（Missions）にアクセスし、ご自身で試してみてください。

ECDSAの何が問題なのか？

ECDSAという言葉を聞いたことがない人もいるかもしれない。Elliptic Curve Digital Signature Algorithmの略で、楕円曲線の数学的性質を利用した暗号の一種で、現時点では業界で最も強力な暗号のセキュリティを提供するものです。

というように、重要な機能に多く使われているということです。

• SSL証明書の署名について
• 暗号化通信時のハンドシェイク
• サムル
• JWT署名
• OpenID Connectの署名

つまり、ECDSAはシステムを保護するための最も機密性の高い機能の多くで重要な役割を担っているのです。署名チェックを回避することができれば、非常に大きな被害を受ける可能性があります。

脆弱性はどのように悪用されるのですか？

ECDSAの数学は、残念ながらやや複雑です。しかし、知っておくべき重要なことは、ECDSA署名は2つの情報、すなわちrと sを含むということである。 

これらの数値は、署名の有効性を計算するために使用される。値rは、右辺のrと sの両方を使った計算の「結果」(左辺)である。0を掛けるのは良くないということから、ECDSAの仕様では、rや sの値が0になることがあれば、それらを破棄するように明示的に呼びかけている。 

しかし、ECDSAのJava実装はこれを考慮するのを忘れていた。そのため、rと sの両方が0である署名を受け入れることになり、これは常に真となる。JWTの例でこれを実証し、いかに簡単であるかを示しましょう。https://token.dev/ を使って、アプリケーションで生成されるのと同じような ES256 アルゴリズムのトークンを生成することができます。

JWTは3つのパートに分かれていることを思い出してください。

• ヘッダー（青字）
• ペイロード（緑色の部分）
• サイン（赤色）

さて、署名チェックを回避したい場合、どのようにすればよいのだろうか。署名はrとsの値を指定し、DER形式でエンコードされています。 

この新しい署名を使用するようにJWTを変更しましょう。JWTでは、等号は含まれないことに注意してください。

これで、署名のrと sが0に設定され、脆弱なバージョンのJavaでは、指定したペイロードに対して署名チェックが成功するようになりました。 

誰が影響を受けるのか、どう軽減するのか？

この脆弱性は、Oracle JavaとOpenJDKの両方に影響します。これらは以下の通りです。

Oracle Java SE（および旧バージョン、非サポート）。 

• 18

• 17.0.2

Oracle GraalVM Enterprise Editionです。 

• 22.0.0.2
• 21.3.1

OpenJDKです。

• 18
• 17.0.2
• 15.0.6
• 13.0.10
• 11.0.14
• 8u322
• 7u331

Oracle社、OpenJDK社ともに勧告を発表しており、すぐにでも適用可能なパッチがあります。 

本脆弱性に対する防御のためのハンズオンプラクティス

ここSecure Code Warrior では、サイキックシグネチャーのような最新の脆弱性から、何年も前から存在する脆弱性まで、重要な脆弱性に関する最も適切な情報と実践的な演習を開発者に提供するよう努力しています。

私たちは、リスクを真に抑えるには、開発者が防御メカニズムを理解し、最初から安全なコードを書けるようにすることが必要だと考えています。そのため、この脆弱性（および他の多くの脆弱性）の段階的なウォークスルーを作成し、あなたと影響を受けるチームのために提供しています。 

ウォークスルーでは、指示に従ってJWTのPhysic Signatureを悪用し、機能しているアプリへの影響をリアルタイムに確認することができます。

今すぐお試しください。

‍

セキュリティとデータ保護に関しては、最新の開発状況への迅速な対応が重要です。ハッキングや脅威はいつでもやってくるので、常に警戒することが重要です。私たちは Secure Code Warrior私たちは、最新の脆弱性、リスク軽減のための措置、ユーザーの保護方法など、最新の情報を提供するよう努めています。先日、Springライブラリの脆弱性についてお知らせしたように、今回も新たに発見された2つの脆弱性についてご紹介します。 

本日は、2つの新しい脆弱性（1つ目はMicrosoftのServer Message Block、通称「Windows RPC RCE」、2つ目はNGINXの「LDAP Reference Implementation」）に焦点を当てます。

これらの脆弱性に関して、これまでに判明していることと、リスクを軽減するためにできることをご紹介します。 

Microsoft Windows RPC RCE - CVE-2022-26809

4月のパッチチューズデーで、マイクロソフトはServer Message Block (SMB) 機能、特にRPCを扱う部分に脆弱性があることを公表しました。この脆弱性は、2003年にワームブラスターによって利用されたCVE-2003-0352と類似しているため、聞き覚えがあるかもしれません! 

悪用されるリスクと可能性はどの程度か？

マイクロソフトのアドバイザリーでは、「攻撃の複雑さ」は「低」、悪用リスクは「悪用の可能性が高い」と評価されており、実際に悪用が証明されていない場合の最高レベルとなっています。 

現在のところ、既知の悪用はありませんが、攻撃の複雑性が低く、「より可能性の高い」悪用であるため、assessment 、悪意のある行為者がBlaster攻撃を通じて迅速かつ容易に利用することが懸念されています。  

研究者は、公衆インターネット上で139/445番ポートにアクセス可能なホストを多数確認しており、大規模な探査が行われた場合、かなり心配な状況であると言えます。 

リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？

幸いなことに、この脆弱性を悪用されるリスクを軽減することは比較的容易です。 

1. インターネットからの139番と445番ポートへのアクセスを確実に遮断し、アクセスが必要な場合は内部からのアクセスのみに制限します。詳しくは、マイクロソフトのドキュメントを参照してください。 
2. 2022年4月12日にマイクロソフトが公開したパッチを適用してください。

NGINX - LDAPリファレンス実装RCE

NGINXは、2022年4月11日、システム上でリモートコード実行（RCE）が可能な「LDAP Reference Implementation RCE」という新たな脆弱性を公開しました。

脆弱性とは何ですか？

この脆弱性の特徴は、本番環境や一般的に機密性の高いシステムで使用されることを想定したコードに影響を与えないことです。むしろ、名前に「参照実装」とあるように、このコードの目的は、NGINX のセットアップで LDAP の統合がどのように機能するかを実証することです。

誰が危険にさらされるのか、そしてコードを守るために何をすべきなのか。

幸いなことに、NGINXはデフォルトでは脆弱性はありません。主なリスクは、LDAPエクステンションがインストールされている場合です。その場合でも、脆弱性が悪用されるためには、他の複数の条件も満たされる必要があります。もしリファレンス実装を使用しているのであれば、必ずプロダクションレディの実装に切り替えることをお勧めします。 

詳細については、NGINXの情報開示をご覧ください。

脆弱性が露呈していると感じていますか？私たちがお手伝いします。

今日のWindows RPC RCEやNGINX - LDAP Reference Implementation RCEから先月のSpringの脆弱性まで、ソフトウェアの脆弱性は常に存在していることがわかります。 

多くの企業は、コードや顧客に対するリスクを軽減するために、迅速な対応策に注力しています。しかし、これは後手に回るアプローチであり、重要ではあるものの、リスクを残したままになってしまう可能性があります。私たちは、安全なコードの構築、開発者のスキルアップ、そしてセキュリティに重点を置いた企業文化の醸成のためのプロアクティブな戦略が、脅威から自らを守る最善の方法であると信じています。 

ソフトウェア開発ライフサイクルの開始時に開発者主導のセキュリティを重視することは、保護機能の強化、より効率的なコード展開、そして時間とコストの節約につながります。

Secure Code Warrior 教育的なコンテンツから、新しいスキルの実践的な応用まで、独自のトレーニングプラットフォームで支援します。  

をご覧ください。 Secure Code Warrior learning platformは、セキュアコーディングのための開発者育成を支援します。

‍

‍

先日、Javaコミュニティで最も人気のあるライブラリの1つであるSpringライブラリが、リモートコード実行（RCE）に関する2つの脆弱性を公開しました。どちらの脆弱性にも該当するリスクがあるのか、またどのような対処をすればよいのかを理解しやすくするために、"Spring4Shell" と "Spring Cloud Function" について既知の詳細をまとめました。

脆弱性1 - "Spring4Shell" (CVE-2022-22965)

2022年3月29日、コミュニティは、Spring Core (SC) を標的としたエクスプロイトの概念実証のスクリーンショットを含む一連のツイートを発見し、最新リリース版である 5.3.17 を含む Spring Core のすべてのバージョンでリモートコード実行が可能であることを確認しました。

どのようなアプリケーションがリスクにさらされているのか？

現在、Tomcat上でホストされているアプリケーションのみが、この新しいエクスプロイトの危険にさらされていることが確認されています。この悪用は、Embedded Tomcat Servlet Containerやその他のTomcat以外のアプリケーションに対して成功したとは証明されていませんが、将来的にこれらのフレームワークに対して成功する可能性を排除するものではありません。 

Springは、この脆弱性について公式声明を発表し、現時点での理解では、以下の条件を満たすことで脆弱性が発生することを明らかにしました。

• JDK 9 以上
• サーブレットコンテナとしてのApache Tomcat
• 従来のWARとしてパッケージ化（Spring Bootの実行可能なjarとは対照的）。
• spring-webmvc または spring-webflux の依存関係
• Spring Framework バージョン 5.3.0 から 5.3.17, 5.2.0 から 5.2.19, およびそれ以前のバージョン

Spring4Shell」の悪用はどのように行われるのですか？

この悪用は、メソッドの署名にPlain Old Java Objects (POJO) を使用するリクエストで「データバインディング」 (org.springframework.web.bind.WebDataBinder) を使用することに依存します。

ここで、FooクラスはPOJOクラスであり、次のように定義できます。実際のクラスは、クラス・ローダーによってロードされる限り、重要ではないことに注意してください。 

このようなメソッドでリクエストが処理される場合、クラス・ローダーがクラスの解決に使用されます。クラスローダーは実行時にクラスをロードする役割を担っており、最初にメモリに可能なすべての型をプリロードする必要がありません。新しいクラスが使用されるときに、どの .jar ファイルをロードすればよいかを判断します。 

この脆弱性についての最新かつ詳細な情報は、Springのブログ記事で直接確認することができます。

脆弱性2 - Spring Cloud 機能 (CVE-2022-22963)

2022年3月27日、サイバーケンドラは、Spring Cloud Functionsに存在するパッチが存在しない0日間のリモートコード実行（RCE）の脆弱性に関する詳細を公開しました。この脆弱性には、ID「CVE-2022-22963」が付与されています。Spring Expression Resource Access Vulnerability」です。

どのようなアプリケーションがリスクにさらされているのか？

この脆弱性は、これらの条件下でアプリケーションに影響を及ぼします。

• JDK 9 以降
• Spring Cloud Functionsのバージョン3.1.6以下、3.2.2以下、または未対応のバージョン 

搾取の仕組みは？

Spring Cloud Functionは、開発者がspring.cloud.function.routing-expressionプロパティを通じてルーティングの処理方法を設定する機能を提供する。通常は設定やコードを通じて行われる。これは、"Spring Expression Language" (SpEL)を受け入れる強力な機能です。今回の脆弱性により、このプロパティはリクエストのHTTPヘッダを通じて設定できることが判明しました。つまり、攻撃者はRoutingFunctionエンドポイントへのHTTPリクエストに直接SpELコードを埋め込み、任意のコードを実行することが可能です。 

リスクを軽減するために、ユーザーはどのような手段を取るべきでしょうか？

Springは、バージョン3.1.7および3.2.3をリリースし、HTTPヘッダによるこのプロパティの設定を許可しないことでこの問題に対処し、脆弱性を軽減しています。いずれのバージョンにもアップグレードした後、追加の手順は必要ありません。

開発者がより安全なコードを書くための支援方法についてもっと知りたいですか？デモをご予約いただくか、セキュアコードコーチで無料のセキュアコーディングガイドラインをご覧ください。

‍

情報源

• https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
• https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/

‍

サイバーセキュリティ攻撃の増加とその巧妙化により、世界中のあらゆる分野、産業で変化が起きています。誰もが「左遷」しようとし、できるだけ早い段階ですべてのプロセスや手順にセキュリティを導入しようとしています。この状況は、新しいソフトウェアやアプリケーションを作成する際にセキュリティを組み込むDevSecOpsのような、サイバー防御の改善を目的とした全く新しい動きさえ育んでいます。 

これらの変化の多くは、開発者コミュニティの足元に着地しています。新しいソフトウェアやアプリケーションを作成し、書き、コーディングするのは彼らなので、より安全なコーディング手法を採用するよう求めるのは、素晴らしいアイデアのように思われます。結局のところ、新しいアプリケーションが最初に作成されたときよりも左にシフトすることはできないのです。

しかし、開発者コミュニティはその責任についてどう感じているのでしょうか。従来は、いかに早くコーディングできるかという点のみで評価されてきた開発者たちは、セキュリティチャンピオンという新しい役割についてどう考えているのでしょうか。また、会社の経営陣は、質の高いトレーニング、充実した報酬、この重要な新しい責任を引き受けたことにふさわしい評価によって、この努力を支援していると感じているのでしょうか。

2年目となる今年は、Evans Data Corp.と共同で、世界の開発者コミュニティを対象に、安全なコーディングの実践に関するスキル、認識、行動、およびソフトウェア開発ライフサイクル（SDLC）における影響と関連性の認識について包括的な調査を実施しました。その結果は、多くの点で非常に驚くべきものでした。

2022年開発者主導型セキュリティの現状調査  

Secure Code Warrior 開発者主導型セキュリティの現状調査」は、2021年12月にEvans Data Corp.が実施したものです。アジア太平洋地域、ヨーロッパ、北米で働く現役のソフトウェア開発者1,200名を対象に、ソフトウェアのコーディング、セキュリティ意識、トレーニング、サポート、モチベーションなどに関する質問を行った。調査は英語で行われ、グローバルな視点を正確に把握するために必要に応じて翻訳されました。調査対象者は、新しいアプリケーションを開発している開発者、および開発コミュニティ内の管理職です。

意外な事実が判明

本調査をあらゆる角度から掘り下げた詳細なホワイトペーパー（The challenges (and opportunities) to improve software security）とレポート（The state of developer-driven security, 2022）を4月11日（月）にリリースします。ホワイトペーパーには、セキュアコーディングの実践に関する調査結果やコミュニティから提起された懸念の分析、開発者チームがソフトウェアセキュリティを向上させるための組織のための推奨事項が記載されています。 

これらの課題の中には、組織で開発者と一緒に仕事をしている人や、開発コミュニティの中にいる人が疑問を抱くようなものもありますし、私たちもそうでした。 

例えば、アプリケーション・セキュリティを今日の最優先事項として挙げた回答者は、わずか14％でした。その代わりに、アプリケーションのパフォーマンスや機能・性能の優先順位付けといった、より伝統的な指標が全体的な焦点として残っています。

セキュリティの優先順位は非常に低く、調査対象となった開発者の67％が、既知の脆弱性や悪用を日常的にコードに残していることを認めました。その理由は、締め切りが厳しかったり、セキュリティよりも機能を優先させたり、あるいは単にセキュリティの問題を修正するのに必要なトレーニングや知識がなかったりするためです。

多くの場合、開発者は、何が安全なコードであるかを組織が定義しておらず、その状況を変えるための十分なトレーニングやサポートが提供されていないと述べています。

しかし、いくつかの否定的な調査結果にもかかわらず、意識が変化していることも明らかでした。開発者の大多数（66％）は、今後12～18ヶ月の間にセキュリティの優先順位が上がると予想しており、調査に参加した採用担当者の82％は、セキュリティを知っている開発者を、そうでない開発者よりも採用したいと表明しています。

この調査結果から、開発者コミュニティと彼らが働く組織が多大な変化に直面していることは明らかですが、ありがたいことに、近い将来と長期的な将来に対する計画も急速に具体化しつつあります。

調査結果の詳細については、ホワイトペーパーとレポートをご覧ください。また、現在のセキュアコーディングの実践に関する課題や、開発者のセキュリティスキル、ひいてはソフトウェアセキュリティを向上させるために組織が取り入れることのできる機会について、専門家のコメントも掲載しています。

をご覧ください。 Secure Code Warriorブログページでは、サイバーセキュリティに関するより深い洞察、ますます危険な脅威の状況、そして組織とお客様をより良く保護するための革新的なテクノロジーとトレーニングの採用方法についてご紹介しています。

‍