OPSWAT Secure SDLCフレームワーク：レジリエンスと徹底したセキュリティ防御への取り組み

悪意ある行為者は、利益や混乱を得るためにシステムを標的にし、組織にコストやビジネスリスク、風評被害をもたらす。 

最近の調査によると、セキュリティ・バグの修正にかかるコストは、本番環境で発見された場合と、分析・要求段階で発見された場合とでは、30倍も高くなる。

OPSWATのSecure SDLC フレームワークは、セキュアなソフトウェア開発を導く構造化された方法論とセキュリティ原則を定義しています。 

OPSWAT Software 開発ライフサイクルに従っています。顧客の要件に完全に準拠するため、規制要件と国際標準に準拠したSecure SDLCフレームワークを採用しました。このアプローチは、進化するサイバーセキュリティ環境における継続的な改善と回復力に対する当社のコミットメントを強化するものです。

OPSWATのSecure SDLC フレームワークは、NIST SP 800-218SSDFSecure Software 開発フレームワーク）に基づいて構築されており、ソフトウェア開発プロセスのすべての段階において、セキュリティが構造化され、測定可能で、一貫して適用されることを保証します。  

SSDFのベストプラクティスを統合することで、OPSWAT 、計画、設計から実装、検証、継続的モニタリングに至るまで、ソフトウェア開発のあらゆる段階にセキュリティを組み込み、プロアクティブなセキュリティ態勢を維持している。 

個々の製品の適合証明は、米国連邦政府のお客様にオンデマンドで提供しています。下記の連絡先をご参照ください。

サイバーセキュリティ規制が進化し続ける中、OPSWAT 、EU のサイバーレジリエンス法や NIS2 指令を始めとするグローバルな規制要件に自社のSecure SDLC フレームワークを整合させることに全力を注いでいます。新たな標準に積極的に適応することで、OPSWAT 、ますます複雑化する規制の状況において、Secure SDLC が包括的でコンプライアンスに準拠し、弾力的であり続けることを保証します。

強固な情報セキュリティを維持することは、業務の完全性と規制コンプライアンスの両方にとって極めて重要です。OPSWAT Secure SDLCフレームワークには、ISO 27001 ISMS（情報セキュリティマネジメントシステム）の原則が組み込まれており、セキュリティ管理、リスク管理戦略、コンプライアンス対策がクラウド製品の運用にシームレスに統合されています。 

OPSWAT 、当社のセキュリティ・ソリューションのプロバイダーであると同時に消費者でもあるため、社内で実施されているセキュリティ・ポリシーを適用し、当社の認定製品が導入前にエンタープライズ・グレードのセキュリティ要件に準拠していることを確認しています。  

コンプライアンスと認証の詳細をご覧ください。

最高水準のソフトウェア品質を確保するため、OPSWATのSecure SDLC フレームワークは ISO 9001 QMS（品質管理システム）に統合されています。QMS は、ガバナンス、変更管理、および部門横断的なプロセスのための監査済み品質管理を確立し、製品およびサポートの定義、設計、開発、製造、および保守をサポートします。  

このアプローチは、品質管理に対する構造化されたリスクベースのアプローチに対する当社のコミットメントを強化するものであり、アプリケーション・セキュリティがすべてのビジネス機能にわたって不可欠な考慮事項であり続けることを保証するものである。

コンプライアンスと認証の詳細をご覧ください。

OWASPSoftware 成熟度モデル（SAMM）は、組織が既存の SDLC の中で、効果的なソフトウ ェアセキュリティ戦略を評価し、策定し、実施するのを支援するために設計された包括的な枠組みです。

オープンソースのフレームワークである SAMM は、世界的な貢献によるメリットを享受し、アプリケーションセキュリティに対する協調的かつ継続的な進化を保証する。SAMM の構造化された方法論によって、組織は効果的かつ測定可能な方法で開発ライフサイクルを分析し、改善することができる。SAMM は、開発ライフサイクル全体をサポートする。SAMM は、技術やプロセスにとらわれない。SAMM は進化的で、リスク駆動型である。SAMM を活用することで、チームはセキュリティギャップに関する実用的な洞察を得ることができ、開発ライフサイクル全体を通じてセキュリティ態勢を体系的に強化することができる。

OWASP アプリケーションセキュリティ検証標準（ASVS）は、ウェブアプリケーションセキュリティに対する、構造化され、測定可能で、実行可能なアプローチを確立するために設計された、世界的に認知されたフレームワークです。これは、開発者とセキュリティチームに、アプリケーションが業界のベストプラクティスを満たすことを保証するための、包括的なセキュリティ要件と検証ガイドラインのセットを提供します。 

オープンソースのフレームワークであるASVSは、グローバルなセキュリティコミュニティからの広範な貢献の恩恵を受けており、新たな脅威や進化するセキュリティ標準に常に対応できるようになっています。

OPSWAT のSecure SDLC プログラムは、Secure SDLC フレームワークを構造化されたガバナンスに変換するものであり、セキュリティ要件が文書化され、維持され、測定され、継続的に改善されることを確実にすると同時に、すべての関係者が適切な訓練を受けることを確実にする。このプログラムでは、開発、テスト、本番環境の役割、責任、セキュリティ対策、および、パイプラインセキュリティを確立し、Secure 開発環境を定義し、Secure SDLC プロセスにおけるセキュリティポリシーの適用を義務付けています。

ハイレベル経営陣 - 最高製品責任者（CPO）

CPO（Chief Product Officer：最高製品責任者）は、すべての製品チームと、品質保証（QA）プログラムやユーザーエクスペリエンス（UX）プログラムなどの他の研究開発（R&D）プログラムにわたるSecure SDLC プログラムの戦略的な監督と実施に責任を持ち、セキュアで高品質なユーザー中心のソフトウェア開発への一貫したアプローチを確保します。

CPO は、すべての製品および R&D プロセスの主要なリスクオーナーとして、R&D オペレーションにSecure SDLC プログラムを所有することを義務付け、製品リーダーがSecure SDLC プログラムの適用を実施し、製品チームにSecure SDLC プロセスを効果的に実装していることを保証します。この役割において、CPO はSecure SDLC プログラムの修正と、Secure SDLC プロセスからの逸脱を承認します。

CPO はまた、Secure SDLC プログラムの成果を監視し、セキュリティ成熟度、脆弱性、コンプライアンス、開発活動を追跡し、製品の強固なセキュリティ体制を維持する。

さらに、CPO は研究開発セキュリティ予算の配分と承認に責任を持ち、適切なリソースがSecure SDLC プログラムに充てられるようにする。

戦略的優先事項

OPSWATのアプリケーションセキュリティに関する戦略的計画は、各製品の成熟度レ ベルとセキュリティ脅威へのエクスポージャーを考慮した上で、事業の優先事項とリスク選好度 に沿ったものとなっている。特に、大規模な顧客基盤を持ち、公衆の面前で展開され、重要なインフラに統合されているような、リスクの高い製品の保護に主眼を置いている。

Secure SDLC プログラムの一環として、当社の一般的なセキュリティ意識向上トレーニングに加えて、セキュアな開発に関与するすべてのスタッフに対して、役割に応じたセキュリティトレーニングが義務付けられています。すべてのトレーニングは、当社のトレーニングツールで追跡される。トレーニングと意識向上プログラムは定期的に見直され、新しいセキュリティ動向を取り入れ、セキュリティ標準への継続的なコンプライアンスを確保する。

OPSWAT は、継続的なセキュリティの有効性を確保するために、構造化されたパフォーマンス測定、成熟度評価、および定期的な更新を通じて、Secure SDLC プログラムを継続的に強化することを約束する。  

強固なセキュリティ態勢を維持するため、OPSWAT セキュリティ・パフォーマンスを追跡し、改善するための体系的なアプローチを採用している。これには、四半期ごとの製品セキュリティ成熟度評価、ベストプラクティスの遵守を確認するための内部セキュリティレビュー、四半期ごとに測定する年間主要業績評価指標（KPI）の定義などが含まれる。  

アプリケーションセキュリティ体制を効果的に測定するため、OPSWAT は構造化された指標を用いてチームを評価する。製品のセキュリティ成熟度は、SAMM フレームワークに基づいてチームごとに評価され、セキュリ ティの進捗を定量化できる指標となる。さらに、製品は ASVS コンプライアンス評価を受け、セキュリティ検証要件に準拠していることを確認する。Secure SDLC プロセスの遵守は綿密に監視、評価され、KPI 目標の達成は証拠に基づいて行われるため、セキュリティ態勢とセキュリティの改善が測定可能かつ実行可能であることが保証される。すべての製品チームは、年次業績評価の一環として、セキュリティ成熟度目標を達成することが求められる。 

継続的な改善努力の一環として、OPSWAT は、成熟度を高め、アプリケーション・セキュリティを強化するために、定期的に新しい製品セキュリティ・イニシアチブを導入している。これらの取り組みには、新たな脅威に対処するためのセキュリティポリシーの更新、検出と防止を強化するための新しいセキュリティツールの統合、継続的な進歩を推進するためのKPI目標の拡大などが含まれる。 

セキュリティガバナンスをさらに強化するため、OPSWAT 、過去のセキュリティインシデントの根本原因分析、脆弱性の傾向の評価、既存のプロセスやポリシーの改良から得られた知見を取り入れながら、Secure SDLC フレームワークの年次レビューを実施している。  

このような継続的改善への構造的アプローチにより、OPSWAT プロアクティブで弾力的な製品セキュリティ体制を維持し、進化するサイバーセキュリティの課題に効果的に適応しながら、規制と運用の両方のセキュリティ目標を達成することができる。

Secure SDLC プロセスは、各開発フェーズにおける自動化されたセキュリティチェックや検証メカニズムなどの具体的な活動を含め、チームが従わなければならないセキュリティ管理を定義することによって、Secure SDLC プログラムをさらに運用するものである。このプロセスは、品質保証プログラムやユーザエクスペリエンスプログラムなどの他の主要な研究開発プログラムと連携しており、安全で高品質な、顧客重視のソフトウェア開発への一貫したアプローチを保証する。 

Secure SDLC プロセスは、以下の節で詳述する：

• Secure 設計とリスク評価
• Secure 実装、構築、展開
• アプリケーション・セキュリティのテストと検証
• Secure
• Secure オペレーションとメンテナンス

Secure SDLC プロセスは高レベルのプロセスであり、チームは、プロセスのセキュリティが最低限と同じレベルに保たれなければならないという条件のもとで、拡張カスタマイズされた方法でそれを実装することができます。Secure SDLC プロセスからの逸脱は、文書化され、承認されなければならない。

Secure SDLC プログラムは、その要求事項への準拠を確実にするために、製品チームが正式に承認し、承認しなければならない様々な方針で構成されています。これらのポリシーの遵守は内部的に必須であり、各チームは開発プロセスの一環として、ポリシーをレビューし、署名し、実施する責任を負う。 

以下は、それぞれの目的とともに主要な政策のリストである。対外的に重要な政策については、追加的な詳細がこの文書に盛り込まれている。

Secure SDLC プロセスの一環として、セキュリティ要件は開発ライフサイクル全体を通じて追跡、文書化、維持される。サードパーティベンダーは、ASVS を認識し、満たすことが要求され、すべてのソフトウェアコンポーネントにわたって、セキュリティに対する期待と製品プライバシーコンプライアンスポリシーの遵守の一貫性を確保します。 

セキュリティは、開発ライフサイクルのすべてのフェーズに組み込まれます。セキュリティチャンピオンは、Secure SDLC プロセスの期待に留意し、チーム内でそれを代表する責任があります。 

Secure 設計要件セットには、ASVS に基づく機能的セキュリティ要件と非機能的セキュリティ要件が含まれる。リファレンス・モデルは、必要に応じて ASVS 要件を文書化した調整（より強力な暗号化要件など）とともに、設計上の意思決定をサポートするために R&D オペレーションズから提供される。

脅威モデリングは、開発ライフサイクルの初期段階で脅威と脆弱性を特定するための構造化されたプロセスです。これは、Secure SDLC プロセスの不可欠な部分であり、少なくとも年に 1 回、あるいは、新機能やアーキテクチャの変更が導入されるたびに定期的に実施されます。製品チームは、セキュリティ目標を定義し、資産と依存関係を特定し、潜在的な攻撃シナリオを分析し、特定された脅威を緩和することによって、脅威モデリングを実施します。  

強化されたアプローチでは、データフロー分析と確立された脅威モデリング手法（STRIDE モデルなど）が組み込まれ、製品全体の包括的な評価が保証される。必要に応じてセキュリティレビューを開始し、セキュリティ要件への準拠を検証するとともに、潜在的なリスクに積極的に対処する。設計上の決定は慎重に文書化され、製品ライフサイクルを通じて残存リスクが継続的に追跡される。

アプリケーションのセキュリティリスクは、脅威モデリング中に特定された残存脅威、OWASP Top 10 や SANS Top 25 などの広く認識されているセキュリティ脆弱性、ASVS ガイドラインに基づくセキュリティ管理の欠落など、複数の情報源を使用して評価される。その他のリスク要因としては、ビルド、デプロイメント、リリースの各プロセスにおける秘密管理の弱点、オープンソースやサードパーティのコンポーネントの脆弱性などがある。 

リスクアセスメントの後、特定されたリスクの重大性を軽減するために、影響と可能性の両方を考慮した軽減計画が策定される。これらの計画は、対応するリスクと緩和策とともに、徹底的に文書化される。 

残存リスクは、製品ライフサイクルを通じて追跡され、定期的なレビューの対象となり、リスク所有者によって正式に承認されなければならない。また、可視性と説明責任を維持するために、内部リリース報告書にも組み込まれる。 

必要に応じて、セキュリティレビューが開始され、セキュリティ要件への準拠を確保し、潜在的なリスクに積極的に対処することで、製品の全体的なセキュリティ態勢が強化される。

実装、構築、配備を含むSecure SDLC プロセスの一環として、Secure 設計とリスクアセスメントに基づいて、脆弱性と欠陥を防止することを目的としています。要求事項セットには、ASVS に基づく機能的及び非機能的なセキュリティ要求事項、セキュアな開発環境（Secure Development Environment）に依存するセキュアな開発及びテスト方法論に関する期待事項が含まれています。  

実施中は、Secure ベストプラクティス、Secure 、セキュリティ欠陥の早期発見を適用する。チームは、Supply Chain （ベンダーのオンボーディングとオープンソースソフトウェアのトピックを含む）、AI使用ポリシー、マルウェアサンプル取り扱いポリシーを遵守しなければならない。ビルドとデプロイメントの際には、集中化されたCI/CDパイプラインの使用と職務の分離によるSecure ビルドとデプロイが要求される。

製品チームは、実装時に、言語に依存しないセキュアコーディングのベストプラクティスに従わなければならない。入力データを検証し、他のシステムに送信されるデータをサニタイズし、コンパイラの警告を排除し、安全なエラーメッセージを設定し、該当する場合は出力エンコーディングを適用し、機密データを公開することなく安全なロギングを実装し、適切なエラー処理と例外管理のガイドラインに従うことが求められます。また、暗号を使用する場合は、承認されたアルゴリズムと安全な乱数生成に依存していることを確認し、メモリを安全に取り扱い、競合状態を防止し、適切な同期化によってデッドロックを回避することで、システムリソースを安全に管理する必要があります。 

製品チームはまた、以下に例示するように、SASTツールによって強制される、言語固有のセキュアコーディングガイドラインに従うことが推奨される： 

Javaの場合、チームは比較操作で使用されるキーが不変であることを保証し、Randomの代わりにSecureRandomを使用し、入力クラスを検証または制限することによって安全でないデシリアライズを避けるべきである。

C++では、メモリ割り当てエラーを検出して処理し、境界チェックやstd::unique_ptr()のようなスマートポインタの使用によってバッファオーバーフローを防ぎ、strcpy()やsprintf()のような安全でない関数を避けることが推奨される。 

Pythonの場合、開発者はコード・インジェクションのリスクを軽減するためにeval()やexec()のような関数の使用を避け、信頼できないデータを処理するときはpickleよりもjsonモジュールのような安全なシリアライズ形式を選ぶべきである。

アプリケーションセキュリティ検証ポリシーで要求されるセキュリティレビューの一環として、セキュアコードレビューは重要であり、OWASP Cheatsheetシリーズに基づき、様々なSecure 適用し、開発技術に応じて実行される。

アプリケーションセキュリティ検証ポリシー（Application Security Verification Policy）で要求されているように、セキュリティ上の欠陥を早期に発見することは、開発プロセスの重要な要素である。潜在的なセキュリティ問題を最小化するために、「フェイル・トゥ・ビルド（fail to build）」アプローチが必須であり、安全でないコードがパイプラインを通過しないようにする。さらに、「フェイル・トゥ・マージ（fail to merge）」アプローチが強制され、 変更を統合する前に、検出された問題を修正することがチームに求められる。検出された欠陥を解決することは、リリース基準を満たすために不可欠である。

Secure SDLC プロセスの一部として、セキュアなビルドを実施し、サプライチェーン攻撃を回避するために、一元化され、オーケストレーショ ンされた CI/CD パイプラインの使用は必須です。監査、ビルド、およびデプロイのログは、会社のセキュリティポリシーの定義に従って、生成、保存、およびレビューされます。 

各製品チームは、該当する場合、セキュアなビルドとコンパイラ設定に従う責任がある。セキュアなコンパイラ・オプションを使用し、デバッグ・コードを無効にし、インタプリタ言語のランタイムをハード化し、依存バージョンを固定し、再現可能なビルドを保証し、コンテナ・イメージをハード化する必要があります。使用された設定は文書化され、定期的にレビューされなければならない。 

職務分掌の原則に則り、コードまたはビルドのアクセス権を持つ開発者やその他のチームメンバーは、本番環境にアクセスすることはできません。クラウド製品の場合、製品のサイトの信頼性エンジニアのみが本番環境へのデプロイを許可される。

当社のアプリケーションセキュリティ検証ポリシーに従って、発見された問題の正式な文書化と追跡を実施し、継続的な検証のための自動化ツールを割り当てます。Secure SDLC プロセスの一環として、セキュリティチェックは、コンプライアンス要件を満たすために、SDLC の各段階で実施され、追跡されます。これらの目的は、可能性のあるセキュリティ上の欠陥を効率的に発見することです。発生したセキュリティ問題は、チームによって調査され、期限内に対処されます。時間枠は、定義されたセキュリティ KPI の一部である。

• アーキテクチャと設計のレビューシニアエンジニアとアプリケーションセキュリティバーチャルチームのメンバーが、暗号化、認証、認可、監査、システムハードニング、システムおよびネットワークアーキテクチャなど、設計変更におけるセキュリティ側面を評価する。 
• コードレビュー： ピアエンジニアとシニアエンジニアによる通常のコードレビューに加えて、アプリケーションセキュリティバーチャルチームのメンバーが、インジェクション、エラー処理、安全でない設定などの一般的な欠陥を防ぐために変更をレビューする。

• シークレットスキャンは、シークレットの流出を回避し、シークレットハンドリングの優れた設計と安全な実装を保証する。
• 脆弱性（SQLインジェクション、バッファオーバーフローなど）を検出するSAST（静的アプリケーションセキュリティテスト）ツール。
• SCA（Software 構成分析）は、オープンソースの脆弱性を検出するために使用される。
• DAST（ダイナミック・アプリケーション・セキュリティ・テスト）は、ランタイム（メモリの欠陥など）や環境の問題を発見するために使用される。

セキュリティ問題の早期発見のセクションで定義されているツールは、CI/CD パイプラインで使用することが必須です。特定されたすべての脆弱性は、製品のVulnerability Management ポリシーに従って修正されなければならない。

自動セキュリティテストと手動セキュリティテストの両方の方法論が、セキュリ ティテスト計画を実行する品質保証プログラムに従って使用される。

• DASTツールは 、実行時の脆弱性の検出、デフォルト設定のテスト、およびハードニングの提案を適用した後のシステムの回復力のテストに使用される。このテストは、ソフトウェアと基盤となるインフラの両方を対象としている。 
• セキュリティ要件と機能の後退を避けるため、自動テストツールを使用して、セキュリティ機能と制御の完全性を継続的に検証しています。 
• 手動テストは 、情報漏えい対策の検証、ビジネスロジックの欠陥の特定、文脈上の脆弱性など、自動化ツールでは不十分な場合に適用される。 
• 開発ライフサイクルにおける成果物の自動マルウェアスキャンも、セキュリティ問題の予防に重点を置くステップの一部である。

Secure SDLC プロセスの一部として、リリースプロセスは、アプリケーションセキュリティテストと検証による発見に基づいて、Secure SDLC プロセスの遵守と製品の全体的なセキュリティの両方を保証するリリース基準を実施します。製品のバージョン管理は、各リリースの基本的な要件として、リリース全体にわたってセキュリティの改善を維持し、セキュリティ関連の後退を防止し、達成されたセキュリティ体制を維持する上で、重要な役割を果たします。 

リリースプロセスには、残存リスクと未解決のセキュリティ問題を文書化した内部リリース報告書の作成が含まれる。これらの報告書は、製品リーダーによって正式に承認されなければならない。さらに、製品の正式リリースの一部として、セキュリティ関連の変更と修正を伝える外部リリースノートも作成する。 

クラウド製品については、デプロイは「フェイル・トゥ・デプロイ」自動化アプローチに従い、安全なビルドのみがリリースされるようにする。アプリケーションセキュリティのテストと検証は、プッシュではなくプル戦略によってデプロイパイプラインに統合され、本番デプロイ前のセキュリティ検証が強化される。 

SBOM管理ポリシーに基づき、各リリースにはSoftware Bill of Materials (SBOM) ）が含まれ、コンポーネントの出所のトレーサビリティを維持し、透明性とサプライチェーンのセキュリティをサポートします。必要なリリース・ファイルはすべて安全にアーカイブされ、長期的なアクセス性を確保しています。

リリース・インテグリティ・ポリシーによると、製品リリースの完全性とセキュリティを維持するために、構造化されたバージョニング・システム（セマンティック・バージョニングなど）が適用され、変更の明確なトレーサビリティと、ドキュメントを含むすべてのリリース済み成果物の定義された保存期間が保証されます。セキュリティをさらに強化するため、ソフトウェア成果物は会社名でデジタル署名され、公開されたSHAフィンガープリントにより、ユーザーは真正性を検証し、改ざんの試みを検出することができます。 

各リリースには、完全性の検証方法、安全なインストール手順、構成のベストプラクティス、システムの堅牢化対策に関する詳細なガイダンスを提供する文書がバージョンごとに 付属しています。これらのリソースは、ユーザがセキュリティ制御を効果的に実装し、潜在的な攻撃面を減らすのに役立ちます。さらに、エンドユーザー使用許諾契約書（EULA）も含まれており、コンプライアンス義務を確立し、法的透明性を維持します。 

個々の製品のSBOMは、お客様のご要望に応じてご提供いたします。お問い合わせ

開発環境、テスト環境、本番環境は、不正アクセスを防ぐために安全に分離されています。各環境は厳格なハードニング・ベースラインとエンドポイント・セキュリティ・プロトコルに従います。開発環境は、会社のセキュリティポリシーに準拠している必要があります。

エンドポイント保護の一環として、OPSWAT 所有するすべてのデバイスは、脆弱性、インストールされているソフトウェア、インストールされているパッチ、および会社のセキュリティポリシーへの準拠について監視されます。コンプライアンス違反があった場合、企業リソースへのアクセスを制限する措置が取られます。 

高リスクカテゴリーに分類されたリソースには、制御されたアクセス経路（VPN）を経由してのみアクセスできる。社内ネットワーク外のデバイスは、安全な経路を使用して研究開発リソースにアクセスすることが義務付けられています。

CI/CDパイプラインのセキュリティは、進化する脅威を軽減するために、厳格なセキュリティ指令に従う。脅威の原因は、時代遅れのインフラストラクチャ要素（オペレーティングシステム、分析ツールなどのような）、脆弱な権限管理による不正アクセス、十分に分離されていない環境などです。CI/CD インフラストラクチャを最新の状態に保ち、徹底的に検証し、厳重に管理することは、私たちのセキュアな SDLC の礎石です。 

地域的には、コードストレージ、CI/CDパイプライン、分析・テストツール、安全な成果物署名など、すべての集中型サービスには米国ベースのサーバーが使用されている。すべての集中ツールの設定は、R&Dオペレーションズの管理下にある。 

強力な認証メカニズム（多要素認証 - MFA）と権限制御（役割ベースのアクセス制御 - RBAC）を適用しています。最小権限と定期的なアクセスレビューを実施します。 

当社のパイプラインには、静的アプリケーション・セキュリティ・テスト（SAST）、Software 構成分析（SCA）、動的アプリケーション・セキュリティ・テスト（DAST）、シークレット・スキャン、マルウェア・スキャンなど、複数の分析・テスト自動化ツールが組み込まれています。 

私たちのセキュアなコード署名ソリューションでは、不正アクセスから鍵素材を保護し、署名を生成するためにHardware セキュリティ・モジュール（HSM）を使用しています。署名ソリューションはCI/CDインフラの一部ですが、ネットワーク・セグメンテーションが行われています。HSMへのアクセスは、短期間であればR&Dオペレーションにのみ許可されている。すべての署名操作はログに記録され、監査証跡で確認することができる。 

ソフトウェアのビルド、コンパイル、テストに使用されるツールセットは、実績情報を持ち、検証されたソースから提供されたものでなければならない。CI/CDパイプラインで使用されるツールは数に制限があり、必要なツールのみがインストールされる。パイプラインのコンパイルとビルドのステップでは、LTSソフトウェアのみが許可される。集中型サービスの運用では、定期的なメンテナンスとキーのローテーション期間が定められている。内部で開発されたツールは、Secure SDLC プロセスに該当する。

すべての集中型サービスの環境ハードニングは継続的に行われ、これらのセキュ リティ要件は定期的に見直される。ハードニングのガイドラインは、製品チームに確実に伝達される。セキュリティインシデントが発生した場合は、RCA を実施して予防措置を講じ、これらの要件を更新する。

ソースコードの保護は、社内のソースコードの機密性と完全性を保証するために、ソフトウェア開発において極めて重要な部分である。 

ソースコードは最小特権の原則に従って保存され、許可された人員とツールにのみアクセスを許可する。ソース・コードはバージョン管理下にある。バージョン管理システムは、コード変更のトレーサビリティと説明責任を保証する。ソースコードの保管は、FIPS 140-3に準拠した暗号化方式で暗号化され、適切な鍵長で保護されている。

本方針の遵守は、社内の全チームにとって必須である。この文書は会社のポリシーに従属するものであり、矛盾がある場合は会社のポリシーが優先され、それに従わなければなりません。 

Secure SDLC 違反に対するエスカレーションプロセス：このポリシーの違反は、R&D オペレーションから始まり、必要に応じて最高製品責任者（CPO）にエスカレーションされます。

ISO 27001、SOC2、NIST SSDF の適用範囲にある製品のコンポーネントやサービスを提供するベンダは、Secure SDLC フレームワークから以下に概説される要求事項に準拠することが期待されます。コンプライアンスは、定期的なセキュリティ監査、第三者による評価、および締結された契約に基づく各当事者の義務の対象となります。 

すべてのベンダーは、「リリースの完全性」セクションで定義されているように、証明書類とともに、出所と完全性に関する情報を提供することが求められる。 

製品コンポーネントおよびライブラリのベンダーは、「Secure 開発環境」のセ クションに記載されているように、当社の慣行に沿った開発環境を構築しなければな らない。ベンダーは、「アプリケーションのセキュリティテストと検証」のセクションで説明するように、コンポーネントとライブラリにセキュリティテストを適用しなければなりません。 

また、パイプラインコンポーネントベンダーは、「Secure 開発環境」の項に記述されているように、OPSWAT の慣行に沿った開発環境を確立しなければならない。さらに、ベンダーの開発プロセスは、OPSWATのSecure SDLC プロセスに沿ったものでなければなりません。 

サービスベンダーは、OPSWATサービスと同等のセキュリティ体制を提供する米国ベースの環境を利用することが期待されている。そのSecure SDLC には、OPSWATの期待に沿うSecure SDLC プログラムとSecure SDLC プロセスの両方が含まれていなければならない。