Secure Code Insight

Dieser Artikel erschien ursprünglich in Informationssicherheit Buzzund wurde von mehreren anderen Medien aufgegriffen. Er wurde für die Syndizierung hier aktualisiert.

Gegen Ende des letzten Jahres veröffentlichte die erstaunliche Community von MITRE ihre Liste der CWE Top 25 der gefährlichsten Softwarefehler, die die Welt im Jahr 2019 betreffen. Diese Liste ist nicht meinungsgesteuert, sondern das Ergebnis einer vielschichtigen Analyse, die sich auf die Arbeit von Organisationen wie NIST sowie auf die veröffentlichten CVE-Daten (Common Vulnerabilities and Exposures) stützt. Um die "Top"-Schwachstellen zu bestimmen, wird ihnen eine Punktzahl zugewiesen, die auf ihrem Schweregrad, ihrer Ausnutzbarkeit und ihrer Verbreitung in aktueller Software basiert. Das ist keine Liste, die mit Lob überschüttet wird, soviel ist sicher.

Doch anders als bei den meisten Jahresrückblicken sind viele der Teilnehmer dieser Liste schon einmal erschienen... immer und immer wieder. Wenn dies die Billboard Hot 100 Charts wären, wäre es so, als würden Britney Spears'Baby One More Time und die Backstreet Boys'I Want It That Way jedes einzelne Jahr seit ihrer ersten Veröffentlichung erscheinen. Und warum habe ich diese Songs ausgewählt? Nun, sie sind ungefähr zwanzig Jahre alt (fühlen Sie sich schon uralt?), ähnlich wie einige dieser gefährlichen Softwarefehler, die uns noch bis ins Jahr 2020 plagen, obwohl sie schon vor Jahrzehnten entdeckt wurden.

Warum sind alte Bugs immer noch so gefährlich? Wissen wir nicht, wie wir sie beheben können?

Nummer sechs auf der aktuellen MITRE-Liste ist CWE-89, besser bekannt als SQL-Injection (SQLi). Die SQLi-Schwachstelle wurde erstmals 1998 entdeckt, damals, als viele von uns noch ihre brennenden Fragen an Jeeves statt an Google stellten. Ein Fix wurde bald darauf bekannt gegeben, und dennoch bleibt dies eine der meistgenutzten Hacking-Techniken im Jahr 2019. Der Akamai Zustand des Internets Bericht zeigte, dass SQLi der Übeltäter bei zwei Dritteln aller Angriffe auf Webanwendungen war.

Was die Komplexität angeht, so ist SQL-Injection weit davon entfernt, ein Exploit auf Genie-Niveau zu sein. Es ist eine einfache Lösung für einen Webentwickler, und wir wissen ohne zu zögern, wie man verhindern kann, dass diese Schwachstelle wertvolle Daten einem Angreifer preisgibt... das Problem ist, dass für viele Entwickler auch heute noch Sicherheit keine Priorität hat. Das mag vor zwanzig Jahren einfacher gewesen sein, aber bei der schieren Menge an Software, die heute und in Zukunft erstellt wird, kann das nicht länger die Norm bleiben.

Entwickler arbeiten in einem kaputten System (die meiste Zeit).

Es ist allzu einfach, sich zurückzulehnen und den Entwicklern die Schuld dafür zu geben, dass sie "schlechten" Code liefern. Die Wahrheit ist, dass ihre Prioritäten sich stark von denen des Sicherheitsteams unterscheiden. Ihr durchschnittliches Entwicklungsteam hat den Auftrag, so schnell wie möglich schöne, funktionale Software zu erstellen. Das unstillbare Bedürfnis der Gesellschaft nach Software sorgt dafür, dass die Entwicklerteams bereits überlastet sind und die Sicherheit keine primäre Rolle spielt; schließlich gibt es deshalb AppSec-Spezialisten. Software-Ingenieure sind an ein etwas kühles Verhältnis zur Sicherheit gewöhnt - sie hören nur von ihnen, wenn Probleme auftreten, und diese Probleme können die Produktion ihrer harten Arbeit aufhalten.

Auf der anderen Seite des Zauns sind AppSec-Spezialisten es leid, jahrzehntealte Fehler zu beheben, die bei jedem Scan und jeder manuellen Codeüberprüfung auftauchen. Diese Spezialisten sind teuer und rar, und ihre Zeit ist weitaus besser für komplexe Sicherheitslücken eingesetzt, anstatt bekannte Fehler immer wieder zu beseitigen.

Es gibt eine unausgesprochene Kultur des Schuldzuweisens zwischen diesen Teams, aber sie haben (oder sollten) das gleiche Ziel haben: sichere Software. Entwickler agieren in einer Umgebung, die ihnen kaum die besten Erfolgschancen in Bezug auf sichere Programmierung bietet; bewährte Sicherheitspraktiken werden nur selten als Teil ihrer Hochschulausbildung gelehrt, und Schulungen am Arbeitsplatz sind oft viel zu selten oder völlig ineffektiv. Die Folge sind astronomische Kosten für die Behebung alter Bugs in fehlerhaftem Code und die unmittelbare Gefahr einer rufschädigenden Datenpanne.

Der menschliche Faktor, a.k.a. "Warum machen all diese Tools unsere Daten nicht sicherer?"

Ein weiteres Problem, das häufig auftritt, ist, dass anstelle von Schulungen ein riesiges Arsenal an Sicherheitstools eingesetzt wird, um Probleme zu finden, bevor die Software in die freie Wildbahn entlassen wird. Das Arsenal an Anwendungs-Scan- und Schutz-Tools(SAST/DAST/RASP/IAST) kann sicherlich bei der sicheren Software-Produktion helfen, aber sie bringen ihre eigenen Probleme mit sich. Vollständiges Vertrauen in sie garantiert keine Sicherheit, denn:

• Kein "einziges" Tool kann nach jeder Schwachstelle, in jedem Framework, in jedem Anwendungsfall suchen
• Sie können langsam sein, besonders wenn sie im Tandem laufen, um sowohl statische als auch dynamische Code-Analyse zu liefern
• False Positives sind nach wie vor ein Problem; diese halten oft die Produktion an und erfordern eine unnötige manuelle Codeüberprüfung, um den Sinn der Alarme zu verstehen
• Sie schaffen ein falsches Gefühl der Sicherheit, wobei sichere Kodierung in der Erwartung, dass diese Tools alle Probleme aufspüren, vernachlässigt wird.

Die Tools werden sicherlich Sicherheitslücken aufdecken, die gepatcht werden können, aber werden sie auch alles finden? Eine 100-prozentige Trefferquote kann nicht garantiert werden, und ein Angreifer braucht nur eine Tür offen zu lassen, um sich Zutritt zu verschaffen und Ihren Tag wirklich zu ruinieren.

Zum Glück erkennen viele Unternehmen den menschlichen Faktor, der bei Software-Schwachstellen eine Rolle spielt. Die meisten Entwickler sind nicht ausreichend für die sichere Programmierung geschult, und ihr Sicherheitsbewusstsein ist insgesamt gering. Sie stehen jedoch ganz am Anfang des Lebenszyklus der Softwareentwicklung und sind in der besten Position, um zu verhindern, dass Schwachstellen jemals in den Code gelangen. Wenn sie von Anfang an sicher programmieren würden, wären sie die erste Verteidigungslinie gegen verheerende Cyberangriffe, die uns jedes Jahr Milliarden kosten.

Entwickler müssen die Chance haben, sich zu entfalten, mit Schulungen, die ihre Sprache sprechen, die für ihre Arbeit relevant sind und sie aktiv für das Thema Sicherheit begeistern. Fehlerfreier Code sollte ein Punkt des Stolzes sein, ähnlich wie das Bauen von etwas funktional Großartigem Ihnen den Respekt der Kollegen einbringt.

Ein modernes Sicherheitsprogramm sollte eine geschäftliche Priorität sein.

Entwicklungsteams können sich nicht selbst an den Ärmeln hochziehen und ein positives Sicherheitsbewusstsein im gesamten Unternehmen durchsetzen. Sie benötigen die richtigen Tools, das Wissen und die Unterstützung, um Sicherheit von Anfang an in den Softwareentwicklungsprozess einzubauen.

Alte Trainingsmethoden funktionieren offensichtlich nicht, wenn die MITRE-Liste immer noch so viele alte Sicherheitsfehler aufzeigt, also versuchen Sie etwas Neues. Suchen Sie nach Trainingslösungen, die sind:

• Hands-on; Entwickler lieben es, "durch Handeln zu lernen", nicht durch das Betrachten von sprechenden Köpfen auf Videos
• Relevant; lassen Sie sie nicht in C# trainieren, wenn sie jeden Tag Java benutzen
• Fesselnd; mundgerechtes Lernen ist leicht verdaulich und ermöglicht es Entwicklern, auf bereits vorhandenem Wissen weiter aufzubauen
• Messbar; kreuzen Sie nicht einfach ein Kästchen an und gehen Sie weiter. Sicherstellen, dass das Training effektiv ist und Wege zur Verbesserung schaffen
• Spaß; schauen Sie sich an, wie Sie das Sicherheitsbewusstsein zusätzlich zur Unterstützung einer positiven Sicherheitskultur aufbauen können und wie dies eine kohäsive Teamumgebung schaffen kann.

Sicherheit sollte für jeden im Unternehmen eine Priorität sein, wobei der CISO die Bemühungen auf jeder Ebene, unsere Daten sicherer zu machen, sichtbar und transparent macht. Ich meine, wer will schon das gleiche alte Lied in der Wiederholung hören? Es ist an der Zeit, sich ernsthaft mit der Beseitigung alter Bugs zu beschäftigen.

これは地味な統計だね？ 中小企業の 60% は、サイバー攻撃が成功してから6か月以内に廃業します*。大企業は何百万（あるいは数十億！）もの大企業が大量に出稼ぎ出しています。一方、ブランドの評判は薄れていきました。安全なコーディング手法を採用する組織が増えるにつれ、「シフトレフト」が起こっています。DevSecOps の台頭により、SDLC が始まった当初から安全なコードが焦点になりつつあります。この傾向が現実世界に及ぼす影響を調査するために、Secure Code WarriorとEvans Data Corp***は、安全なコーディング、安全なコード慣行、およびセキュリティ運用に対する開発者の態度に関する最近の調査を委託しました。

左へのシフト — 多くのレベルでのシフト

企業が脆弱性の修正には事後に30倍の費用がかかることに気付くにつれ、先制措置が新しいゴールドスタンダードになりました*。しかし、このような対策が効果的であるためには、 みんな SDLCでは、特に開発者がセキュリティを意識している必要があります。

‍シフトワン — じゃあ、今は誰が責任者なの？

の台頭とともに DevSecOps、組織は安全なコーディング手法を採用しています。その結果、私たちの調査で最初に明らかになった変化の 1 つは、コードセキュリティに対する責任が運用レベルにシフトしていることです。

開発者と開発マネージャーに「コードセキュリティの最終的な責任は誰にあるべきか」と尋ねたところ、、46% がプロジェクト/チームリーダーであると回答しました。これは、責任をアプリケーションセキュリティチームに任せるべきだと答えた人のほぼ2倍です。

これは、セキュリティ責任が従来のアプリケーションセキュリティチームから開発チームリーダーにシフトしていることを明確に示しています。

シフト2 — マネージャーの役割の変化  

セキュア・コード・トレーニングを実施しなければならないというプレッシャーは、さまざまな方向からマネージャーに押し寄せています。

41% が組織的に必要であることを明らかにしている セキュアコードトレーニング 上級管理職から来ています。規制遵守に対する要求の高まりも要因です。

マネージャーは、従来の開発からDevSecOpsへの移行を支援する上で重要な役割を果たしており、トレーニングやツールの購入決定の重要な意思決定者としての地位も高まっています。

‍シフト3 — 開発者のステップアップ

しかし、下層から変化を求める圧力も高まっています。マネージャーの 24% が、開発者からの提案や推奨により、安全なコーディング手法を実装していると回答しています。この点は、自社のセキュリティプログラムに貢献する開発者としての役割がますます重要になっていることを浮き彫りにしています。DevSecOps への移行により、予防的で安全なコーディング手法が新たに重視されるようになったことで、開発者は「防御の最前線」の役割にシフトしています。

シフト4 — チームダイナミクスの向上  

安全なコードプラクティスを実装することはソフトウェアの品質に重大な影響を与えるだけでなく、チームの働き方をより良い方向に変えます。調査対象の開発者の 60% は、安全なコードプラクティスを採用することで他の開発者とのコミュニケーションが向上したと考えていますが、そのメリットはそれだけではありません。

調査対象となった開発者とマネージャーの半数は、安全なコーディング慣行が開発者とそのリーダー間の協力の強化につながったと回答しました。46% が、開発者と利害関係者間のコラボレーションが増えたと回答しました。同時に、41% がリーダーと利害関係者間の協力関係が強化されたと回答しました。

DevSecOpsは、チーム、リーダー、利害関係者を新しい方法で結びつけ、ソフトウェア開発ライフサイクルのさまざまな役割や段階にわたる協力を強化します。

調査対象のマネージャーの 62% が、安全なコードプラクティスがコードリリースのスピードアップに役立つと回答しています。この単一の事実がこれらすべての変化と相まって、DevOps アプローチに移行することの明らかなメリットが浮き彫りになっています。しかし、この記事の前半で述べたように、このような対策が効果的であるためには、 みんな SDLCではセキュリティに対応している必要があります。この洞察は、組織が開発者をどのようにトレーニングするかに重大な影響を及ぼします。チームは最近特定された脆弱性について学び、コーディングに使用する特定の言語、つまりフレームワークで学ぶ必要があります。つまり、日常業務の中で、コード内の既知の脆弱性を発見し、特定し、修正する方法を理解する必要があります。このようなトレーニングにより、チームはリスクの最前線から防御の最前線へと変わります。

セキュアコーディングにおける変革の推進者として、Secure Code Warriorは人間主導のアプローチを採用して組織の「シフトレフト」を支援し、全体的なセキュリティアプローチを事後対応型から事前対応型へと移行します。

DevSecOpsの未来を実現するためのマネージャー、開発者、組織のニーズを一致させる、実践的で魅力的で実績のある安全なコードトレーニングについて詳しく知りたい場合は、 今すぐデモを予約。

‍

*中小企業の60％は、ハッキングされてから6か月以内に閉鎖されます。
‍https://cybersecurityventures.com/60-percent-of-small-companies-close-within-6-months-of-being-hacked/

**IBM Software Group; コード欠陥の最小化によるソフトウェア品質の向上と開発コストの削減
‍https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

***対応から予防への移行：アプリケーションセキュリティ2021の変わりゆく様子 セキュア・コード・ウォリアーとエバンス・データ・コーポレーション
https://scw.buzz/3169uzS

2019年6月11日、米国国立標準技術研究所（ニスト）は、詳細を説明した最新のホワイトペーパーをリリースしました いくつかの行動計画 削減用 ソフトウェアの脆弱性 そしてサイバーリスク。タイトル セキュアソフトウェア開発フレームワーク (SSDF) の採用によるソフトウェア脆弱性のリスクの軽減、NISTは、データ侵害による厄介な（費用のかかることは言うまでもありません）の結果を回避するための確固たるガイドラインを組織に提供しています。

SSDFは意図的に汎用的なものであり、すべての組織がまったく同じソフトウェア・セキュリティ目標を持っていることを前提としているわけではなく、またそれを達成するための正確なメカニズムを規定しているわけでもないことに注意することが重要です。主な目的は、セキュリティのベストプラクティスを実装することです。ライターのDonna Dodson氏は次のように述べています。「各セキュリティプロデューサーが適用可能なすべてのプラクティスに従うことが望まれていますが、各プラクティスの実装の程度は、プロデューサーのセキュリティ前提によって異なることが予想されます。これらのプラクティスは実装者にとって柔軟性を提供しますが、解釈の余地があまり大きくなりすぎないようにすることも明確です。」

もちろん、私が特に興味を持ったのは、開発者向けのソフトウェア・セキュリティ・トレーニングに関する具体的な内容でした。開発者がソフトウェア開発プロセスの初期段階から組織を守るためには、十分なトレーニングが必要であることは以前からわかっていました... しかし、何がそうなのでしょうか？ 十分な、正確に?世の中にはさまざまな意見があります。しかし、ようやく大きなポジティブな結果につながる方向に限界が押し広げられていると思います。

セキュリティトレーニングと効果的なセキュリティトレーニングがあります。

これまで、ソフトウェア・セキュリティ・トレーニングをより効果的に実施し、開発者のニーズに応え、それに合わせて調整する必要性について長々と話してきました。今でも、多くの組織では、せいぜい「チェックする」だけの練習に過ぎません。おそらく、数時間のビデオトレーニングがあるかもしれませんし、授業ベースの学習のためにツールを使わない貴重な時間を費やすことさえあるかもしれません。よく知られている (通常は簡単に修正できる) 脆弱性を悪用する攻撃者による大規模なデータ侵害が 1 日おきに発生しているという事実は、ソフトウェアセキュリティトレーニングが必要以上に効果的ではないことの証拠です。そして、おそらく最も重要なのは、トレーニングがまったく効果があったかどうかを検証するための準備がほとんど整っていないことです。脆弱性はより早く修正されたのでしょうか。コードの脆弱性は減少しているのか？受講者は実際にトレーニングを完了したのか、それとも「次へ」をクリックして修了しただけなのか。

開発者は忙しい人で、厳しい締め切りに間に合うように一生懸命働いています。セキュリティはたいてい不便であり、サイバーリスクをうまく軽減するための知識を教育中に身につけていることはほとんどありません。通常、「セキュリティ」という言葉は、AppSecチームのメンバーが自分の仕事の欠点を指摘しているときに出てきます。その結果、かなり冷淡で機能不全な関係になってしまいます。「あなたの赤ちゃんは醜いです。直してください」というシナリオ。

これは何を教えてくれますか？これは数十年前の危険信号です。開発者がセキュリティに関して十分な努力をしていないということです。開発者は責任を取る意欲がなく、機能的でありながらセキュリティのベストプラクティスを念頭に置いて作られたソフトウェアを作成するために必要なツールを探す意欲もありません。

開発者は賢く、創造的で、問題を解決するのが大好きです。セキュリティの脆弱性に関する動画を延々と視聴しても、開発者がワクワクしたり、エンゲージメントを維持したりできるとは考えにくいです。私がSANSのインストラクターを務めていたとき、最高のトレーニングは実践的なものであることがすぐにわかりました。そのため、生徒は脳をテストし、事前の学習に基づいて構築する実際の例を使用して、分析し、知的に挑戦することを余儀なくされました。ゲーミフィケーションと友好的な競争は、誰もが新しい概念を理解できるようにすると同時に、応用において有用で実用的なものであり続けるための強力なツールでもあります。

NISTのガイドラインには、次のように明記されています。「安全な開発に貢献する責任を負う役割を担うすべての職員に、役割別のトレーニングを提供する。職務別の研修を定期的に見直し、必要に応じて更新する。そして後で、「サイバーセキュリティスタッフ、セキュリティチャンピオン、上級管理職、ソフトウェア開発者、製品所有者、その他SDLCに関わる人たちの役割と責任を定義する」

この声明は、トレーニングの種類については具体的に述べていませんが、依然として組織を左派にシフトさせ、セキュリティのベストプラクティスを常に念頭に置いておくのに役立ちます。これは、効果的でより具体的なトレーニングソリューションを見つけることに責任を会社に負わせることであり、その結果、開発者が成功するための適切なツールと知識を身に付けることにつながることが期待されます。

文化:ミッシングリンク.

組織が開発者やその他の主要スタッフのトレーニングに時間とリソースを費やし、脆弱性の防止とセキュリティリスクの軽減における彼らの役割に重点を置いていても、組織のセキュリティ文化が根本的に壊れたままであれば、その努力が無駄になることがよくあります。

個人が効果的にトレーニングされ、目標が設定され、期待が明確になれば、セキュリティ環境における自分の位置を理解し、必要に応じて責任を取ることがはるかに容易になります。特に開発者の場合は、最初から安全なコードを書くためのツールと知識が与えられます。ただし、これは、二重処理や責任追求、サイロ化されたプロジェクト作業が少ない、ポジティブなセキュリティ環境で調整するのが最適です。

セキュリティは組織全体の最優先事項であり、優れた安全なソフトウェアを提供するための支援と協力的な取り組みが必要です。つまり、現実世界のコードの脆弱性を利用した楽しく魅力的なトレーニングを展開するのに十分な予算を確保し、勢いを維持するために組織全体で賛同を得られるようになるということです。この絶え間なく進化するデジタル環境では、トレーニングは提供と同じくらい継続的でなければなりません。過去に、「1回限りの」または「設定したら忘れる」コンプライアンストレーニングが適切または効果的であると言われたことがありますが、これは誤りです。

この新しいNISTの枠組みには、ポジティブな安全保障文化を育むための要件が具体的に明記されているわけではありませんが、そのガイドラインをうまく遵守するには、間違いなくそれが必要です。ただし、組織は「開発者が従うべき安全なコーディング手法を含め、組織のソフトウェアが満たすべきセキュリティ要件を明記したポリシーを定義する」べきだと述べています。

上記は、チーム内のセキュリティスキルを強化し磨くために不可欠です。自社のポリシーと現在のアプリケーションセキュリティ環境を評価する際には、次の点を考慮すると役立つ場合があります。

• ソフトウェア・セキュリティのガイドラインと期待事項は明確に定義されていますか?
• 目標を達成するために自分が果たす役割について、全員が明確に理解できているか?
• トレーニングは頻繁に行われ、評価されていますか？
• 開発者は、一般的なセキュリティバグを発生前に排除するうえで、自分たちが果たせる大きな役割を認識していますか？

さて、最後の部分は、すでに述べたように、主に組織と彼らが選択するトレーニング次第です。関連性があり、頻繁に実施し、参加してもらえるものでなければなりません。日常業務に適用できるソリューションを見つけ、状況に応じて知識を深めましょう。

これからどうする？

これらの新しいガイドラインを深く掘り下げてみると、かなり圧倒されるでしょう。ほとんどの企業が必要とする強固で安全なソフトウェアを、可能な限り最も安全な方法で作成、検証、展開するには、本当に多くの人手が必要です。トレーニングだけの問題ではありません。サードパーティ製ソフトウェアを使用する際に考慮すべきガイドラインがあります (既知の脆弱性を持つコンポーネントの使用 まだ座っている OWASP トップ10結局のところ）、検証、ペネトレーションテスト、コードレビューに関する提案、セキュリティ記録管理に関するガイドライン、適切なツールチェーンなど。全体像を把握するための実用的な洞察は、Gary McGraw博士の論文にあります。 BSIMM モデルこれはNISTのドキュメント全体で参照されています。

ただし、開発者が適切なツールと知識を得て、最初から安全なソフトウェアの構築に真に成功できれば、最速で成果を上げることができます。SDLC の後の段階でよくある脆弱性が何度も出現するのを防ぐ方が、ビジネスにとってはより安価です (そして全体的に迅速です)。その強みを活かし、組織のセキュリティ面に関わるインセンティブを提供しましょう。本当に楽しいことですし、彼らは悪者を排除し、私たちのデータを安全に保つために必要なジャストインタイムのヒーローになることができます。

参考文献:

1. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 2。
2. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 5。
3. SSDF の採用によるソフトウェア脆弱性のリスクの軽減 (2019 年 6 月 11 日) ページ 4。

若い頃、よく遊んでいました 破滅そして確かに、最初は、ゲームの最初の2、3回のランスルーを完了するために、さまざまな難易度を切り替える必要がありました。「アイム・トゥー・ヤング・トゥ・ダイ」（イージー）から「ナイトメア」（ヴェリー・ハード）まで多岐にわたりました。テクノロジー企業を経営する上での難易度を単純にリセットして変更できたらいいなと思う日があります。特に、非常に多くの要素がデリケートで不安定で、失敗しやすい初期段階ではそうです。

統計は 有名で地味な：スタートアップは90％前後の割合で倒産しています。これは長年続いていますが、さらに掘り下げてみると、一般的な内訳では、スタートアップの21％が初年度、30％が2年以内、30％が2年以内に、50％が5年以内に、70％が最初の10年以内に失敗します。

共同創設者のマティアス・マドウ、ファテマ・ベイドン、コリン・ウォン、ネイサン・デズメット、ヤップ・カラン・シンが「レベル10」にたどり着いたことを誇りに思います。これは、ゴールドマン・サックス、シスコ・インベストメント、パラディン・キャピタル、フォージポイント、エアツリー、タイダルなどの投資家と、私の独立取締役であるジム・プフラギングとナンヒ・シンの支援に支えられて、「レベル10」に到達したことを誇りに思います。。

創設チームは、10年間、すべての教訓、勝利、挫折を乗り越えて団結し、船を導いてきました。私たちは規模を拡大しつつあり、開発者リスク管理のリーダーとして、次の章である SCW 2.0 に立ち向かう準備ができています。

2024年：業界初のデータインサイトツールを市場に投入した年。

人材のスキルアップによる投資収益率を実証することは非常に困難ですが、2024年、SCWは業界全体が求めていたものを達成しました。「開発者のスキルを向上させることで、ソフトウェアの安全性が向上することを証明できますか？」私たちは、定評のあるプログラムを実行している大口のお客様から脆弱性と問題の修復に関するデータを収集しました。お客様からの検証により、安全な開発者が作成したコードが他の開発者が作成したコードと比較して、脆弱性の減少の中央値が 53% であったことを誇らしげに証明できました。また、セキュア開発者はセキュリティ問題を 2 ～ 3 倍速く修正できるため、時間を節約し、リスクにさらされるリスクを軽減できることも証明されました。

最初に門を出たのは SCW トラストスコア、 のみ 企業のセキュア・コーディング・プログラムの影響を定量化するベンチマーク機能セキュリティリーダーは、開発チームのセキュア・コーディング・スキルについて、データに裏打ちされたきめ細かなインサイトを得たり、業界標準と比較したりすることが初めて可能になりました。これは、多くの開発者がプログラムの重要な調整を行うために待ち望んでいた完璧な可視性であり、個々の開発者が生涯にわたってセキュリティスキルを強化するための学習経路を提供するために待ち望んでいたものです。さらに、次のような記事も公開しています。 研究論文 元米国ナショナル・サイバー・ディレクターのクリス・イングリスと、パラディン・グローバル・インスティテュート会長で元米国ナショナル・サイバー・ディレクター代理のケンバ・ウォルデンと。

その後、リリースしました SCW トラストエージェントは、組織のコードリポジトリ全体を可視化し、すべてのコミットを開発者の安全なコーディングスキルと照らし合わせて分析するコンパニオンサービスです。SCW Trust Agent は SCW Trust Score に基づいて構築されており、企業のセキュリティプログラムがすべてのコミットにどれほど効果的に適用されているかを協力して実証しています。

これらのツールは、企業のセキュリティリーダーが次のような目標を達成するのに役立ちます。 CISAのセキュリティ・バイ・デザイン・ガイドライン開発者のセキュリティスキルの検証、安全なコミット、そして最終的には実証済みの安全な設計原則に必要な脆弱性のカテゴリの根絶を行います。

やあ、パートナー！パートナーネットワークは拡大を続けており、顧客ベースも拡大を続けています。

サイバーセキュリティ業界に携わることで心温まる側面の1つは、本質的に、私たち全員が1つの大きくてマニアックで情熱的なコミュニティであり、ほとんどの場合、相互の成功だけでなく、すべての人にとってより安全なデジタル世界を追求するために力を合わせることをいとわないということを理解することです。

さまざまなセキュリティおよびテクノロジー企業に電話できることを光栄に思います 私たちのビジネスパートナー当社のパートナープログラムは、当社が成長を促進するうえで重要な役割を果たしています。2024年末に向けて、情報管理のグローバルリーダーとの2回目のOEMパートナーシップを発表しました。 オープンテキスト。この開発は、当社の主力OEMパートナーと相まって、 ブラックダックは、企業とそのセキュリティプログラムの現代のニーズに応える、本格的で包括的なソリューションを提供する素晴らしい機会を与えてくれます。

さらに、現在、650を超える企業顧客を誇っています。10 年前、最初の大口顧客を祝って 4 人のチームに安い昼食を勧めたときのことを覚えています。私たちは、開発者を変化の担い手として、予防的セキュリティに取り組むことを恐れないクライアントの健全な足跡をしっかりと築いてきました。

究極のディスラプターであるAI、そして開発者が主導するセキュリティの未来

人工知能、LLM、AI コーディングツールは、2 年以上にわたり、すべての IT プロフェッショナルの口で話題になっています。そして、私たちは社会として、テクノロジーの歴史における決定的な瞬間にいます。ほぼすべてのカテゴリーに豊富な AI ツールが揃っているため、生産性が大幅に向上することが期待されています。ソフトウェア開発では、 最近の GitHub アンケート ほとんどのエンジニアがAIを活用したコーディングアシスタントの採用を開始していることが明らかになりました。

これらのツールの使用を承認している組織はわずか38％ですが、現在ではソフトウェア開発環境の一部となっています。ツールの使用は避けられないため、セキュリティリーダーは「シャドーAI」の状況を作り出すのではなく、開発者を安全で責任あるコーディングの旅に導くことに注力すべきです。セキュリティ意識の高い開発者は、セキュリティスキルの低い開発者が抱える継続的なリスクを増大させることなく、生産性の向上から真に利益を得るために必要な批判的思考とセキュリティに関する専門知識をもってこれらのツールを活用できます。

2025年は、AIコーディングの進歩が続く年です。それでも、企業がこの分野やその他多くの分野で開発者リスク管理を効果的に適用できるよう支援できることが1つまたは2つあるかもしれません。今後の動向に注目して、私たちの旅が私たちをどこへ導くのか見守っていただきたいと思います。

サイバー脅威が蔓延し、高度化するにつれて、サイバーセキュリティの焦点は安全なコードの重要性に集中しています。ホワイトハウスの 国家サイバーセキュリティ戦略 およびサイバーセキュリティおよびインフラストラクチャセキュリティ庁（CISA）の セキュリティ・バイ・デザイン イニシアチブは、他の国のイニシアチブや法律とともに、セキュリティに対する責任をソフトウェア開発者に真っ向から負わせています。ソフトウェア開発ライフサイクル (SDLC) の早い段階でセキュリティを確保するために左へ、より正確には左にシフトすることが、かつてはあれば良いと考えられていましたが、今や組織にとってデータやシステムを保護し、侵害による規制の影響を回避するために不可欠です。

安全なコーディングプラクティスを実現するための鍵は、開発者のトレーニングにあります。ソフトウェアエンジニアは通常、以下の内容を受け取ります。 サイバーセキュリティ教育はほとんどまたはまったくない。特に今日の加速するDevOps環境における彼らの仕事は、急速に機能するジェネレーティブAIモデルの助けを借りて、新しいアプリケーション、アップグレード、サービスをできるだけ早くスピンアウトし、SDLCの後半のある時点でセキュリティチームがサイバーセキュリティの問題に対処できるようにすることでした。これは、大量のコードが作成されることで発生する大量の欠陥に対処するには非効率的な方法であり、その結果、ソフトウェアの脆弱性がエコシステムに放出されることがよくあります。

開発者は、最初から安全なコードを書くためのトレーニングを受け、AI によって生成されたコードや、使用しているオープンソースやその他のサードパーティソフトウェアに含まれる安全でないコードを検出できるようにする必要があります。多くの開発チームや組織にとって、これは未知の領域です。開発者が自分たちに必要なトレーニングを受けていることをどうやって知るのでしょう?そして、そのトレーニングは定期的に実施されているのでしょうか？

開発者教育に取り組む企業の中には、開発者が習得するためのベースラインとなるスキルセットを確立し、明確に定義されたベンチマークに照らして進捗状況を測定することが有益であると考える企業もあります。その取り組みを支援するために、Secure Code Warriorは開発者のセキュリティトレーニングの進捗状況を正確に測定するためのベンチマークを開始しました。は SCW トラストスコア これにより、組織はトレーニングが仕事にどの程度適用されているかを測定し、セキュリティ、開発者、エンジニアリングの各チームが協力できるようになります。

これは、改善すべき分野を特定しながら、セキュアコードトレーニングが定着しつつあることの証拠を確認する方法です。

セキュアデザインの事例

ソフトウェア開発者は、プロセスの開始時にSDLCにセキュリティを導入する理由は十分にあります。アプリケーションやサービスに対する需要の高まりと、AI が開発プロセスにもたらすスピードは、 役に立った ジェネレーティブAIをすぐに採用した開発者にとっても、結果的には必然的に バギーソフトウェア パイプラインにリリースされています。生成されるコードが増えれば増えるほど、欠陥も増えます。 最近の研究 は、アプリケーションの4分の3近く（作成方法に関係なく）に少なくとも1つのセキュリティ上の欠陥があり、その20％近くが重大と見なされていることを発見しました。

SDLCの後半で脆弱性に追いつくのは、非常に時間とコストがかかるようになっています。米国国立標準技術研究所 (NIST) 見つけた テスト中の欠陥の修正には、SDLCの開始時にソフトウェアを保護するよりも15倍の時間がかかり、展開/保守段階での修正には30〜100倍の時間がかかることがあります。

これらすべてが、開発サイクルの最初にセキュリティを適用することの重要性を浮き彫りにしています。これは、リスクを軽減する最も効果的な方法であるだけでなく、最も費用対効果が高いことが証明されています。SDLC の開始時にセキュリティを導入するにあたっては、開発者が個別の組織として機能するのではなく、セキュリティチームと連携して作業するのが最適な立場にあります。また、セキュリティのベストプラクティスのトレーニングを受けた開発者は、脆弱性を効果的に軽減してきました。問題は、トレーニングを受けた開発者がほとんどいないことです。

ベンチマークの魅力

企業にとっての基本的な道筋は、セキュリティスキルのベースラインを確立し、トレーニングを提供し、開発者が必要なスキルを習得していることを組織と規制当局の両方に検証することです。これは、あらゆる経済セクターの多くの組織にとって困難であることが証明されていますが、必ずしもそうである必要はありません。

セキュリティリーダーが指摘する課題の 1 つは、トレーニングプログラムを企業全体に拡大することの難しさです。しかし、SCW の調査によると、特に開発者の幹部が大勢いる組織は、セキュア設計アプローチをうまく実装できることが分かっています。小規模な組織の結果では、セキュリティバイデザインの原則をどの程度うまく適用しているかが大きく異なる傾向にあります。それでも、彼らもトラストスコアを含むアプローチの恩恵を受けることができ、より早く改善が見られる可能性があります。

Trust Scoreは、ベンチマーク指標を使用して個々の学習者の進捗状況を測定し、スコアを集計してチーム全体のパフォーマンスを評価し、組織の進捗状況を業界のベンチマークやベストプラクティスと比較します。トレーニングを追跡するだけでなく、開発者が新しいスキルを日常的にどの程度うまく活用しているかを示します。また、組織がトレーニング/スキルアッププログラムを最適化できるように、改善が必要な分野も浮き彫りになっています。

CISA全体で 重要インフラセクター データが入手できたとしても、ほとんどの組織は安全な設計の原則をほぼ同じレベルで実装しています。金融サービスや防衛産業の基盤から、医療、IT、重要製造に至るまで、さまざまなセクターのトラストスコアは同じ範囲で低下し、1,000点満点で300点をわずかに上回りました。最も規制の厳しい業界である金融サービスが最前線にあるという従来の通念にもかかわらず、どの業界も他の業界を上回ることはありません。

化学、エネルギー、原子力事業など、トラストスコアランキングに含まれていない重要インフラセクターは、一般的に独自のソフトウェアを作成せず、代わりに他のセクター、特にITに依存しています。しかし、これらのセクター内で安全なシステムを維持することの重要性（原子力発電所が危険にさらされるのを誰も望んでいない）は、そもそもそのセクターが使用するソフトウェアを保護することがいかに重要であるかを示しているに過ぎません。

結論

規制圧力の高まりとサイバー脅威の状況の現実により、データ、システム、事業運営、評判を保護したい組織にとって、セキュアバイデザインのアプローチが不可欠になっています。安全なソフトウェアの開発は大部分が開発者の手に委ねられていますが、必要な教育を提供し、その適用方法を示す徹底的なスキルアップとトレーニングプログラムという形での支援が必要です。

Trust Score などのツールに裏打ちされたベンチマークを含むプログラムでは、開発チームの重要な進捗状況を明確に把握できます。これは、開発者と彼らが働く企業の両方にとって、セキュアなソフトウェア開発スキルを常に向上させながら、新しいSecure-by-Designの要件を満たすために必要な、極めて重要な新しいアプローチです。

‍

で セキュア・コード・ウォリアー、私たちのモットーは常に、開発者に実践的なアジャイル学習体験を提供することでした。つまり、日常業務の一部として、現実世界で実践的なセキュリティトレーニングを提供することです。私たちはこれを「実践による学習」と呼んでいます。

開発者が今取り組んでいることに的を絞ったトレーニングは、企業にとってさらに有意義な結果をもたらすのに役立つやりがいのある体験を提供することを私たちは知っています。つまり、バトルテストされ、品質管理され、タイムリーに市場に出荷する準備ができているコードリリースをより迅速に行うことができます。そのサウンドが気に入らない企業などあるでしょうか。

とのエキサイティングな新しい統合を通じて、このエクスペリエンスを強化しています アピイロは、重要なアプリケーションリスクの優先順位付け、修正、防止、管理に必要な可視性をAppSecチームとリーダーに提供する、主要なアプリケーションセキュリティポスチャ管理（ASPM）プラットフォームです。2 つのプラットフォームを統合することで、開発者がセキュリティリスクを修正する際に、関連性の高いコンテキストとリアルタイムのセキュリティトレーニングが開発者に提供されます。これにより、開発者はコンテキストを切り替えたり、日常的に使用する開発ツールの使い慣れた環境から離れることなく学習できるようになります。

では、この魔法はどのようにして起こるのでしょうか？Apiiroは、Apiiroによって検出された、またはサードパーティのセキュリティツールによって取り込まれたアプリケーションのセキュリティ結果を、Secure Code Warriorのタイプと言語別の関連トレーニングにマッピングし、チケット、問題、またはメッセージとして関連する開発者またはチームに提供します。Apiiro と Secure Code Warrior の統合により、別のツールで別の時点でアクションを実行する必要がなくなるため、ソフトウェア開発ライフサイクルの中断を最小限に抑えることができます。これは、企業が質の高いコードをより早くリリースし、開発者の効率を高められるよう支援するもう一つの方法です。

この新しい統合とパートナーシップの詳細については、以下をご覧ください アピイロのブログはこちら。

‍

ほとんどの組織は、ソフトウェア開発ライフサイクル（SDLC）の重要な要素としてセキュリティを重視することに依然として苦労しており、堅牢なDevSecOpsアプローチを克服できる組織はほとんどありません。多くの企業にとって、機能やリリース期限を優先することが、依然としてセキュリティよりも優先されています。これには、高額なデータ漏えいのリスクが高まったり、チームがセキュリティチケットをふるいにかけてやり直したりすることによる生産性の低下などの影響が伴います。

なぜなら、開発者はリスクを排除するための最前線だからです ソフトウェアの脆弱性、組織にとって自社の成熟度を高めることを考えることは重要です 開発チーム。しかし、これにはいくつかの疑問が生じます。

組織は開発チームのセキュリティ成熟度をどのように評価していますか?セキュリティ成熟度ロードマップを設定することが不可能な作業に思えないようにするにはどうすればよいでしょうか。開発者のエンゲージメントを維持し、セキュリティの成熟度を高めるためのモチベーションを維持するにはどうすればよいでしょうか。

セキュア・コード・ウォリアーからの洞察を利用しました 開発者主導のセキュリティ調査の現状 これらの質問に対する答えを理解し、世界クラスのカスタマーサービスチームを活用して、他の組織が答えを見つけるために何をしているのかを調べました。‍

開発チームのセキュリティ成熟度を高めるにはどうすればよいでしょうか?

セキュリティ成熟度の向上に関しては、同じ組織は2つとありません。企業が左にシフトする取り組みの成功に影響を与える可能性がある考慮すべき要素は数多くあります。そうする企業には、コードの作成やリリースが速くなるなど、ほとんどまたはまったくなくても済むなど、多くのメリットがあります。 脆弱性これにより、費用のかかるやり直し作業が減り、最終的にはリスクが軽減されます。

進歩を遂げている組織には、経営陣の支援を得た明確な計画と、（とりわけ）以下を含むセキュリティの成熟度を長期にわたって継続的に改善するためのまとまりのあるアプローチがあります。

• セキュリティ成熟度ベースラインの定義
• チームのセキュリティ成熟度の評価
• 主なセキュリティ弱点の特定
• ポジティブなセキュリティ文化の構築

新しいホワイトペーパーをご覧ください 開発チームにおけるセキュリティ成熟度の重要性 以下を詳しく見てみましょう。

• 開発チームにおけるセキュリティ成熟度とは何か、なぜ重要なのか
• 開発チームのセキュリティ成熟度のさまざまな段階と特徴は何か?
• 開発チームのセキュリティ成熟度を高めるには何が必要ですか?

Vor fünf Jahren schlossen sich die belgischen Banken zusammen, um diesen fantastischen TV-Spot zu drehen, der die Geschichte von Dave erzählt, einem extrem begabten Hellseher, der einige ziemlich spezifische persönliche und finanzielle Informationen kennt. Der Werbespot hat Millionen von Verbrauchern über die Tatsache aufgeklärt, dass ihr gesamtes Leben im Internet zu finden ist, und jeden dazu ermutigt, wachsam zu sein.

Schauen Sie sich das Video an, und Sie werden sehen, dass es heute noch aktueller ist als 2012, und wir wissen, dass die Folgen noch erschreckender sind.

Wenn Sie das Gefühl haben, dass Cybersicherheitstrainings Ihrer C-Suite und Ihren Mitarbeitern große Kopfschmerzen bereiten, mit langweiligen Diashow-Trainings, erdrückenden Regeln und jemandem, der Ihnen ständig sagt, was Sie nicht tun sollen, dann ist es vielleicht an der Zeit, sich dieses Video anzusehen, um sich kreativ inspirieren zu lassen.

Sehen Sie sich das Video an, teilen Sie es mit Ihren Personal- und Kommunikationsteams und bitten Sie sie um Hilfe, damit Informationssicherheit wieder Spaß macht!

Egal, ob Sie die C-Suite in Cybersicherheit schulen oder Entwicklern in JAVA oder C# sichere Coding-Skills beibringen, es gibt einen Platz für Kreativität, Gamification und Spaß.

Egal, ob Sie die C-Suite in Cybersicherheit schulen oder Entwicklern in JAVA oder C# sichere Coding-Skills beibringen, es gibt einen Platz für Kreativität, Gamification und Spaß.

一方 VxWorks 平均的な消費者にはあまり馴染みのない名前ですが、このソフトウェア製品は、あなたや私のような多くの人々に毎日利益をもたらすことは避けられません。世界で最もポピュラーなリアルタイムオペレーティングシステム (RTOS) であるこの製品は、エンタープライズネットワークやファイアウォール、航空宇宙インターフェース、産業機器、さらには一部の医療機器に電力を供給するために、(プロキシ経由で) 私たちが頼りにしている主力製品であり、その用途が広く使われている例をいくつか挙げてみます。

そして今、私たちは、そうでなくても何億人もの可能性に直面しています。 数十億、これらのデバイスのうち、現在少なくとも11の脆弱性が侵害されています。ウインドリバーのチーフセキュリティアーキテクトであるアーレン・ベイカーは、以下の記事でこの件数に異議を唱えています。 検索セキュリティ、正確な範囲を明らかにすることは未確認であり、それほど高いとは考えられていません。それにもかかわらず、データ侵害や攻撃は常に発生していることはすでにわかっていますが、これは次のレベルです。確認された欠陥は比較的簡単に悪用され、攻撃者はネットワークパケットの送信を通じてデバイスをリモートで制御できるようになります。

もちろん、Wind Riverは影響を受けた顧客やアソシエイトに一連の修正とパッチをリリースしました。問題は、パッチアップデートを必要とするデバイスの数が非常に多いことにあります。サノスが指一発で世界を終わらせるのと同じように、まさにそうです。 避けられない その数のデバイスはパッチが適用されないままになり、長期間にわたって脆弱になります。

セキュリティ会社 アーミス この巨大な発見の背後にいたのは彼らの発見だと言って 緊急/11。複数の媒介動物からの攻撃が容易であることと、広範囲に及ぶ感染の可能性があることからも、深刻な感染が確認されたことは間違いありません。MRI スキャナーや VoIP 製品から、鉄道ネットワークや信号機に至るまで、あらゆるものを支えるソフトウェアにワームを作成して展開することは完全に可能です。

パニックになる時間ですか？

セキュリティ意識向上を人生の重要な使命としてきた者として、私は日常的に潜在的なセキュリティ問題をたくさん目の当たりにしています。パニックに陥りすぎると、1 日の大半をヒステリックな状態で過ごしてしまいます (結局のところ、むしろ教育やバグ修正の手伝いをする仕事に取り掛かりたいのです!)。しかし、URGENT/11の調査結果の範囲はかなり怖いです。見つかった 11 件の脆弱性のうち、6 件が重大と見なされています。として ハッカーニュース これらの欠陥は、バージョン6.5以降（VxWorks 653やVxWorks Cert Editionなどの認証用に設計されたバージョンを除く）VxWorksを実行しているデバイスに存在していたことが確認されています。つまり、一部の重要なテクノロジーは、10年以上にわたってデバイス乗っ取り攻撃の脅威にさらされてきました。すべてのデバイスが11の欠陥すべてに対して脆弱であるわけではなく（攻撃者が同じLABサブネットにいる場合にのみ悪用されるものもあります）、凡庸なハッカーでも必要なのはほんの少しの機会だけです。

Wind Riverには 迅速に行動し、詳細なアドバイスを提供しました アーミスがそうであるように、問題の軽減についてです。そして、VxWorks RTOSは非常に広く採用されています。 なぜなら 非常に信頼性が高く、ソフトウェア安全規制のスコアも高くなっています。通常、バグバウンティハンターはあまり気にしません。しかし、セキュリティ企業とウインドリバーがこの問題を解決するためにできることは限られています。パッチをダウンロードし、セキュリティアドバイスに耳を傾け、自社のデバイスを強化するのはエンドユーザーの手に委ねられており、そこが難しいところです。

まだ慌てる必要はないかもしれないが、この獣と格闘して服従させるには村が必要かもしれない。

緊急/11の脆弱性の説明

この時点で、バージョン6.5以降の侵害されたVxWorks TCP/IP IPNetスタックに接続されているすべてのデバイスが、少なくとも1つのURGENT/11の影響を受ける可能性があります。(ウインドリバーの CVE の全リストについては、以下を参照してください) ここに)。

ほとんどの場合、これらの欠陥によりリモートコード実行（RCE）攻撃やサービス拒否攻撃が可能になり、その一部が情報漏洩につながり、 ビジネスロジック 問題も。この場合、攻撃者はエンドユーザーの操作なしにデバイスの制御を乗っ取ることができるため、リモートコード実行は特にデリケートな問題です。疑わしいものを誤ってクリックしたり、何かをダウンロードしたり、詳細を入力したりする必要はありません。これにより、VxWorksデバイスは高度に「ワーム可能」になり、攻撃自体が自動的に実行されます。EternalBlueの製品を思い出してください ワナクライ ワーム?URGENT/11も同様ではあるが壊滅的な可能性を秘めており、世界規模の悩みの種となっている。

私たちはそれについて何ができるでしょうか？

さて、これを書いている時点では、URGENT/11の結果は不明のままです。メディアは業界に認識を示しており、ウインドリバーは明らかに影響を受けた人々を支援しています。今後数か月で、攻撃者がこれらの既知の欠陥を有意義な方法で悪用するかどうか明らかになりますが、それまでの間、明らかな解決策は、大量のアドバイスに耳を傾け、軌道上の関連デバイスにパッチを適用することです。

長期的に見ても、使命は変わりません。ソフトウェアセキュリティに関しては、誰もがもっとうまくやる必要があるということです。URGENT/11 CVEは、一般的に、簡単に通り抜けることができるように心配なほどシンプルなバックドアであり、長年にわたって発見されなかったという事実は、業界全体の懸念と認識がかなり低いことの証です。

すべての開発者には自分の役割を果たす機会があり、本番環境の最初からコードを保護する方法を学ぶためのサポートが必要です。アプリケーションセキュリティから経営幹部に至るまで、周囲の影響力のあるチームが、ビジネス内のあらゆるソフトウェアタッチポイントでポジティブなセキュリティ文化を確実に浸透させることができます。

自分のセキュリティ意識を試してみませんか？当社のゲーミフィケーションプラットフォームでは、URGENT/11 で発見されたものと同様の実際のコード課題が発生する可能性があります。それらをチェックして、どうなるか見てみましょう。

• DHCP オファーのヒープオーバーフロー/ipdhcpc の ACK 解析のヒープオーバーフロー（CVE-2019-12257）
  メモリ破損-ヒープオーバーフロー
• 不正な形式の TCP オプションによる TCP 接続 DoS（攻撃拒否）（CVE-2019-12258）
  トランスポート層保護が不十分-機密情報の無防備な転送
• ipdhcpc DHCP クライアントによる IPv4 割り当てにおける論理的な欠陥（CVE-2019-12264）
  ビジネスロジックの欠陥
• IGMP 解析におけるヌルデリファレンス経由の DoS 攻撃 (CVE-2019-12259)
  メモリ破損-NULL デリファレンス
• IGMPv3 固有のメンバーシップレポートによる IGMP 情報の漏えい（CVE-2019-12265）
  情報漏えい-機密データ漏えい