Menu

    Secure Code Warriorがコンプライアンス達成を支援する方法

    Avatar
    Secure Code Warrior Elves
    • 更新
    フォローする

    重要 : Secure Code Warrior はコンプライアンスの専門家でもコンサルタントでもありません。この記事は一般的なガイドとして作成されており、各標準の公開情報に基づいた洞察を提供するものであり、特定の監査アドバイスとして解釈されるべきではありません。

     



    PCI DSS

    PCI DSS は、カード所有者のデータ セキュリティを促進および強化し、世界規模で一貫したデータ セキュリティ対策を幅広く導入できるようにするために開発されました。PCI DSS は、アカウント データを保護するために設計された技術要件と運用要件のベースラインを提供します。これは、販売業者、プロセッサ、アクワイアラー、発行者、サービス プロバイダーなど、ペイメント カード処理に関与するすべてのエンティティに適用されます。PCI DSS は、カード所有者データ (CHD) や機密認証データ (SAD) を保存、処理、または送信するその他のすべてのエンティティにも適用されます。

     

    PCI DSS v4.0 では、6 つの制御目標にグループ化された 12 の要件が規定されています。

    • 管理目標 1: 安全なネットワークとシステムを構築し、維持する
    • 管理目標 2: カード会員データの保護
    • 管理目標 3: 脆弱性管理プログラムを維持する
    • 管理目標 4: 強力なアクセス制御手段を実装する
    • 管理目標 5: ネットワークを定期的に監視およびテストする
    • 管理目標 6: 情報セキュリティポリシーを維持する

    Secure Code Warrior は、開発者の作業に最も直接関連する 6 つの制御目標のうち 5 つをカバーし、これらの要件のうち 8 つを満たすのに役立ちます。

     

    PCI DSS v4.0 推奨事項の事前構築済みコース テンプレートを確認してください。


    ISO 27001 管理要件

    この規格の核心である目標 A.7.2.2 では、「情報セキュリティの意識、教育、トレーニングは、職務に応じてすべての従業員に提供される必要がある」と規定されています。それだけでなく、請負業者にもこの意識トレーニングを実施する必要があります。開発者やその他のエンジニアは、コストのかかるミスを回避するために、ソフトウェア セキュリティの基礎を習得する必要があります。これは通常、基本要件を超えており、開発者はソフトウェア セキュリティと信頼性の学習に継続的に時間を費やすことが推奨されます。

    目標 A.14.2 では、開発プロセスにおけるセキュリティが特に求められています。これは、セキュア開発ライフサイクル (SDLC) に適用されるセキュア開発ポリシーを確立することから始まります。

    目標 A.14.2.3 では特に、各アプリケーションのテストとレビューが求められます。

    目標 A.14.2.5 では、あらゆる情報システムにセキュア システム エンジニアリングの原則を実装する必要があります。脆弱性が発見された場合、これらの脆弱性の悪用を防ぐために、技術的な脆弱性管理プロセス (A.12.6) が必要です。適切なセキュア コーディング トレーニングがなければ、組織の開発者がこれらの脆弱性を修正する準備ができていない可能性があり、または脆弱性管理が会社にとってコストがかかりすぎる可能性があります。

    上記の要件に加えて、新しく改訂された ISO 27001:2022 には、次の要件があります。付録 A コントロール 8.28 は、適切なセキュア ソフトウェア コーディング プラクティスを開発、実装、およびレビューすることにより、不適切なソフトウェア コーディング プラクティスによって発生する可能性のあるセキュリティ リスクと脆弱性を防止するために組織を支援します。

    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているコースのすべてまたは組み合わせのいずれか:

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • セキュリティ要件
    • 脅威モデリング
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩

     

     

    SOC 2 - タイプ 2

    SOC 2 では開発者トレーニングの要件については規定されていませんが、より広義には次のことが求められます。

    • 従業員は、企業のセキュリティ ポリシーを遵守するための義務と責任を理解するために、採用時およびその後毎年、セキュリティ意識向上トレーニングを受講します。

      サービス組織は、この制御の下で、一般的なセキュリティ トレーニングに加えて、開発者向けのトレーニングを組み込むことができます。

    • セキュア コードの開発とテストに関するポリシーと手順。これには、開発者とテスト担当者向けのセキュア コード トレーニング、およびコードの脆弱性を特定して修正するためのツールと方法が含まれる場合があります。ポリシーの正確な範囲と内容は、サービス組織のコードとシステムの性質と複雑さに応じて異なる場合があります。一般的なガイドとして、組織はポリシーに関して次の点を考慮する必要があります。

    • セキュア コーディングのベスト プラクティスと標準: サービス組織は、セキュア コーディングのベスト プラクティスへの取り組みを示すために、開発者トレーニングを組み込むことができます。

    • 一般的な脆弱性とその回避方法

    • 安全なコードレビューとテストのツールと方法

    • インシデント対応および修復手順

    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • セキュリティ要件
    • 脅威モデリング
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩



    GDPR

    第 5 条 (f) - 個人データは、適切な技術的または組織的措置 (完全性と機密性) を使用して、不正または違法な処理、偶発的な損失、破壊、または損傷からの保護を含む、個人データの適切なセキュリティを確保する方法で処理されなければなりません。

     

    第 32 条 - 組織は、個人の権利を効果的に保護するために、リスク、技術の進歩、および特定の処理コンテキストに基づいて個人データを保護するための適切な技術的および組織的対策を実施する必要があります。GDPR のデータ保護原則 (第 5 条 - 説明責任) への準拠を実証し、開発者が次の場合に「最先端技術」(つまり、既存の技術とテクノロジーの最高レベルの開発) を十分に考慮できるようにするために、開発者の継続的なトレーニングが必要です。

    • 個人データを保護するための技術的措置を実施し（第 32 条）、データ処理活動の開始時およびライフサイクル全体にわたってプライバシー保護慣行を統合する（第 25 条 - 設計およびデフォルトでのデータ保護）。

    • 定期的なトレーニングにより、セキュリティ対策がすべてのプロセスにわたって一貫して適用され、新しいスタッフも規制要件と技術標準について同様に理解できるようになります。



    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • ソフトウェア セキュリティの基礎
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩

    HIPAA

    セキュリティ ルール (45 CFR 164) では、組織が処理する医療情報を保護し、特定の標準と実装推奨事項に従うことが義務付けられています。セキュリティ ルールの要素の概要は次のとおりです。

    • 一般原則 (45 CFR 164.306) - 組織は、すべての電子保護医療情報 (ePHI) の機密性、完全性、可用性を確保し、以下から保護する必要があります。
        • 当該情報のセキュリティまたは完全性に対する合理的に予測される脅威または危険
        • 許可または要求されていない、合理的に予測される情報の使用または開示

    • 管理上の保護措置 (45 CFR § 164.308) - 組織は、セキュリティ違反を防止、検出、封じ込め、修正するためのポリシーと手順を実装する必要があります。

      これには、従業員が適切に訓練され、監督されていること、および ePHI に対するリスクを特定して軽減するためのセキュリティ管理プロセスが実施されていることを保証することが含まれます。



    • 技術的保護手段 (45 CFR § 164.312) - 組織は、許可された人物のみが ePHI にアクセスできるようにする技術的ポリシーと手順を実施する必要があります。これには、ePHI が不適切に変更または破壊されないようにするためのアクセス制御手段、監査制御、整合性制御、および電子ネットワーク経由で送信される ePHI への不正アクセスを防ぐための送信セキュリティが含まれます。

    管理上の保護策の一部として直接言及されていますが、トレーニングは HIPPA の「合理的に予測される脅威/使用」という一般的な言及にも暗示されています。開発者が、ePHI を適切に保護するために必要な既知の脆弱性と対策について最新の知識を持っていることは合理的です。



    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • ソフトウェア セキュリティの基礎
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩


    NIS2

    • 管轄当局による監督
      NIS2 第 8 条では、各 EU 加盟国は、その領域内での指令の適用を監督する責任を負う管轄当局を任命することが義務付けられています。これらの当局は、NIS2 の対象となる組織が、セキュア コードのトレーニングに関連する要件を含む、その要件に準拠していることを確認する役割を担っています。

    • 必須サービス事業者（OES）向けのセキュリティ対策：
      第 14 条を参照すると、NIS2 では、エネルギー、輸送、医療、金融などの分野の事業者などの必須サービス事業者に対し、ネットワークと情報システムのセキュリティにもたらされるリスクを管理するために、 適切なセキュリティ対策を実施することを義務付けています。関係者に対するセキュア コードのトレーニングは、これらのセキュリティ対策の 1 つと見なすことができます。

    • リスク管理:
      NIS2 は、サイバーセキュリティの強化におけるリスク管理の重要性を強調しています。セキュア コードのトレーニングは、安全でないコードの使用によって生じるソフトウェアの脆弱性や侵害のリスクを軽減するための予防策と見なすことができます。
        • リスク管理（第 21 条）：組織はサイバーセキュリティのリスクを特定し、管理する必要があります。安全なコーディングの実践により、ソフトウェアの脆弱性が大幅に減少し、主要なリスク要因が緩和されます。
        • サイバー衛生慣行（第 21 条）：この指令では、適切な入力検証や安全なデータ処理などの安全なコーディング原則を含むことが多い基本的なサイバー衛生慣行を推奨しています。

    • セキュリティ バイ デザインとセキュリティ バイ デフォルト:
      NIS2 は、いくつかの条項 (14、16、18) で、セキュリティ バイ デザインとセキュリティ バイ デフォルトの原則を推進し、製品とサービスの開発に最初からセキュリティの考慮を組み込むことを要求しています。NIS 2 提案の序文 54 では、セキュリティ バイ デザインという「原則」が明示的に言及されており、これを第 18 条の要件に結び付けています。序文は法的拘束力はありませんが、指令の意図を解釈するための貴重なコンテキストを提供します。セキュア コードのトレーニングは、開発者がソフトウェア開発ライフサイクル全体を通じてセキュリティを優先する、セキュリティを意識した開発文化を育む上で重要な役割を果たします。基本的に、NIS2 にはセキュリティ バイ デザインに関する単一の章はありませんが、さまざまな条項で、予防的なセキュリティ対策とリスクベースのアプローチを提唱することで、この概念を推進しています。

    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • セキュア コード ウォリアーの推奨事項
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩
    • 脅威モデリング


    NIST

    米国国立標準技術研究所 (NIST) は、セキュア コード トレーニングを含むサイバー セキュリティのさまざまな側面に関するガイドラインと推奨事項を提供しています。NIST には規制機関のような具体的な要件はありませんが、組織がサイバー セキュリティの態勢を改善するために採用できるガイダンスとベスト プラクティスを提供しています。以下は、セキュア コード トレーニングに関する NIST のガイダンスの重要なポイントです。

    • NIST 特別出版物 800-53:
      この出版物は、連邦政府の情報システムおよび組織のセキュリティとプライバシー管理のカタログを提供します。安全なコードのトレーニングについては特に触れていませんが、組織の全体的なセキュリティ プログラムの一部としてのトレーニングおよび認識プログラムの重要性を強調しています。

    • NIST 特別出版物 800-64:
      この出版物は、情報セキュリティ リスクを管理するためのガイダンスの提供に重点を置いています。開発者やソフトウェア開発ライフサイクルに携わるその他の人員に対するセキュリティ トレーニングの重要性を強調しています。具体的なトレーニング要件は規定していませんが、組織が特定のニーズとリスクに基づいてトレーニング プログラムをカスタマイズする必要性を強調しています。

        • NIST 特別出版物 800-64 改訂 2: この改訂では、SP 800-64 で提供されるガイダンスが更新され、ソフトウェア開発ライフサイクルにセキュリティを統合することの重要性が強調されています。一般的な脆弱性を特定して軽減するために、安全なコーディングの実践と手法について開発者をトレーニングすることが推奨されています。

    • NIST サイバーセキュリティ フレームワーク (CSF):
      NIST CSF は、組織がサイバーセキュリティ体制を管理および改善するためのフレームワークを提供します。特定のトレーニング要件は規定していませんが、サイバーセキュリティ リスクの特定、保護、検出、対応、回復に向けた組織の取り組みの一環として、サイバーセキュリティの認識とトレーニングの重要性を強調しています。

    • NIST セキュア ソフトウェア開発フレームワーク (SSDF):
      要件セットではありませんが、SSDF はセキュア ソフトウェア開発のプラクティスを概説しています。これらのプラクティスの 1 つである PW.5: セキュア コーディング プラクティスに従ってソース コードを作成するでは、セキュア コーディング手法について開発者をトレーニングすることの重要性を強調しています。このプラクティスでは、インプレース トレーニングを提供する開発環境の使用など、セキュア コーディング プラクティスを実装する方法の詳細が説明されています。

    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • 大統領令 (EO) 14028 に基づく「EO クリティカル ソフトウェア」使用のセキュリティ対策
    • セキュア コード ウォリアーの推奨事項
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩
    • 脅威モデリング


    フェデラル・ランプ

    FedRAMP (Federal Risk and Authorization Management Program) は、政府機関向けに設計されたフレームワークです。このフレームワークは、さまざまなインフラストラクチャ プラットフォームやクラウドベースのサービス、ソフトウェア ソリューションに対するサイバー脅威とリスクを連邦政府機関が評価できるようにする標準化されたガイドラインを提供します。

    このフレームワークは、リアルタイムのサイバーセキュリティ プログラムを促進するために、IT インフラストラクチャとクラウド製品を継続的に監視することにも基づいています。さらに重要なのは、FedRAMP が、面倒で束縛された安全でない IT から、より安全なモバイルで迅速な IT への移行に重点を置いていることです。その目的は、連邦政府機関がセキュリティを損なうことなく、最新の信頼性の高いテクノロジーにアクセスできるようにすることです。

    望ましいセキュリティ レベルを達成するために、FedRAMP はクラウドおよびサイバー セキュリティの専門家と協力して、他のセキュリティ フレームワークを維持しています。これには、NSA、DoD、NIST、GSA、OMB、およびその他の民間セクター グループが含まれます。

    FedRAMP がセキュアコーディングとどのように関係しているかを以下に示します。

    • セキュリティ管理: FedRAMP では、包括的なセキュリティ管理の実装が義務付けられています。これらの管理には、次のような安全なコーディング プラクティスに関連する要件が含まれることがよくあります。
      • 入力検証
      • 出力エンコーディング
      • アクセス制御
      • エラー処理
      • 暗号化の実践
    • サードパーティによる評価: FedRAMP では、クラウド サービス プロバイダー (CSP) が独立したセキュリティ評価を受けることが義務付けられています。これらの評価には、CSP の安全なコーディング プラクティスや OWASP Top 10 などの業界標準への準拠のレビューが含まれることがよくあります。

    • 継続的な監視: FedRAMP では、セキュリティ要件への継続的な準拠を確保するために、クラウド サービスを継続的に監視する必要があります。これには、安全でないコーディング方法によって発生する可能性のある脆弱性の監視も含まれます。

    • 他の標準への準拠: FedRAMP は、安全なコーディングに関連する要件も含まれる NIST 800-53 などの他のセキュリティ標準を参照することがよくあります。

    SCW プラットフォームから選択するコースの推奨事項。以下にリストされているすべてのコース、またはそれらの組み合わせ。

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • 大統領令 (EO) 14028 に基づく「EO クリティカル ソフトウェア」使用のセキュリティ対策
    • セキュア コード ウォリアーの推奨事項
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩
    • 脅威モデリング

     

    ヒットラスト

    HITRUST Common Security Framework (CSF) には、リスク分析とリスク管理のフレームワーク、および運用要件が含まれています。このフレームワークには 14 の異なる制御カテゴリがあり、医療を含むほぼすべての組織に適用できます。

    このフレームワークは、医療業界の組織が IT セキュリティを管理する際に直面するセキュリティ問題に対応するために開発されました。これは、リスクを管理し、さまざまなコンプライアンス規制を満たすための効率的で包括的かつ柔軟なアプローチをこれらの機関に提供することにより実現されます。

    特に、このフレームワークは、個人情報を保護するためのさまざまなコンプライアンス規制を統合しています。これには、シンガポールの個人データ保護法が含まれ、一般データ保護規則に記載されている関連要件を解釈します。

    HITRUST がセキュアコーディングとどのように関係するかを以下に示します。

    • セキュリティ管理: HITRUST の CSF (Common Security Framework) は、組織が機密性の高い医療情報を保護するために実装する必要がある一連のセキュリティ管理の概要を示しています。これらの管理の多くは、次のような安全なコーディング手法に直接関係しています。
        • 入力検証
        • 出力エンコーディング
        • アクセス制御
        • エラー処理
        • 暗号化の実践

    • 評価と認証: HITRUST は、組織のセキュリティ管理と CSF への準拠を厳密に評価する認証プロセスを提供します。これには、組織のソフトウェア開発プラクティスのセキュリティを評価し、安全なコーディング原則に準拠していることを確認することが含まれます。

    • サードパーティの評価: HITRUST では、組織が認定された評価者による独立した評価を受けることを義務付けています。これらの評価には、組織の安全なコーディング プラクティスや OWASP Top 10 などの業界標準への準拠のレビューが含まれることがよくあります。

    • 継続的な監視: HITRUST では、組織が CSF への継続的な準拠を確保するために継続的な監視プロセスを実装することを要求しています。これには、安全でないコーディング方法によって発生する可能性のある脆弱性の監視が含まれます。

    SCW プラットフォームから選択するコースの推奨事項

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • セキュア コード ウォリアーの推奨事項
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩



    ドラ

    デジタル運用レジリエンス法（DORA）は、EU 金融セクター向けの拘束力のある包括的な情報通信技術（ICT）リスク管理フレームワークを作成する欧州連合（EU）規制です。

    DORA は、金融機関とその重要なサードパーティ技術サービスプロバイダーが 2025 年 1 月 17 日までに ICT システムに実装する必要がある技術標準を定めています。

    DORA は安全なコーディング標準に直接取り組むものではありませんが、金融機関がソフトウェア開発とセキュリティのベスト プラクティスを採用するよう促す規制環境を構築します。ソフトウェアが安全に開発されることを保証することで、金融機関は DORA の要件を満たし、運用の回復力を高めることができます。

    DORA がセキュア コーディングとどのように関係するかは次のとおりです。

    • インシデント管理: DORA では、金融機関に堅牢なインシデント管理フレームワークを導入することを義務付けています。安全なコーディング プラクティスは、データ侵害やシステム障害など、重要な業務を中断させる可能性のあるインシデントの防止に役立ちます。

    • サードパーティのリスク管理: DORA は、サードパーティのサービス プロバイダーに関連するリスクを管理することの重要性を強調しています。セキュアなコーディング プラクティスは、サードパーティのソフトウェア コンポーネントまたはサービスを扱う際のリスクを軽減するのに役立ちます。

    • テクノロジー リスク管理: DORA では、金融機関に包括的なテクノロジー リスク管理フレームワークの導入を義務付けています。ソフトウェアの脆弱性は業務の中断につながる可能性があるため、安全なコーディング プラクティスはテクノロジー リスクを軽減するための基本的な要素です。

    • ビジネス継続性管理: DORA では、中断が発生した場合でも重要な業務を継続できるように、ビジネス継続性計画を義務付けています。セキュア コーディングは、継続性計画のきっかけとなるインシデントの発生確率を減らすことで、ビジネス継続性に貢献できます。

    SCW プラットフォームから選択するコースの推奨事項

    • OWASP Top 10 の認識の概要または詳細な OWASP Top 10 の認識
    • セキュア コード ウォリアーの推奨事項
    • セキュリティ要件
    • 機密データの保存
      • パスワードのプレーンテキスト保存
      • 機密情報のプレーンテキスト保存
    • 情報露出
      • 機密データの漏洩



    CRA (サイバーレジリエンス法)

    EU サイバーレジリエンス法は、2022 年に欧州委員会によって初めて提案され、2024 年 3 月に欧州議会で可決された EU の法律です。この法律は、EU 市場で提供されるすべてのデジタル要素 (PDE) を含む製品、そのコンポーネント、およびその他のデジタル サービスに対して、明確な必須サイバーセキュリティ要件を定めています。CRA は、他のサイバーセキュリティ認証スキームと連携して機能することが期待されています。

    他の標準へのマッピングのリストについては、次を参照してください - https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping

     

    対象者:

    • EU 市場に投入されるデジタル要素 (ハードウェアとソフトウェアの両方) を含む製品の製造業者、輸入業者、販売業者
    • これらの製品を使用する重要なインフラストラクチャオペレーターと重要なサービスプロバイダー

    規制は具体的には以下の内容を対象としています:

    • コネクテッドデバイス（IoT製品）
    • ソフトウェア ソリューションとアプリケーション
    • オペレーティング システム
    • ネットワーク機器
    • スマートホームシステム
    • 産業用制御システム
    • 重要な分野で使用されるデジタルツール

    詳しい情報については、公式ガイダンスを参照してください - https://www.european-cyber-resilience-act.com/

    CRA がセキュアコーディングとどのように関係しているかは次のとおりです:

    サイバーレジリエンス法 (CRA) では、開発者にシフトレフトのセキュリティアプローチに従うことを要求する新しいセキュリティ標準が導入されています。これには、ソフトウェアの設計、開発、テスト、保守、およびリリース後に発生する脆弱性に対処するための定期的な更新が含まれます。

    その結果、開発者は、コード セキュリティ、脆弱性管理、インシデント対応、コンプライアンス ドキュメント、全体的な説明責任などの領域についてさらに考慮する必要が生じています。

      1. コード セキュリティ
        CRA では、開発者は記述するすべての行にセキュリティを組み込むとともに、最初から問題を特定するためにセキュア コード レビューを実行する必要があります。脆弱性を早期に特定して修正するには、セキュア コーディング プラクティス (入力のサニタイズ、XSS および SQL インジェクションの防止) に従い、自動化ツールを使用した定期的なセキュリティ テストを実施する必要があります。開発者には、セキュア ソフトウェアを設計および実装するための十分な知識とスキルも必要であり、セキュア コードのトレーニングを通じて継続的にスキルを習得する必要があります。

      2. 脆弱性管理
        すべてを解決できるパッチは 1 つだけではありません。開発者は、作業する製品のライフサイクル全体をカバーするアクティブな脆弱性管理プログラムで重要な役割を果たします。これには、問題を検出、報告、修正するプロセスの設定、および現在のソフトウェアとレガシー ソフトウェアの両方の定期的な更新の確保が含まれます。さらに、セキュア コードのトレーニングは、開発者がこれらの要件に準拠するための最新のセキュリティ プラクティスを理解するのに役立ちます。

      3. インシデント対応
        開発者は、サイバー インシデントへの対応において積極的な役割を果たす必要があります。これには、迅速なインシデント検出機能を備えた製品の作成、インシデント対応計画の支援、過去の侵害を調査して将来実施する必要がある変更点を明らかにすることが含まれます。

      4. コンプライアンス ドキュメント
        組織は、サイバーセキュリティ標準への準拠を証明する技術ドキュメントを提供する必要があります。開発者は、製品が標準を満たしていることを確認するために、これらの標準を理解する必要があります。

      5. セキュリティに対する説明責任
        CRA は製造業者に説明責任を課しており、これには製造業者のチーム (開発者を含む) が安全なプラクティスを実装できることを保証することが含まれます。

    SCW プラットフォームから選択するコースの推奨事項

      • OWASP Top 10 の認識と詳細な OWASP Top 10 の認識の紹介
      • セキュア コード ウォリアーの推奨事項
      • セキュリティ要件
      • 機密データの保存
        • パスワードのプレーンテキスト保存
        • 機密情報のプレーンテキスト保存
      • 情報露出
        • 機密データの漏洩
      • 脅威モデリング

    関連記事

    コメント

    0件のコメント

    記事コメントは受け付けていません。