セキュリティコードインサイト

Secure Code Warriorでは、顧客体験を改善し、プラットフォームを通じて付加価値を提供するため、絶えず革新を続けています。

今月は、コース管理者環境、待機時間を短縮しながら新機能を事前に利用できる機能、SAP:ABAPコンテンツに関する新たな更新がリリースされました。

管理者向けには、言語や脆弱性カテゴリを横断した一括操作が可能な強力な表形式ビューにより、エンドユーザー体験を重視したコース管理が容易になりました。また、新しい機能を簡単なオン/オフ切り替えで事前に利用できるようになりました。

詳しく見ていきましょう！

新しいコース作成環境により、コースをより簡単に作成・管理できます。

今や、大量の作業を通じて複数の学習パスや言語にまたがるコースを簡単に設計・展開できます。プロセスを繰り返すことに時間を費やす代わりに、コンテンツと戦略に集中することで、開発者がより効果的に学習できるよう支援できます。

現在、会社の管理者はコース作成フローの更新を利用できます。

強力な表形式の表示と検索環境で、コース設計の時間を節約しましょう。

すべての言語および脆弱性カテゴリに関するトレーニングコース情報を単一ビューでアクセスできるようになりました。これにより、複数の開発チーム向けのコースをより簡単かつ迅速に作成できます。

新しい表形式の表示により、コンテンツの概要を一目で簡単に確認したり、詳細情報を詳しく確認したりできます。コースコンテンツは言語および脆弱性カテゴリ別にグループ化され、各グループレベルの活動タイプや難易度などの追加詳細情報と共に、より簡単に探索できるようになりました。

検索機能を使用したりフィルターを適用したりして、注目したい詳細情報に範囲を絞り込むこともできます。また、テーブルデータを他のアプリケーションにエクスポートしたり、全体またはフィルター処理された行をCSVファイルとしてエクスポートして、さらに分析することも可能です。

‍

大量の作業を少ないクリックでより多くのタスクを実行

すべての言語に変更を適用する代わりに、一箇所でコースを一括変更できます。一括操作により、管理者は時間を節約し、重要な業務、つまり開発者に適したコース体験の設計に集中できます。

新しいバッチ処理には以下が含まれます。

• 教育課程の重点追加（例：OWASP Top 10または全言語における特定の脆弱性カテゴリ）
• コースに言語を追加し、コンテンツを素早く更新しましょう。
• 選択した行またはすべての行のモジュールをコピー、ロック、またはロック解除
• コースから言語またはモジュールを削除
• すべての言語に対して、ウェルカムメッセージと終了メッセージを一度に設定

‍

教育課程終了評価経路

各言語に合わせて教育課程終了評価を調整し、単一ビューで管理できるようになりました。

言語およびコースタイプに基づいてカスタマイズされた評価パスを簡単に作成し、教育課程修了時にスキルを測定・評価できます。

新機能をいち早く体験してみてください

‍

以前は、新しい機能がリリースされることを知り、正式リリース前に試してみたい場合、カスタマーサクセスマネージャーに問い合わせ、当社チームがその機能を有効化するまで待つ必要がありました。

管理タブで簡単なトグル操作だけで、チームがいつどの機能を有効化するかを制御できるようになりました。もう待つ必要はありません。

簡単に移動 管理 > もっと見る > 早期アクセス 試してみるために。

この機能は、より多くの機能、特にユーザー体験に重大な変化を伴う機能に活用される予定であるため、環境をより適切に制御できます。

アーリーアクセスで利用可能な機能について知りたいですか？現在提供されているいくつかのオプションを確認してみましょう。

改善されたホームページより統一された体験のための展望

教育課程更新：

1. プレビュー状態モード
2. コースコンテンツに対する一括操作
3. グローバル歓迎メッセージ
4. 教育課程終了時の活動改善

現在の会社管理者はアーリーアクセスオプションを利用できます。

新たにリリースされた教育コンテンツによるABAPアプリケーション保護

ABAPでコーディングする開発者も、参加度が高く関連性の高いセキュリティコーディング教育の楽しさに加わることができます！新しい教育は、開発者がセキュリティコーディングスキルを向上させ、ABAPコードの脆弱性を減らすのに役立つでしょう。

Secure Code Warrior （実践）を通じて、以下の内容を扱うプログラムを提供できます。

1. 開発者が必要な時に楽しめる自己学習型教育
2. コンプライアンス、セキュリティフレームワーク、または開発者の技術レベルに合わせたカスタマイズされた学習パス
3. 面白いコーディング大会
4. セキュアコーディング能力評価

ABAP教育コンテンツの詳細については、こちらを参照してください。

------

セキュアコードウォリアーをお試しになりたいが、まだアカウントをお持ちでないですか？無料トライアルアカウントにご登録ください。今日から始めましょう。

これで今月の新機能の紹介を終了します！TwitterのSecure Code Warriorをフォローして、最新リリースや改善点に関する更新情報を受け取ってください。

ソフトウェアの脆弱性を事後的な考慮事項や革新の妨げと見なす場合、組織はデータ侵害、評判の毀損、そして高額な法的責任の扉を開くことになります。サイバー攻撃は、強力な開発慣行によって防げたはずのコードの弱点を悪用することがよくあります。

セキュリティコーディングは、セキュリティ原則を開発の全段階に組み込むことでこれらの問題を解決します。開発者は脆弱性が発見された後に修正プログラムを実装する代わりに、インジェクション攻撃やクロスサイトスクリプティング（XSS）といった一般的な脅威に対する保護機能を組み込んだコードを記述します。セキュリティコーディングにより、企業はリスクを低減し、ユーザーの信頼を守り、 規制要件を遵守しながら、信頼性の高い高品質なソフトウェアを提供する方法について詳しく見ていきましょう。

セキュアコーディングとは？

セキュリティコーディングとは、潜在的な脆弱性を解決するためのソフトウェアを作成する際に、セキュリティのベストプラクティスに従う原則です。セキュリティコーディングは、セキュリティを別個の開発段階として扱うのではなく、初期段階から検証済みの保護機能を統合することで、開発者がコードのセキュリティに対する所有権を持ち、これを効果的に適用できる技術を身につけられるようにします。

オープン・ワールドワイド・アプリケーション・セキュリティ・プロジェクト（OWASP）やソフトウェア・エンジニアリング研究所のCERT部門などの組織が作成した公認のセキュリティコーディング標準は、攻撃者が悪用する一般的な落とし穴を回避しようとする開発者にとって指針となる役割を果たせます。これらの戦略を既存のワークフローに安全に実装するためには、基礎的かつ実用的なセキュリティコーディング技術を継続的に構築することが、今日のサイバーセキュリティ環境において不可欠です。例えば、可能な限り多くのユーザー入力の検証はSQLインジェクション攻撃を防ぎ、出力エンコーディングはXSSを遮断するのに役立ちます。こうしたセキュリティコーディング手法やその他の手法は、セキュリティ侵害リスクを低減し、進化するサイバー脅威に対応できるアプリケーションの回復力を高めます。

セキュリティコーディングはなぜそれほど重要なのでしょうか？

セキュリティコーディングの重要性多くの成功したサイバー攻撃は、開発プロセスで防止できた脆弱性を悪用して行われます。最初からセキュリティ慣行を優先することで、攻撃者がデータに損害を与えたり運用を妨害したりするために利用可能な欠陥が生じる可能性を減らせます。ソフトウェア開発ライフサイクル（SDLC）の全段階にセキュリティを組み込むことで、あらゆる機能、更新、統合が保護を考慮して設計されるようにできます。

開発中にリスクを事前に解決することは、デプロイ後に発生した問題を解決するために緊急パッチ、ダウンタイム、インシデント対応リソースが必要になる可能性に比べ、はるかに低コストです。また、データ保護規制への準拠を強化することで、潜在的な罰金や法的問題を回避できます。セキュアコーディングの実践は、消費者からの企業への信頼を高め、強固なセキュリティをブランド評判の一部として確立します。

一般的なコードセキュリティ脆弱性

セキュアコーディングは、攻撃者が悪用する最も頻繁かつ危険な脆弱性だけでなく、AIコーディングツール使用時に現れる脅威ベクトルといった新たな脅威ベクトルを防ぐことを目的としています。以下は、いくつかの一般的な脆弱性とそれらが引き起こす可能性のある被害、そしてセキュアコーディングがこれらの脆弱性を緩和するのにどのように役立つかについての概要です。

逆直列化欠陥

逆シリアライゼーションの脆弱性は、アプリケーションが外部ソースからのデータを受け取り処理する際に適切な検証を行わない場合に発生します。シリアライゼーションはオブジェクトを保存または転送可能な形式に変換する処理であり、 デシリアライゼーションは、そのオブジェクトを再構成して使用可能にします。デシリアライゼーションの欠陥の影響は深刻であり、その結果、任意のコードが実行されたり、権限が昇格されたりする可能性があります。セキュアコーディングは、信頼できる検証済みのデータのみがデシリアライズされるようにし、可能な場合は信頼できない入力のデフォルトのデシリアライゼーションを完全に防止することで、この問題を解決します。

注射攻撃

インジェクション攻撃は、攻撃者がアプリケーションがコマンドやクエリの一部として解釈する入力を提供した際に発生します。最もよく知られているタイプは、悪意のあるSQL文をクエリに挿入してデータベースの内容にアクセスまたは変更するSQLインジェクションです。その他のタイプには、攻撃者が任意のコマンドを実行するコマンドインジェクションやLDAP（Lightweight Directory Access Protocol）インジェクションがあります。 インジェクション攻撃の結果は、不正なデータアクセスや削除からシステム全体の破壊に至るまで多岐にわたります。機密性の高い個人、金融、または専有情報を含むデータベースが主な攻撃対象です。セキュリティコーディングではパラメータ化されたクエリやプリペアドステートメントを使用し、 信頼できないデータを処理する前にこれを回避し、厳格な入力検証を適用することで、インジェクション脆弱性を防止するのに役立ちます。これらのセキュアコーディング慣行やその他のセキュアコーディング手法は、攻撃者がアプリケーションの意図した動作を変更できないようにすることができます。

クロスサイトスクリプティング (XSS)

クロスサイトスクリプティング (XSS)他のユーザーが閲覧するページに悪意のあるスクリプトを挿入し、ウェブアプリケーションを標的とするインジェクション攻撃の一種です。これは通常、アプリケーションの出力が検証されていないユーザー入力を含む場合に発生します。他のユーザーのブラウザがページをレンダリングすると、悪意のあるスクリプトが実行され、潜在的にクッキーを盗用したり、キー入力をキャプチャしたり、クッキーを悪意のあるサイトへリダイレクトしたりする可能性があります。

XSSの影響にはセッションハイジャックや身元盗用が含まれる可能性があります。企業の場合、これにより顧客の信頼が損なわれ、機密データが侵害された場合には規制関連の罰則につながる恐れがあります。セキュリティコーディングでは、ユーザーが提供したすべての入力は表示前に削除・エンコードし、出力を自動的にエスケープするフレームワークを使用し、実行可能なスクリプトを制限するCSP (Content Security Policy) を実装することでXSSを解決します。

アクセス制御

アクセス制御の脆弱性は、ユーザーが閲覧または実行できる項目に関するルールが適切に定義または適用されていない場合に発生します。脆弱なアクセス制御を通じて、攻撃者は意図されたユーザーロールの制限を回避し、潜在的に機密性の高いデータの読み取り、レコードの改変、または権限のあるユーザーのみが実行できる操作を実行できる可能性があります。

アクセス制御の問題は重大な問題を引き起こし、特にAIコーディングツールは苦戦を強いられており、開発者の技術と認識の必要性を強調しつつ、この脆弱性クラスを効果的に解決する必要があります。アクセス制御の解除が及ぼす影響は甚大です。例えば、管理者専用機能にアクセスできる攻撃者は、セキュリティ設定を無効化したり、個人情報を窃取したり、他のユーザーになりすましたりすることが可能です。

セキュリティコーディングプラクティスは、最小権限の原則に基づき、すべてのリクエストに対してサーバー側の認証チェックを適用し、セキュリティ対策として曖昧性（例：リンクの非表示）のみに依存しないことで、これらのリスクに対処します。また、厳格なアクセス制御テストを実施することで、これらの保護機能が長期的に強力に維持されることが保証されます。

サイト間リクエストフォージェリ (CSRF)

クロスサイトリクエストフォージェリ（CSRF）攻撃は、認証済みのユーザーを別のサイトで意図しない操作を実行させるものです。これには資金の送金、メールアドレスの変更、アカウント設定の改変などが含まれます。この攻撃が有効なのは、ブラウザが偽造されたリクエストにクッキーなどの有効な認証トークンを自動的に含めるためです。

セキュアコーディングは、各ユーザーセッションに固有のアンチCSRFトークンを実装し、各状態変更リクエストで有効性を検証することでCSRFを防御します。追加の防御手段としては、重要な操作に対して再認証を要求することや、クッキーにSameSite属性を設定してクロスサイトリクエストと共に送信されないようにすることが含まれます。これらの保護機能を開発ライフサイクルに組み込むことで、システムが正当かつ意図的な操作のみを処理する可能性を大幅に高めることができます。

安全でない認証

安全でない認証ユーザーの身元を確認するプロセスが脆弱、予測可能、またはその他の欠陥がある場合に発生します。これは、不適切なパスワードポリシー、安全でない認証情報の保存方法、または多要素認証（MFA）の欠如によって引き起こされる可能性があります。攻撃者は、ブルートフォース攻撃、資格情報スタッフィング、または送信中の暗号化されていない資格情報の傍受など、様々な方法でこれらの脆弱性を悪用できます。安全でない認証は、攻撃者にユーザーアカウント、管理制御、および機密データへの直接アクセスを許可する可能性があるため、深刻な影響をもたらします。一度侵入されると、システムをさらに侵害したり、貴重な情報を盗んだりすることが可能になります。

セキュリティコーディングは、強力なパスワード要件を適用し、保存された認証情報をハッシュ化およびソルト処理し、すべての認証交換にHTTPSなどの安全なプロトコルを使用し、MFAを統合して追加の検証層を提供することで、この脆弱性を解決します。また、開発者は認証システムが弱点ではなく強力な防御ラインとして機能できるよう、失敗試行を制限し、不審な活動を早期に検出するログインメカニズムを設計する必要があります。

従うべき6つのセキュアコーディング実践

セキュリティソフトウェアの構築は、単に脅威の存在を把握する以上の意味を持ちます。そのためには、検証済みのセキュリティコーディングプラクティスとパターンを学び、統合する必要があります。以下の技術は、セキュリティをすべてのプロジェクトの必須要素とするために開発者が実行可能なステップを提供します。

1.ユーザーアクセス制御の実装

前述のように、ユーザーアクセス制御とは、システムの各ユーザー役割に対する権限を定義し適用することを意味します。強力なアクセス制御は、権限のないユーザーが機密データを閲覧したり、記録を改ざんしたり、管理作業を実行したりすることを防止します。また、攻撃者はそのアカウントの権限のみを持つため、ユーザーアカウントが乗っ取られた場合でも被害を最小限に抑えられます。

効果的なユーザーアクセス制御のためには、身元を確認するための強力な認証が必要であり、 認証されたユーザーが要求された操作を実行する権限があるかどうかを確認するための権限チェックが続きます。アクセス制御の慣行を定期的に見直し、最小権限の原則に沿ってユーザーに操作実行に必要な最小限のアクセス権限を付与する必要があります。また、アクセス制御は定期的な監視を通じてシステムのポリシーとユーザーを最新の状態に保ち、監査を通じて異常な活動を迅速に発見します。

2.データ検証および削除

データを検証および削除するには、処理前にすべての入力が想定される形式、タイプ、パターンを満たしていることを確認し、その後データをクリーンアップして潜在的に危険なコンテンツを除去する作業が含まれます。信頼できるソースも侵害される可能性があるため、この慣行は外部ソースからのデータにも適用されるべきです。 したがって、検証されるまではすべての入力は信頼できないものとして扱う必要があります。検証および削除機能を開発プロセスに組み込むことで、インジェクション攻撃などの一般的な脅威に対するアプリケーションの回復力を維持できます。

3.現代語で文章を書いてください

セキュリティコーディングはコードの書き方だけに限定されません。そもそもセキュリティ上の欠陥が発生するのをより容易に防止できるツールや環境を選択することも重要です。多くの企業では最新言語への完全移行が現実的または効率的な選択肢ではない場合が多いですが、最新のプログラミング言語を少なくともある程度使用し、選択したすべての言語の最新バージョンを使用することでソフトウェアのセキュリティを改善できます。最新の言語とフレームワークは、一般的に優れたメモリ安全性、強力な型検査、一般的な脆弱性に対する組み込みの保護機能を提供します。例えば、RustやGoといった言語は安全性を念頭に設計されているため、従来の言語では発生しやすいバッファオーバーフローなどの問題を防止するのに役立ちます。

JavaやPythonなどの既存言語は、近代化やセキュリティ対策が難しい場合がありますが、最新のリリースに追従することで最新のセキュリティ機能を活用し、パフォーマンスを改善できます。多くの更新では既知の脆弱性が修正され、安全でない機能が廃止され、より安全なデフォルト設定が提供されます。

4.練習コードの難読化

コード難読化は、攻撃者がソースコードまたはコンパイル済みコードを理解、リバースエンジニアリング、または操作することを困難にするプロセスです。他のセキュリティ対策を代替するものではありませんが、アプリケーションのロジックや機密性の高いルーチンを侵入者から隠蔽することで、防御レベルを一段階高めます。難読化には、変数や関数の名前を意味のない識別子に変更したり、コードを理解しにくくする形で再構成するといった技術が含まれる場合があります。

目標は、攻撃者が脆弱性を見つけて悪用するために必要なコストと労力を増やすことです。セキュリティコーディングにおける難読化は、他の強力なセキュリティ対策と組み合わせて機能し、アプリケーションを攻撃対象として魅力の低いものにします。

5.コードスキャンおよびモニタリング

セキュリティコーディングの実践には、コードを積極的にスキャンし監視することも含まれます。静的アプリケーションセキュリティテスト（SAST）ツールは、デプロイ前にソースコードの既知の脆弱性を分析するのに対し、動的アプリケーションセキュリティテスト（DAST）ツールは、実行中のアプリケーションに悪用可能な欠陥があるかどうかをリアルタイムでテストします。両方のアプローチを組み合わせることで、問題を早期かつ継続的に特定できます。

開発中のスキャンに加え、本番環境での継続的なモニタリングの実装が重要です。これには、異常な活動に対する通知の設定、セキュリティイベントの記録、ランタイムアプリケーション自己防御（RASP）ツールを活用したリアルタイムでの攻撃の検知と遮断が含まれます。定期的な検査とモニタリングにより、開発中に脆弱性が発見された場合でも、深刻な被害が発生する前に迅速に対処できる可視性を確保できます。

6.セキュリティコーディング標準の文書化および実装

セキュリティコーディング標準を文書化するには、チームの手法を定義する明確なガイドラインを作成する必要があります。安全で保守しやすく、規制に準拠したコードの記述。これらの標準は、技術スタックに関連する一般的な脆弱性を解決する方法だけでなく、入力検証、エラー処理、暗号化の実践、セッション管理といったトピックも扱うべきです。

これらの標準を整備することで、ジュニアエンジニアからシニア設計者まで、すべての開発者が同一のセキュリティ原則に従うことが可能になります。これらの標準を教育および定期的な更新と組み合わせて活用することで、開発プロセスを最新のセキュリティ要件に適合させる有用なリソースとなります。

セキュリティコーディング標準およびフレームワーク

独自のコーディング標準を作成する際に支援が必要な場合は、以下の人気ガイドラインが役立つ可能性があります。このガイドラインは一般的な脆弱性を解決する様々な事例を扱い、コーディング作業を業界のベストプラクティスに合わせる方法を明確にするのに役立ちます。

OWASP セキュリティコーディングのベストプラクティス

OWASPは、開発者が最初から最後までセキュリティをコードに組み込むための最も広く知られた情報源の一つです。OWASP開発者ガイドや OWASPトップ10といった主要なセキュリティコーディングリソースを提供しています。OWASPのアプローチは非常に実践的であり、チェックリストや開発中に適用できるコーディングのヒントといった利点を提供します。

OWASPガイドラインに従うことで、プロジェクト全体でセキュリティコーディングの共通基準を確立し、チームを支援します。OWASPは新たな脅威ベクトルや攻撃手法を反映するため定期的に更新されるため、組織はこれを利用して新たなリスクに事前に対処できます。OWASPの原則をワークフローに適用することで、コード品質の向上、脆弱性の削減、広く受け入れられている業界ガイドラインへの準拠が可能になります。

NIST セキュリティソフトウェア開発フレームワーク

米国国立標準技術研究所（NIST）は、包括的なセキュリティコーディングガイドラインを発表します。広範なサイバーセキュリティフレームワーク。高度なセキュリティソフトウェア開発プラクティスに関する情報を提供するだけでなく、NISTセキュリティソフトウェア開発フレームワーク（SSDF）は、企業内のチーム間およびチーム間の主要な課題に関するコミュニケーションを改善する共通語彙を提供します。特定の技術よりも結果に焦点を当てるため、OWASPやSEI CERTコーディング標準などの他の標準を補完するのに最も適しています。

SEI認証書コーディング標準

ソフトウェア工学研究所（SEI）のCERT部門が開発しました。SEIのコーディング標準は、C、C++、Java、Perlなどの特定プログラミング言語におけるセキュリティ脆弱性の防止に重点を置いています。各言語ごとの標準には、セキュリティコーディング規則、詳細な説明、準拠コードと非準拠コードの例が含まれています。CERTコーディング標準は特定プログラミング言語の微妙な差異や弱点を扱うため、その環境で作業する開発者にとって非常に有用かつ実践的です。

マイクロソフト セキュリティ開発ライフサイクル

マイクロソフトのセキュリティ開発ライフサイクル（SDL）は、セキュリティをソフトウェア開発プロセスの不可欠な要素とするために設計された一連のベストプラクティスです。これには以下の推奨事項が含まれます。10の重要テーマこれには脅威モデリング、開発者向けセキュリティ教育、ソフトウェアサプライチェーンセキュリティが含まれます。マイクロソフトはこのアプローチを自社で採用しているため、組織は開発者、テスター、セキュリティチームを調整する実証済みのプロセスを活用できます。

ISO/IEC 27001

ISO/IEC 27001は情報セキュリティマネジメントシステム（ISMS）の標準として最もよく知られていますが、セキュリティコーディングにも大きな影響を与えます。組織レベルのISMSの確立に重点を置いていますが、これにはセキュリティコーディング原則が含まれます。これらの推奨事項は、組織がセキュリティコーディングの実践を導入する際に従うことができる高水準の指針を提供します。

AIセキュリティルール

AIコーディングツールはかつてないほど便利ですが、安全で正確なコードを作成できなければ、メリットよりもデメリットの方が大きくなる可能性があります。Secure CodeWarriorのAIセキュリティルール——業界初の製品 ——は、GitHub Copilot、Cline、Cursor、WindsurfなどのAIツールと併用可能なセキュリティコーディングのベストプラクティスを提供します。これらのルールは、安全でないコードのリスクを最小化するガードレールを設け、AIコーディングアシスタントの行動を監視できるようにします。

最初からセキュリティコードを作成する方法を知る

セキュリティコーディングは単なる技術的要件ではなく、重要なビジネス上の利点です。チームが最初から安全なコードを書くことで、コストのかかる脆弱性を予防し、データ侵害のリスクを低減し、顧客が信頼できるソフトウェアを提供できます。しかし体系的な指針がなければ、セキュリティコーディングの実践を習得することは特に困難です。開発者には、実際の事例、進化する脅威に関する最新の知識、そしてすべてのコード行にセキュリティ原則を自信を持って適用する方法が必要です。

Secure Code WarriorのISO 27001認証およびSOC2準拠アジャイル学習プラットフォームは、まさにその点をチームに提供します。言語別のセキュリティベストプラクティス、現実的なコーディング課題、多様な役割向けにキュレーションされたコンテンツを通じた教育により、セキュリティを後付けの考慮事項から脱却させ、開発プロセスの自然な一部へと転換します。開発者は脆弱性を早期に特定・修正し、 業界標準に準拠し、ソフトウェア開発ライフサイクル全体を通じてコードセキュリティに対する完全な所有権を持つ技術を構築します。Secure Code Warriorを利用する企業がソフトウェア脆弱性を53%削減し、最大1,400万ドルのコスト削減を実現し、開発者の92%が追加トレーニングを希望していることは驚くべきことではありません。

チームが初日からより安全で堅牢なコードを書く方法を知りたいなら、今すぐセキュアコードウォリアーのデモを予約してください。

セキュアコードウォリアーでは、開発者と組織が今日の絶えず変化するセキュリティ課題に対処するための適切なスキルを身につけられるよう、絶えず革新を続けています。私たちは、セキュリティコーディングのためのアジャイル学習プラットフォームを通じてこれを実現します。これにより、開発者は業界で最も包括的で信頼性の高い脆弱性コンテンツを通じて、自身の望む方法で学習できます。

前四半期、Secure Code Warriorは、管理者がSCIMプロビジョニングを通じてユーザーをより簡単に管理できるだけでなく、トーナメントを複数のブランドや組織に拡張できる新たな方法を実装しました。また、Jiraで新しいコーディングガイドラインとパフォーマンス概要レポート、そして新しいプログラムワークフローをプレビューできるようになったことを発表でき、大変嬉しく思います。

詳しく見ていきましょう！

SCWプラットフォームの幅と深さの拡大

Secure Code Warriorは、新しいコンテンツを継続的に追加することで、今日のサイバーセキュリティ環境で知っておくべき事項に合わせてモジュールを関連性が高く、タイムリーでカスタマイズされた状態に保つのに役立ちます。60以上の言語で業界最高の幅と深さを提供するため、多くの言語やフレームワークにおいて、開発者向けのアジャイル学習プログラムを容易に構築・拡張できます。

現在利用可能: Jiraのコーディングガイドライン

Jira統合にガイドラインを追加すると、開発者向けにセキュリティ緩和策を扱う状況に応じた学習が提供されます。ガイドラインは動画よりも詳細で、特定の言語やフレームワークに焦点を当て、開発者が問題をより迅速に解決できるよう支援するコードスニペットを提供します。開発者は動画やチャレンジにアクセスできるだけでなく、Jira課題から直接コーディングガイドラインを読み、詳細な改善アドバイスを得られるようになりました。

現在利用可能：新しいフロントエンド開発者向けコンテンツ

フロントエンド開発者にも安全なコードのサポートが必要です！これが、私たちがミッションやワークスルーにフロントエンドの脆弱性を追加で公開した理由です。また、フロントエンド開発者はコースを通じてフロントエンド関連のミッションにアクセスできます。

これらのアップデートは、DOMベースのXSSのような一般的な脆弱性から、CSSインジェクションのように頻発しない脆弱性まで、フロントエンド固有の脆弱性を包括的にカバーするよう努めています。段階的な演習はフロントエンド開発者に脆弱性が悪用される方法に関する信頼できる指針を提供し、上級開発者はトーナメントのフロントエンドミッションで自身の技術をテストすることもできます。

セキュリティ文化を拡大する興味深く新しい方法

現在利用可能：複数企業のトーナメント

‍

複数の企業トーナメントを開催し、様々な事業体、会社の子会社、パートナー、および他社の開発者間で友好的な競争を促すことができます。これにより、セキュアコーディングの文化が組織全体および複数のブランドに拡大されます。

究極のマルチカンパニートーナメントに参加してみませんか？第3回年次デブリンピックに登録する-サイバーセキュリティ啓発月間に向けたSCWのグローバルトーナメント！既に顧客の方は、プラットフォームを通じて登録できます。

管理者および開発者の体験を簡素化

現在利用可能: コースフィルタリング

コース管理ページでは追加フィルターを適用できるため、管理者は作業対象のコースをはるかに簡単に絞り込めます。状態、終了日、登録チームなど、複数の属性でコースをフィルタリングできます。

現在利用可能: SCIMでSCWライセンスを管理しましょう

プログラム所有者と企業管理者は、大規模な開発者をプログラムによって管理できるようになり、アクセス制御が常に最新の状態であるという確信を持てます。

SCIMプロビジョニングは、IDプロバイダーを使用してSecure Code Warriorへのアクセスを同期します。これらの操作を自動化することで、正確性、セキュリティ、およびコンプライアンスが保証され、ユーザーのプロビジョニング時に時間とリソースの両方を節約できます。現在、SCWはユーザーレベルでのみSCIMプロビジョニングをサポートしており、SCIMグループはまだサポートしていません。

プレビューとして提供: プログラムワークフロー

 プラットフォームの主要なユーザビリティ改善により、拡張性が高く参加意欲を高めるセキュリティコード教育プログラムを構築することがこれまで以上に容易になりました。プログラムは、コースと評価を段階的なプログラムとして順序立てて分類し、学習者により多くのガイダンスを提供するために設計されています。プラットフォームでプレビューを有効化したお客様は、自動化されたプログラムワークフローを利用できるようになりました。プログラムワークフローを通じて、開発者はどこから始めるべきかを把握し、 次のステップへ移行し、安全なコード学習プログラムを通じて様々な段階を容易に進めることができます。また、企業管理者はプログラムの設定・管理に要する時間を削減し、開発者が次の学習活動を完了するよう促すことが可能になります。

組織でセキュリティコードの学習を始める方法に関するヒントが必要ですか？こちらをお読みください。ハンドブックでは、セキュリティ目標を達成するためにプログラムを構成する方法について説明しています。

レポートおよびプログラムインサイト

プレビューとして提供: 性能概要

組織全体の活動を監視することは、開発者の参加状況を把握し、セキュリティコード学習プログラムの成功度を測定する上で極めて重要です。管理者がレポートから最も実用的な知見を得られるよう、強化されたレポートインターフェースを構築しました。

性能概要は、時間の経過に伴う平均精度とともに、開発プロセスおよび評価完了に関する洞察を提供します。また、レポートは選択した評価の業界平均評価スコアとプログラムがどのように比較されるかを確認できる、洞察に富んだ業界ベンチマークを提供します。

簡潔でありながら強力なこのレポートは、2024年に計画されているSecure Code Warriorのインサイトおよび指標セットの開始を告げるものです。

セキュアコードウォリアーをお試しになりたいが、まだアカウントをお持ちでないですか？今すぐデモを予約して詳細をご確認ください。

これで今四半期の新しい機能の紹介を終了します！Secure Code WarriorをフォローしてくださいLinkedInおよびX（旧Twitter）で最新リリースと改善点に関する更新情報を受け取れます。

‍

‍

企業や製品に関係なく、世界は急速に変化しています。ますますデジタル化が進み、ソフトウェアへの依存度が高まっています。開発者はかつてない速さでコードを提供していますが、AppSecチームは依然としてコードの75%を検査し、一般的で簡単に予防可能な脆弱性を発見しています。

ソフトウェア開発プロセスにおいて、セキュリティコードやセキュリティを優先しない場合、重大なリスクが生じます。実際、過去1年間におけるデータ侵害による世界平均コストは435万ドルに増加しました（IBMデータ侵害コストレポート2022）。開発者は新たな脅威や文化の変化に対応するため、セキュリティチームとの連携を通じて残されたセキュリティ中心の考え方を変革する、参加型で革新的な教育が必要です。

セキュアコードウォリアーでは、開発者と組織が今日の絶えず変化するセキュリティ課題に対処するために必要な適切なスキルを身につけられるよう、絶えず革新を続けています。私たちは、参加型で柔軟性があり、管理しやすい教育プログラムを通じてこれを実現します。

前四半期には、コーディングラボ（プレビューで新たに提供開始）を通じて新たな学習方法を構築し、LMS SCORM統合を活性化し、よりアクセスしやすく包括的なユーザー環境の構築に注力しました。同時に管理環境を簡素化し、時間の節約を実現しました。

詳しく見ていきましょう！

コーディングラボ発表 — 一歩進んだ学習

最近の業界調査（開発者主導セキュリティ現状レポート2022）では、40%の開発者が実践が不十分だと回答しました。Coding Labsは、親しみやすく強力なブラウザ内IDEで、実際のコーディングと直感的なフィードバックを含む実践的なトレーニングを通じて、開発者がセキュリティコーディングスキルを向上できるよう支援します。これにより、学習から実践への移行がこれまでよりもはるかに容易になります。

開発者は、明確でなくもどかしい「正しいか間違っているか」という指示を受ける代わりに、自分が正しい方法を学んでいるという確信を持ち、リアルタイムかつ状況に応じたフィードバックを通じて理解を深めることができます。Coding Labsは、セキュリティ脆弱性を予防し、組織のセキュリティ態勢を改善しようとする開発者の目標を支援します。

SCWプラットフォームの一部であるこの新たな体験は、開発者支援に新たな視点をもたらします。リーダーは、開発者がいる場所で、彼らに適したアクセスしやすくシンプルな学習を通じて、成功へと導く教育プログラムを構築できます。アクセスしやすいガイド付きトレーニングで新たな課題を克服し、コーディングラボのようなより挑戦的で実践的な体験へと人々を導きましょう。リーダーは、開発者が学習をより興味深く容易に継続し、最終的にコードベースに適用することで脆弱性と手戻りを削減できると確信できます。

コーディングラボはプレビュー版で利用可能になりました。SCWのお客様は、アクセス方法の詳細についてアカウント管理者にお問い合わせください。

SCWのお客様ではありませんが、コーディングラボの利用状況に関する最新情報をご希望ですか？こちらからフォームにご記入ください。

SCWに参加して製品革新について学び、コーディングラボのデモをご覧ください。ウェビナーはこちらから登録してください。

SCORM LMSと統合し、セキュリティコード教育を優先してください

まもなくリリース予定のSCWマネージャーは、手動での開発作業なしに、他の教育プラットフォームと連携してセキュリティコード教育プログラムをより簡単に管理できます。これにより時間を節約でき、管理者は教育プログラムを改善するためのより効果的な方法に集中できるようになります。

SCORMとは、共有可能なコンテンツオブジェクト参照モデルを意味します。 e-コースの国際標準です。講座がSCORM形式で公開されている場合、ほぼすべてのLMS（学習管理システム）で認識できます。

新しいSCORM LMS統合により、以下のことが可能になります。

• セキュリティコード教育を優先するLMSに直接統合することで、参加者と課題を1か所で管理できます。
• 組織の進捗状況および完了状況を追跡してください

‍

SCWプログラムが開発者のワークフローに直接組み込まれていることを確認し、ユーザーエクスペリエンスを向上させてください。教育コースおよび評価用のSCORMパッケージをダウンロードすることで、SAP SuccessFactors、Workday、Cornerstoneなどの人気プラットフォームやLMSとシームレスに統合できます。

お客様は10月にLMS SCORM統合をプレビューできます。詳細はアカウント管理者にお問い合わせください。

SCWプラットフォームの幅と深さの拡大

セキュアコードウォリアは、新たなコンテンツを継続的に拡充することで、今日のサイバーセキュリティ環境において知っておくべき事項に合わせてモジュールを関連性が高く、タイムリーでカスタマイズされた状態に保つのに役立ちます。55以上の言語で業界最高水準の幅と深さを提供するため、多くの言語やフレームワークで開発者を教育するプログラムを容易に構築・拡張できます。

新たにリリースされた教育コンテンツによるABAPアプリケーション保護

基盤構築の解放春には、6つの新しいワークスルーと14のミッションを通じて、ABAPでコーディングする開発者向けの新しい教育方法をリリースできることを嬉しく思います。

柔軟で多様な教育を利用でき、新たな課題とコンテンツが含まれています。

Secure Code Warriorは、教育モジュールの関連性と挑戦性を維持しつつ、様々な技術レベルに対応するコンテンツを継続的にリリースするよう努めています。今四半期、SCWは以下の人気コーディング言語向けにさらに多くのコンテンツをリリースしました。

• 33の追加RPGチャレンジ、最も多くの顧客リクエスト
• RPGでトーナメントを作成する機能
• 10の追加Python Djangoチャレンジ

すべての新しいコンテンツを、チャレンジプールからプラットフォームでプレイできるようになりました。

管理者およびユーザー体験の簡素化

プラットフォームの主要なユーザビリティ改善により、拡張性が高く参加率の高いセキュリティコード教育プログラムを構築することが、これまで以上に容易になりました。

公開された講座を手軽に編集

既存プログラムを編集する新しい方法を使用して、組織や教育プログラムの絶えず変化する要件に対応してください。管理者はコースバージョン管理を通じて、新たにコースを作成することなく既存のコースを修正できます。この機能はお客様から最も多くリクエストされていた機能の一つでした。

アップデートには以下が含まれます。

• 公開された講座に新しい言語を追加
• コースのモジュールおよび活動コンテンツの追加/更新/削除
• 教育課程終了活動追加/更新/削除
• プラットフォームは、基本バージョン管理を作成するためにコースのメジャーバージョンを保存します。

ホーム画面からコースにアクセスする

新しいホームページに「続行」ボタンを追加すると、ユーザーが以前に開始したモジュールを素早く再開できるよう、アクティビティカードの一覧が表示されます。また、ユーザーはホーム画面で未完了のモジュールを確認できるウィンドウを表示できるようになりました。

これにより、ユーザーは講座や評価を一時停止する必要がある場合でも、進捗状況を失うことなく中断した箇所から効果的に再開できます。

‍

両方の機能は、プラットフォームで早期アクセスを有効化したアカウントで利用できます。アクセスに関して不明な点がある場合は、アカウント管理者にお問い合わせください。

包括的でアクセシビリティに優れたデザイン

セキュアコードウォリアーでは、言語とデザインがセキュアコーディングを推進するという私たちの使命のもと、多様なユーザーグループをつなぎ理解を深める力を持っていると信じています。私たちの目標は包括的でアクセスしやすい体験を創り提供することであり、アクセシブルなデザインへの継続的な進化を実現できることを嬉しく思います。

中国語（繁体字）が使用可能になりました

プラットフォーム言語に中国語（繁体字）を追加することで、私たちはセキュリティのチャンピオンとなるために必要なツールにアクセスできる真にグローバルな開発者コミュニティを継続的に構築しています。

設定のドロップダウンメニューから言語にアクセスできます。リソースセクションでは、ビデオ字幕とともに中国語（繁体字）も利用可能です。

2022年10月5日に開催されるプロダクトトークウェビナーにご参加ください。

さらに詳しく知りたいですか？2022年10月5日に開催されるProductTalkウェビナーに参加し、製品チームメンバーによる興味深いアップデートや新機能についての話を聞き、変化する開発者中心のセキュリティ環境について学びましょう。

ウェビナーに登録する こちら.

セキュアコードウォリアーをお試しになりたいが、まだアカウントをお持ちでないですか？今すぐ登録してください 無料トライアルアカウント 今日始めましょう。

これで今四半期の新しい機能の紹介は以上です！フォローして、 TwitterのSecure Code Warriorの最新リリースや改善点に関する更新情報を受け取ってください。

安全でないコードは企業に数百万ドルの損失をもたらします。では、セキュリティコーディングの実践を採用する妨げとなるものは何でしょうか？

ほとんどすべてがソフトウェアに依存する世界では、コードの安全性を確認することが 非常に重要です。ブランドの評判と財務上の存続は、この点にかかっています。とはいえ、セキュリティコーディングに関する懸念は多いものの、完全かつ効果的な採用には多くの障壁があります。これまで以上に新しい作業方法が必要です。そこで 2020 年、Secure Code Warrior は Evans Data Corp. と提携し、セキュリティコーディング、セキュリティコードの実践、およびセキュリティ運用に関する開発者と管理者の意識に関する一次調査* を実施しました（ホワイトペーパーのダウンロード）。 こちら）。

現在の組織では、セキュリティコードプラクティスを実装することが難しいことを認識しています。開発者と管理者の双方が脆弱性に対処し、特に懸念されるコードに対して責任を負う必要があります。

より優れた教育とセキュリティコードプラクティスを支援するプログラムが明らかに必要です。開発者と管理者にセキュリティコーディングに関する懸念を尋ねると、この必要性が明らかになります。当社の調査*によれば、この2つのグループは同じ基本的な関心事を共有していることが示されました。しかし役割が異なるため、どちらが最も差し迫った問題であるかについては見解の相違があります。

開発者にとって最大の関心事は「過去の脆弱性を再現するコードの混入」です。開発者はコードの品質で評価されるため、これは驚くべきことではありません。いかなる開発者も、安全でないコード、つまり再作業が必要でチームの作業速度を低下させるコードの根源となることを望みません。

開発者が二番目に重要視するのは、同僚が犯したミスに対処することです。納期を守ることやコードに対する責任を負うことも同様に上位に位置付けられています。セキュリティコードを学ぶことが難しいという事実も、セキュリティコード教育に対する新たなアプローチが必要であることを改めて示しています。

一方、管理者はよりトップダウンの視点を取る傾向があります。

チーム管理者でありリーダーとして、彼らが最も重要視しているのはコードに対する責任です。チームで質の低いコードが作られると、問題はマネージャーに押し付けられます。

既存の脆弱性を複製するコードが二つ目です。学習プロセスが煩雑であるという事実が三つ目に挙げられます。現行のセキュリティコード教育アプローチが適切に機能しない場合、管理者は新たなアプローチが必要だと認識します。

セキュリティコーディング慣行の採用における障壁

管理者に組織内でセキュアコーディングの実践が採用される際の障壁について尋ねたところ、特に目立つ二つの課題が浮かび上がりました。それはコミュニケーションと教育です。

45%は利害関係者とのコミュニケーション不足を深刻な障害と指摘しました。42%は新入社員のセキュアコーディング技術不足を嘆いています。同時に40%は 教育時間とリソースが不足していると回答しました。

組織全体でセキュリティコード慣行を成功裏に導入するには、プロセスおよび人事関連の障壁が存在します。

しかし、こうした扱いにくい問題にもかかわらず、依然として進展は可能です。新入社員のセキュリティコーディング技術の不足と不適切な教育・リソースは、解決がより容易です。

開発者は脆弱性を防ぐために最前線で戦っています。しかし、セキュリティ契約において各自の役割を果たすための支援、ツール、教育は受けているのでしょうか？

彼らの懸念によれば、簡潔な答えは「いいえ」です。

実際、正しい教育は講義のように感じられるべきではありません。

セキュリティコーディングの変革を主導するSecure Code Warriorは、開発者がセキュリティコーディング技術を学び習得できるよう、積極的に参加させる人間主導型のアプローチを採用しています。当社の実績ある学習プラットフォームは、開発およびセキュリティチームが好むワークフロー内で、状況に応じた極めて関連性の高い学習を提供します。脆弱性を見つけるだけでなく、そもそも脆弱性が発生しないように防止できます。

この種の実務教育は技術を向上させる機会です。つまり、脆弱性を防ぎ、他のチームメンバーと協力してより高水準のコードを作成するために真剣な努力を払う開発者にのみ、肯定的な影響を与えることができます。

セキュリティを侵害することなく、セキュリティコードを「ゼロから構築」し、より迅速にリリースできるチームの能力に及ぼす潜在的な影響について詳しく知りたい場合は 今すぐデモを予約してください.

*対応から予防への転換：アプリケーションセキュリティの変容する姿。セキュアコード・ウォリアー＆エバンズ・データ・コーポレーション 2020

BSIMM 8が発表されました！素晴らしいですね。大企業がセキュリティソフトウェアを開発する際に採用しているセキュリティ慣行に関する唯一の大規模な研究です。

本研究はGary McGrawの監督のもと、アプリケーションセキュリティ専門家によって実施され、収集されたデータの一貫性と正確性を確認するとともに、30万人の開発者が日々行う作業に関する洞察を提供します。最近のプレゼンテーションではBSIMMの数値が参照されましたが、ここで言及されたBSIMMの数値によれば、開発者100人あたり平均2人のアプリケーションセキュリティ専門家が存在します。

しかしBSIMM4以降はそうではありませんでした。BSIMM8レポートによると、この数値はそれよりもはるかに少なく、現在は開発者100人あたり1.6人です。人材が不足しているため、アプリケーションセキュリティの専門家をさらに雇用しても効果はありません。私たちはこれまで以上に、開発者に組織内で直接使用でき、拡張可能なセキュリティコードを書くためのツールと教育を提供すべきです。

また報告書によると、教育実践において最も一般的な活動は、全従業員に対する認識向上トレーニングの提供である（67%）。Secure Code Warrior SCW）が実施する作業を教育実践にマッピングし始めたところ、このソリューションにより教育実践においてレベル1（大半の企業で実施）からレベル3（ごく少数の企業）に至る12の活動を全て実行可能であることが判明した。

全体の実習で使用できる単一ソリューション！12の教育事例の中で、セキュアコードウォリアーソリューションに関する最も興味深い事例は以下の通りです。

• レベル1：認識教育の提供
• レベル1: オンデマンド個別教育の提供
• レベル2: 訓練による衛星能力の向上（SCWメトリック）
• レベル3: カリキュラムを通じた報酬の進捗 (SCWバッジ)
• レベル3：サプライヤーまたは外部委託作業者向けの教育提供（SCW評価）
• レベル3: 外部ソフトウェアセキュリティイベントのホスティング（SCWトーナメントモード）
• レベル3：訓練による衛星識別（SCWメトリック）

現在使用中のソリューションがこれらの慣行を解決すると確信していますか？

11月初旬、ケンブリッジ大学は「 トロイの木馬-ソース」と題する 研究を発表しました。この 研究は、方向性書式指定文字を用いてソースコードやコメントにバックドアを隠蔽する手法に焦点を当てています。これにより、コンパイラが人間のコードレビュー担当者と異なる方法でロジックを解釈するコードを生成することが可能となります。

以前、Unicodeがファイルの実際の拡張子を隠すなど悪用された事例はあったものの、この脆弱性は新たに発生したものです。ファイル名の末尾部分の方向転換。最近の研究によれば、多くのコンパイラは警告なしにソースコード内のユニコード文字を無視する一方、コードエディタを含むテキストエディタはこれに基づいてコメントとコードを含む行を再配置（リフロー）することが可能です。したがってエディタは、コンパイラが解析する方法とは異なる順序でコードとコメントを表示することができ、コードとコメントを交換する場合でも同様です。

詳細を知りたい場合は読み進めてください。またはトロイの木馬ソースのハッキングシミュレーションを試してみたい場合は、無料で提供されているサービスにすぐにアクセスしてみてください。公共任務を直接体験してください。

双方向テキスト

これらのトロイの木馬攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用します。このアルゴリズムは、英語（左から右）やアラビア語（右から左）のように表示順序が異なるテキストの整列方法を処理します。方向書式指定文字を使用してグループを再構成し、文字の順序を表示することができます。

上記の表には攻撃に関連する一部のBidiオーバーライド文字が含まれています。例えば、

RLIe d o cPD

略語RLIは以下を表します。右から左への分離。テキストをコンテキスト（PDIで区切られる）から分離します。ポップディレクショナルアイソレート）をクリックし、右から左へ読みます。結果は次の通りです。

C O D E

しかしコンパイラとインタプリタは通常、ソースコードを解析する前に、Bidiオーバーライドを含む書式制御文字を処理しません。方向性書式指定文字を単に無視すると、次のように解析されます。

E D O C

新しい瓶に入った古いワイン？

もちろんこれは太陽の下で新しいことではありません。過去には方向指定文字が使用されていました。ファイル名に挿入され、その悪意のある性質を隠すためです。「myspecialexe.doc」と表示されたメール添付ファイルは、RLO（右から左へのオーバーライド）がなければ十分に無邪気に見えたかもしれません。実際の名前が「myspecialcod.exe」であることを示す文字の贈り物でした。

トロイの木馬ソース攻撃は、ソースコード内のコメントや文字列に方向指定文字を挿入します。これらの制御文字は、構文エラーやコンパイルエラーを引き起こさないためです。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るようにします。

例えば、次のバイトを順に含むファイル:

方向指定文字ごとに以下のように再配置されます。

方向指定文字が明示的に呼び出されていない場合、コードは次のようにレンダリングされます。

RLOは最後の行で閉じる中括弧を開く中括弧に反転し、その逆も同様です。このコードを実行すると、次のような結果が出力されます。「あなたは管理者です。」管理者チェックはコメントアウトされていますが、制御文字を見ると、そのチェックが依然として存在していたという印象を与えます。

(出典: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)

これは皆様にどのような影響を与える可能性があるでしょうか？

C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど多くの言語が攻撃に対して脆弱であり、 さらに多くの言語が攻撃に脆弱であると推定されます。一般の開発者はソースコード内の方向指定文字を見て眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えない方が良いかもしれません。さらに、これらの文字の可視化はIDEによって大きく異なるため、発見される保証はありません。

しかし、そもそもこの脆弱性はどのようにソースコードに潜入できたのでしょうか？何よりもまず、信頼できないソースからのソースコードを使用する際、悪意のあるコードの混入が気づかれないまま発生する可能性があります。第二に、インターネットで見つけたコードをコピー＆ペーストするだけで、このような事態が起こり得ます。 私たちの開発者のほとんどが過去に経験したことでしょう。ほとんどの組織は複数のベンダーのソフトウェアコンポーネントに依存しています。これにより、このコードをどの程度信頼し、依存できるかという疑問が生じます。隠されたバックドアを含むソースコードをどのように選別できるでしょうか？

誰の問題でしょうか？

一方、コンパイラとビルドパイプラインは、一方向が文字列やコメントで厳密に制限されていない限り、複数の方向を持つソースコード行を許可すべきではありません。なお、文字列やコメントの方向指定文字は、ポップされない場合、行末まで方向変更を延長できます。一般的にコードエディタは、ホモグリフや方向指定文字など疑わしいユニコード文字を明示的にレンダリングし強調表示すべきです。11月からGitHubは、双方向ユニコードテキストを含む全てのコード行に警告記号とメッセージを追加します。 ただし、これらの文字の行位置は強調表示されません。これにより、悪意のある方向変更が依然として潜入する可能性があります。

開発者とコードレビュアー間の認識は不可欠であるため、脆弱性を説明するガイダンスを作成しました。現在この練習はJava、C#、Python、GO、PHPで利用可能です。

より詳しく知りたい場合は、当社の製品をお試しください。トロイソースシミュレーション（公開ミッション）、そしてトロイソースリサーチをお読みください。

Javaシミュレーション

C#でのシミュレーション

PHPでのシミュレーション

GOでのシミュレーション

Pythonでのシミュレーション

静的解析とは？

静的解析とは、アプリケーションを実行せずにソースコードを自動的に解析することです。

プログラムの実行中に分析を実行する場合、これを動的解析と呼びます。

静的解析は主に以下の検出に使用されます。

• セキュリティ脆弱性。
• 性能問題。
• 標準に準拠していません。
• 古いプログラミング構造の使用。

静的解析ツールはどのように動作しますか？

すべての静的解析ツールに共通する基本概念は、ソースコードを検索して関連する警告や情報を持つ特定のコーディングパターンを識別することです。

これは「JUnit 5のテストクラスは'public'である必要はありません」のように単純な場合もあります。あるいは「SQL実行文で使用される信頼できない文字列入力」のように特定が複雑な場合もあります。

静的解析ツールはこの機能を実装する方法が異なります。

• 抽象構文木（AST）を生成するソースコード解析技術
• テキスト正規表現マッチング
• 上記の組み合わせです。

正規表現によるテキストの一致は非常に柔軟で、一致ルールを記述しやすいですが、しばしば多くの誤検出につながり、一致ルールは周囲のコードコンテキストを無視します。

ASTマッチングはソースコードをテキストで埋め尽くされたファイルだけでなくプログラムコードとして扱うため、より具体的かつ状況に応じたマッチングが可能となり、コードに対して報告される誤検知の数を減らすことができます。

継続的インテグレーションにおける静的解析

静的解析は、継続的インテグレーション（CI）プロセス中に頻繁に実行され、コンプライアンス問題に関するレポートを生成します。このレポートをレビューすることで、時間の経過とともにコードベースを客観的に把握することが可能になります。

一部のユーザーは、静的解析ツールを特定のコード部分のみを測定し、ルールのサブセットについてのみ報告するように構成し、コード品質の客観的な尺度として使用します。

時間が経ってもコード評価が変わらないため、使用されたルールに基づいて客観性が保証されます。明らかに使用されるルールとその構成を組み合わせることは主観的な決定であり、チームごとに時期に応じて異なるルールを使用することを選択します。

CIで静的解析を実行することは有用ですが、プログラマーへのフィードバックが遅延する可能性があります。プログラマーはコーディング時にフィードバックを受けず、後で静的解析ツールを通じてコードを実行する際にフィードバックを受けます。CIで静的解析を実行する際の別の副作用は、結果を無視しやすいことです。

チームが静的解析の結果により多くの注意を払えるよう、指標が超過した場合（例：トリガーされたルール数）にビルドを失敗させるよう、ビルドプロセスで閾値指標を設定することが一般的に可能です。

IDEにおける静的解析

多くのIDEプラグインは、フィードバックをより早く得るために、必要に応じて、またはコードが変更されたときに定期的に静的解析ルールを実行します。

すると、プログラマーがコードを書く際にIDEでルール違反を確認できるようになり、ルールを無視しにくくするために、エディタで違反をアンダーライン付きのコードとして表示されるように設定できます。

個人的には、これがコーディングを改善するのに有用な方法だと考えています。特に静的解析ツールが扱う新しいライブラリで作業する際にはなおさらです。ただし、誤検知や関心のないルールによって「ノイズが多くなる可能性」はあります。しかしこの問題は、追加の手順を実行して特定のルールを無視するよう静的解析ツールを構成することで解決されます。

静的解析ルールに基づくコード修正

ほとんどの静的解析ツールでは、ルールの修正はプログラマに委ねられているため、プログラマはルール違反の原因と修正方法を理解する必要があります。

違反事項を修正できる機能を備えた静的解析ツールはほとんどありません。修正はチームや使用された技術、合意されたコーディングスタイルによって決定される場合が多いためです。

基本ルール

静的解析ツールが基本ルールと共に提供される場合、ルールの品質に対する誤った確信が生まれる可能性があります。プログラマーが直面し得るあらゆる問題と、そのルールが適用されるべきあらゆる状況を網羅していると信じがちです。時にルールを適用すべき状況は微妙で、検知しにくい場合があります。

静的解析ツールを使用してルールと違反事項をより詳細に調査することで、プログラマーが特定の領域の文脈において問題を検知し、防止する技術を開発できることを願っています。

ドメインにコンテキストルールが必要な場合、静的解析ツールにはドメインやライブラリに一致するルールが存在しない可能性があり、またツールの構成や拡張が困難になる場合があります。

煩わしさ

こうした「煩わしさ」の中で、克服できないものはありません。

• 誤検知
• 修正事項不足
• 規則を無視するための構成
• コンテキスト別のルール追加

しかし、そもそも静的解析ツールを使用しないための言い訳として使われるケースが多く、静的解析を活用すれば以下のような方法で非常に有用になり得るため、残念です。

• ジュニア開発者向けのより良いアプローチの強調
• 明確なコーディング違反に対する迅速なフィードバックの確保
• プログラマーがこれまで経験したことのない曖昧な問題を特定します。
• プログラマーが正しいコーディング手法を採用していることを強調してください（違反事項が報告されていない場合）

IDEベースの静的解析ツール

プロジェクトの個人貢献者として、私はIDE内で実行される静的解析ツールを好んで使用しています。これにより、コードに対するフィードバックを迅速に得ることができます。

これはプロジェクトに存在する可能性のあるすべてのプルリクエストレビュープロセスとCI統合を補完します。

私は優位性を得られるツールを探し、個人のワークフローを改善しようと努めています。

ツールがIDE上で実行される場合、デフォルトのGUIと構成へのアクセス方法が同じであるため、ツールを切り替えて確認したくなるかもしれません。

ツールには重複する機能やルールセットが含まれる場合がありますが、利点を最大限に活用するために複数のツールを導入し、それぞれの強みを活用します。

コーディング時に積極的に使用する静的解析IDEツールは以下の通りです。

• IntelliJ内蔵検査 - 一般的なコーディングパターン
• スポットバグ - 一般的なエラー
• ソナリント - 一般的な使用パターン
• チェックスタイル - 一般的なスタイルパターン
• Sensei カスタムルールの作成

互いに良く調和し、互いを補強し補完するため、全て使用します。

IntelliJ Inspection

IntelliJを使用している場合、すでにその検査を使用しています。

これはIDEでフラグが設定された静的解析ルールです。これらのうち一部には、問題を解決するためにコードを書き換えることができるクイックフィックスオプションも含まれています。

ルールを設定または解除でき、IDEで強調表示する際に使用するエラーレベルを選択できます。

優れたIntelliJ検査機能が多数存在します。この記事を執筆する過程でその内容を全て読み込んだため、私はそれを知っています。IntelliJ Inspectionsはデフォルトで有効化されており、まだ設定は行っていません。しかし検査機能を最大限活用するには、検査項目を注意深く読み込み、自身のコーディングスタイルに関連する項目を特定し、警告レベルを調整してコード内で確認できるようにする必要があります。

IntelliJ Inspectingの良い点は、IDEと共に無料で提供され、以下のような筋肉記憶を構築するのに役立つことです。

• コードを記述する際にソースの警告およびエラーを確認する
• フラグが設定されたコードの上にマウスを置くと、ルール違反の有無を確認できます。
• Alt+Enter キーを使用して問題に対するクイックフィックスを適用します。

スポットバグ

TheSpot BugIntelliJプラグインは、静的解析を使用してコードのバグを通知します。

IntelliJの基本設定でSpotBugsを構成してコードをスキャンできます。使用された実際のルールはDetectorタブで確認できます。

私はコードを記述しレビューした後、SpotBugsを使用する傾向があります。その後、「テストソースを含むプロジェクトファイルの分析」を実行します。

このようにすることで、バグ、デッドコード、および明らかな最適化を特定するのに役立ちます。また、報告された違反事項の一部を調査し、どのような措置を取るべきかを判断するのに役立てなければなりません。

SpotBugsは問題を検出しますが、問題を解決するためのQuickFixタスクは提供しません。

SpotBugsは設定が容易で、私のIDE内で参照できる客観的なセカンドオピニオンだと考えています。

ソナ・リント

ザ・ソナ・リント・プラグイン。

IntelliJの基本設定でSonarLintを構成し、コードの有効性を検証するルールを選択できます。

基本的にSonarLintはリアルタイムで実行され、編集中の現在のコードに関する問題を表示します。

SonarLintは迅速な修正機能を提供しませんが、違反レポートに関連するドキュメントは一般的に明確でよく文書化されています。

SonarLintは、最新のJavaバージョンで知られている新しいJava機能について教えてくれるのに有用であることがわかりました。

チェックスタイル

チェックスタイルプラグインは、書式とコード品質ルールの組み合わせを提供します。

チェックスタイルプラグインは「サンチェック」および「グーグルチェック」と共に提供されます。

彼らの定義は単純かもしれません。オンラインで見つけました。

CheckStyleは、プロジェクトが独自のルールセットを作成する時間を割いた場合に最大の価値を発揮します。そうすれば、そのルールセットを使用するようにIDEプラグインを設定でき、プログラマーはコードをCIにコミットする前にスキャンを実行できます。

CheckStyleは、CheckStyle違反件数が閾値を超えた場合にCIプロセスのビルド失敗プラグインとして頻繁に使用されます。

先生

先生コードのマッチングおよびQuickFixsの生成には、AST（抽象構文木）に基づく静的解析を使用するため、問題のあるコードを非常に具体的に特定できます。

ASTを使用すると、レシピに関連するQuickFixが周辺コードを理解できます。例えば、コードに新しいクラスを追加する場合、そのクラスのインポートはソースファイルに一度だけ追加され、各置換には追加されません。

Senseiは、他のツールでは存在しない、あるいは構築が困難なカスタムマッチングルールを簡単に作成できるように設計されています。

構成ファイルを修正する代わりに、GUIですべての設定を実行できます。新しいレシピを作成する際、GUIを使用するとレシピに一致するコードを簡単に確認できます。また、QuickFixsを定義する際、コードの修正前と修正後の状態を即座に比較できます。したがって、状況に応じたレシピ（例：チーム、技術、さらには個々のプログラマーだけが使用できる固有のレシピ）を簡単に作成できます。

私はSenseiを他の静的解析ツールと併用しています。例えば、ほとんどの静的解析ツールは問題を発見しますが、解決はできません。Senseiの一般的な使用例は、他のツールのマッチング検索をSenseiで複製し、クイックフィックスとして拡張することです。これにより、適用されたカスタム修正が既にプロジェクトのコーディング標準を満たしているという利点があります。

IntelliJのインテントセットに既に存在するSensei を作成する場合があります。これは、インテントレポートが私が作成したコンテキストと完全に一致しない場合や、IntelliJが提供するQuickFixが使用したいコードパターンと一致しない場合です。

私は既存のツールを完全に置き換えるのではなく、既存のツールを補強する方を選びます。

Senseiは、共通ルールの状況に応じた変形を識別する際にも非常に有用です。例えば、静的解析ツールがサポートしていないSQLライブラリを使用している場合でも、静的解析エンジンの一般的なSQLルールが依然として適用される場合、Senseiを使用してそのルールのライブラリ固有の変形を作成できます。

Senseiは、前述の静的解析ツールのような一般的なレシピを数多く提供するものではありません。Senseiの強みは、特定のコーディングスタイルやユースケースに合わせて構成されたQuickFixを備えた新しいレシピを簡単に作成できる点にあります。

注：一般的なユースケースに対応するため、レシピの公開リポジトリを開発中です。 こちらで見つけることができます。

要約

私は連携し、構成可能で、特定の状況に合わせて容易に拡張できるツールを選ぶ傾向があります。私は長年、IDEの静的解析ツールを活用し、問題の特定や使用しているプログラミング言語とライブラリの詳細な理解に役立ててきました。

前述のすべてのツールを組み合わせて使用します。

• IntelliJ Intentionsは、関連するQuickFixを頻繁に使用することで、一般的なコードの問題を即座に把握できるように支援します。
• SpotBugsは、私が見逃したかもしれない単純なバグを見つけ、パフォーマンスの問題を通知します。
• SonarLintは、私が知らなかったJavaの機能を特定し、コードをモデリングする追加の方法を提供してくれます。
• CheckStyleを使用することで、CI中にも適用される合意されたコーディングスタイルを遵守できます。
• SenseiはQuickFixsを生成することで、静的解析ツールで検出される一般的なシナリオを補完し、他のツールでは構成が難しい特定のプロジェクトや技術レシピを作成することを支援します。

---

IntelliJ内で「環境設定\プラグイン」（Mac）または「設定\プラグイン」（Windows）を使用してSenseiをインストールした後、「センセイ セキュリティコード」を検索してください。

Secure Code Warrior の`sensei`プロジェクトで、一般的なユースケースに関するサンプルコードやレシピのリポジトリを見つけることができます。

https://github.com/securecodewarrior/sensei-blog-examples

先生についてもっと知る

組織のセキュリティ態勢を確実に向上させる方法は、開発者向けのセキュリティコーディングベストプラクティスを、基準線やベンチマークを含むフレームワークで提供し、必要な学習パスを設計することです。しかしセキュリティコーディングは一度で解決できる問題ではありません。組織のDNAに組み込まれ、生活様式として定着させる必要があります。開発者は左にシフトするだけでなく、左から始め、左へ移動し続ける必要があります。

単に教育を提供するだけでは不十分です。組織では、開発者が教育内容を完全に習得し、SDLC（ソフトウェア開発ライフサイクル）の初期段階で日常業務の一部としてベストプラクティスを実践していることを確認する必要があります。内部基準や業界ベンチマークと比較して開発者の成果を追跡し、進捗を測定することで、教育投資のROIを効果的に評価すべきです。

セキュアコードウォリアーズ信頼スコアは、個々の開発者の成果に対する可視性を提供し、データを集計して組織全体の成果を評価します。改善が必要な領域を特定すると同時に、スキル向上プログラムの効果を可視化します。また、一般データ保護規則（GDPR）、決済カード業界データセキュリティ基準（PCI DSS）、カリフォルニア州消費者プライバシー法（CCPA）など、様々なコンプライアンス要件への準拠を支援します。

当社の研究によると、セキュリティコード教育は効果的であることが示されました。Trust Scoreは、600以上の組織における25万人以上の学習者が業務で得た2,000万以上の学習データポイントに基づくアルゴリズムを使用し、脆弱性を除去するのに効果的であり、イニシアチブをより効果的にする方法を示しています。

教育を通じてセキュリティが強化されます — 開発者が教育を受けると

長年にわたり、SDLCの開始時にセキュリティのベストプラクティスを採用することは、ソフトウェア業界ではほとんど野心的な取り組みのように見えました。 いつかは必要だが、今日では優先順位が低い。しかしソフトウェア開発のスピードが加速し続ける中、ソフトウェアの脆弱性を標的にして構築される高度で破壊的なサイバー脅威の速度も同様に加速しており、セキュアコーディングは必須となった。サイバーセキュリティ・インフラセキュリティ庁（CISA）は、セキュアコーディングを前面に押し出し、中心に据えている。セキュリティを考慮した設計（Secure by Design）は、成長を続ける国際的なイニシアチブ運動である。

当社の研究により、セキュアバイデザインアプローチとソフトウェア脆弱性の低減との間に明確な相関関係が実証されました。SCW顧客ベースの脆弱性削減データ（26%）を分析した結果、開発者教育を通じてソフトウェア脆弱性が22%から84%に減少したことが明らかになりました。この範囲は、関連する企業の規模（開発者数が比較的少ない小規模企業ほど劇的な結果を生む）、学習グループが特定の問題に焦点を当てていたかどうか、といった変数に起因しており、 この場合、欠陥の割合がより高くなりました。

大企業の結果はほぼ一致していました。開発者が7,000人以上いる企業では、開発者のセキュリティ技術向上により脆弱性が47%から53%まで減少すると予測できます。例えば、10,000人以上の開発者を擁するある企業（プラットフォームで最高実績を上げた企業でも、ベンチマークが最も高い企業でもない）では、脆弱性が53%減少しました。

もちろん、最も効果的な教育のために広範で画一的なアプローチが必要なわけではありません。開発者の作業環境と開発者が行う開発のタイプに合わせて調整されるべきです。

企業はまず、開発者が単にコードを書くのと同じように自然にセキュアなコードを書けるようにするために、備えるべき基本技術を確立しなければなりません。アップスキリングプログラムは、行う作業の種類や使用する言語に合った実際のシナリオを用いた実践的でアジャイルなトレーニングで構成されるべきです。また、トレーニングセッションは業務スケジュールに合わせられるほど柔軟である必要があります。

開発者の場合、技術セットにはコード作成以上の作業が含まれます。開発者は人工知能アシスタントやサードパーティ製ソフトウェア（例：オープンソースリポジトリ）を確認できる必要があります。開発者たちは熱心なユーザーとして生成AIモデルを活用し、一般的にこのモデルがより多くのコードをより速く生成できる利点を高く評価しました。しかし回答者の76%が、AIが生成したコードは人間が作成したコードよりも安全だと回答した一方で、56.4%は依然としてAIが時々または頻繁にエラーを発生させると回答しました。同じ調査では、開発者の80%がAIコードのセキュリティポリシー適用を省略していることが明らかになり、これはAIコードの問題が未解決のままであることを示唆しています。

セキュアバイデザインのアプローチでは、開発者はセキュリティチームと別々に作業するのではなく、セキュリティチームと協力してSDLCの初期段階でこれらの問題を解決し、コードが本番環境に投入される前に欠陥を特定して修正します。

信頼スコアは個人および企業の業績を測定します。

継続的な教育の実施も重要です。企業は、最高職位から各職位に至るまで、全社的に適用されるセキュリティ優先の文化を採用すべきです。継続的な改善とSDLC全体における模範的なセキュリティ慣行の適用に重点を置く必要があります。技術とサイバー犯罪者は進化を止めず、サイバーセキュリティも同様です。ソフトウェアを開発する組織にとって、セキュリティ教育を受けた開発者が基盤となります。

したがって、トレーニングが効果的に定着したことを証明することは、トレーニング自体と同様に重要です。信頼スコアは、開発者個人と組織全体の成果を把握できるだけでなく、組織が成果データを詳細に分析し、特定の言語、開発者チーム、またはソフトウェアカテゴリに焦点を当てられるようにします。個別の成果および集計された成果結果のデータは、トレーニングを改善すべき領域（例：開発者の日常的な成果に望ましい影響を与えていないかどうか）を特定するのにも役立ちます。

組織はTrust Scoreを通じて開発者の実績を評価し、開発者が必要なセキュリティ技術を習得し、使用していることを確認することで、コード作成ライセンスを取得したかどうかを確認できます。これにより、組織は資格のある開発者に最も機密性の高いデータや重要なソフトウェアプロジェクトへのアクセス権を自信を持って付与し、まだ準備が整っていないツールを使用する開発者にはアクセスを拒否できます。

変化するセキュリティ文化の証

サイバーセキュリティはもはや単なるセキュリティ問題ではありません。これは多くの組織にとって最も重要な資産であるデータの完全性に影響を与えるビジネス上の問題です。深刻な侵害は組織の運営、評判、そして潜在的には組織の存続可能性にも影響を及ぼします。規制当局もサイバーセキュリティの重要性を軽視しておらず、ますます厳格な規制を実施する中で、CISOや潜在的には他の上級管理職に対して訴訟を起こす意向を示しています。 こうした規制当局は、Uberや SolarWindsの事例のように刑事告発を行うほどです。

今日の環境では、全社的なセキュリティ文化の採用が不可欠です。企業価値の相当部分がデータ、アプリケーション、サービスに存在するため、セキュアコーディングは企業文化の中核要素です。文化変革に教育が寄与した証拠とともに、文化的思考様式の一部である標的型教育と技術向上は、組織がセキュリティ態勢を強化する道へと進むことを可能にします。

開発者主導のセキュリティプログラムには価値があります。その証拠が信頼スコアです。