OPSWAT Secure フレームワーク：レジリエンスと多層防御への取り組み

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

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

OPSWAT「Secure Framework」は、安全なソフトウェア開発を導く体系的な方法論とセキュリティ原則を定義しています。 

OPSWAT 、アジャイルSoftware ライフサイクルOPSWAT 。お客様の要件に完全に準拠するため、規制要件や国際基準に即した「Secure フレームワーク」を導入しました。このアプローチにより、変化し続けるサイバーセキュリティ環境において、継続的な改善とレジリエンスへの当社の取り組みがさらに強化されます。

OPSWAT「Secure Framework」は、NIST SP 800-218SSDF（Secure Software Framework）に基づいて構築されており、ソフトウェア開発プロセスの全段階において、セキュリティ対策が体系化され、測定可能であり、一貫して適用されることを保証します。  

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

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

サイバーセキュリティ規制が進化し続ける中、OPSWAT 、EUサイバーレジリエンス法やNIS2指令を皮切りに、自社の「Secure 」を世界的な規制要件に適合させることにOPSWAT 。新たな基準に先を見越して適応することで、OPSWAT 、ますます複雑化する規制環境においても、自社のSecure 」が包括的かつコンプライアンスに準拠し、強靭性をOPSWAT 。

強固な情報セキュリティの維持は、運用の健全性と規制遵守の両方にとって極めて重要です。OPSWAT「Secure Framework」は、ISO 27001のISMS（情報セキュリティマネジメントシステム）の原則を取り入れており、セキュリティ対策、リスク管理戦略、およびコンプライアンス対策が、当社のクラウド製品の運用にシームレスに統合されることを保証しています。 

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

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

最高水準のソフトウェア品質を確保するため、OPSWAT Secure Framework」はISO 9001品質マネジメントシステム（QMS）に統合されています。このQMSは、ガバナンス、変更管理、および部門横断的なプロセスについて、監査を受けた品質管理体制を確立しており、製品およびサポートサービスの定義、設計、開発、製造、保守を支援するとともに、その範囲は研究開発にとどまらず、営業、カスタマーサポート、情報技術、人事などの分野にも及んでいます。  

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

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

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

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

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

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

OPSWAT「Secure 」は、「Secure 」を体系的なガバナンスへと具体化し、セキュリティ要件が文書化、維持、測定、そして継続的に改善されることを保証するとともに、関係者全員が適切なトレーニングを受けられるようにします。このプログラムでは、開発、テスト、本番環境における役割、責任、セキュリティ対策を確立し、パイプラインのセキュリティについても規定するとともに、Secure 」を定義し、「Secure 」内でのセキュリティポリシーの適用を義務付けています。

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

最高製品責任者（CPO）は、すべての製品チームにおける「Secure 」および、品質保証（QA）プログラムやユーザー体験（UX）プログラムといったその他の研究開発（R&D）プログラムの戦略的統括と実施を担当し、安全で高品質かつユーザー中心のソフトウェア開発に向けた一貫したアプローチを確保します。

CPOは、すべての製品および研究開発プロセスの主要なリスク責任者として、研究開発部門に対し「Secure プログラム」の責任を担うよう指示するとともに、製品リーダーがSecure 適用を徹底し、各製品チームにおいて「Secure プロセス」を効果的に実施するよう確保します。この役割において、CPOは「Secure プログラム」の変更および「Secure プロセス」からの逸脱を承認します。

また、CPOは「Secure 」の成果を監視し、セキュリティの成熟度、脆弱性、コンプライアンス、および開発活動を追跡することで、製品の強固なセキュリティ態勢を維持しています。

さらに、CPOは研究開発（R&D）のセキュリティ予算の配分と承認を担当し、「Secure プログラム」に十分なリソースが割り当てられるよう確保する。

戦略的優先事項

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

「Secure 」の一環として、当社の一般的なセキュリティ意識向上研修に加え、セキュア開発に携わる全スタッフに対して、役割に応じたセキュリティ研修の受講が義務付けられています。すべての研修は、当社の研修管理ツールで記録・管理されています。研修および意識向上プログラムは定期的に見直され、最新のセキュリティ動向を反映させるとともに、セキュリティ基準への継続的な準拠を確保しています。

OPSWAT 、体系的なパフォーマンス測定、成熟度評価、および定期的な更新を通じて、「Secure 」を継続的に強化し、セキュリティの有効性を維持することにOPSWAT 。  

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

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

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

セキュリティガバナンスをさらに強化するため、OPSWAT 「Secure 」フレームワークについて年次見直しOPSWAT 、過去のセキュリティインシデントの根本原因分析から得られた知見、脆弱性の動向評価、および既存のプロセスやポリシーの改善点を反映させています。  

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

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

「Secure プロセス」については、以下のセクションで詳しく説明しています：

• Secure とリスク評価
• Secure 、ビルド、およびデプロイ
• アプリケーション・セキュリティのテストと検証
• Secure
• Secure ・保守

「Secure プロセス」は概要レベルのプロセスであり、各チームは、プロセスのセキュリティレベルを最低限の基準と同等以上に維持することを条件として、これを拡張・カスタマイズして実装することができます。Secure プロセスからの逸脱については、文書化および承認を受ける必要があります。

「Secure 」は、その要件への準拠を確保するために、製品チームによる正式な承認と確認が必須となるさまざまなポリシーで構成されています。これらのポリシーの遵守は社内で義務付けられており、各チームは開発プロセスの一環として、これらのポリシーを確認、署名、および実施する責任を負っています。 

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

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

セキュリティは、開発ライフサイクルのあらゆる段階に組み込まれています。セキュリティ推進担当者は、「Secure 」の要件を常に念頭に置き、チーム内でその内容を周知徹底する責任を負っています。 

「Secure 」要件セットには、ASVSに基づく機能要件および非機能要件が含まれています。設計上の意思決定を支援するため、R&D Operationsより参照モデルが提供されており、必要に応じてASVS要件に対する調整内容（例：より厳格な暗号化要件）も文書化されています。

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

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

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

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

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

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

実装、ビルド、デプロイメントを含むSecure プロセスの一環として、Secure およびリスク評価に基づき、脆弱性や欠陥の防止を目指しています。この要件セットには、ASVSに基づく機能的および非機能的なセキュリティ要件、Secure 環境に依拠したSecure 開発およびテスト手法に関する期待事項が含まれています。  

実装段階では、Secure ベストプラクティス、Secure 、およびセキュリティ上の欠陥の早期発見を適用する必要があります。各チームは、Supply Chain （ベンダーのオンボーディングやオープンソースソフトウェアに関する事項を含む）、AI利用ポリシー、およびマルウェアサンプル取り扱いポリシーを遵守しなければなりません。ビルドおよびデプロイ段階では、一元化されたCI/CDパイプラインの活用と職務分離を伴う、Secure およびデプロイSecure 求められます。

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

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

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

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

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

「アプリケーションセキュリティ検証ポリシー」で義務付けられているセキュリティレビューの一環として、セキュアコードレビューは重要であり、開発技術に応じて実施されます。その際、OWASPチートシートシリーズに基づいたさまざまなSecure チェックリストが適用されます。

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

Secure プロセスの一環として、セキュアなビルドを徹底し、サプライチェーン攻撃を防ぐためには、一元化され、オーケストレーションされたCI/CDパイプラインの使用が必須です。監査、ビルド、およびデプロイのログは、会社のセキュリティポリシーに定められた通り、生成、保存、および確認されます。 

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

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

当社の「アプリケーションセキュリティ検証ポリシー」に基づき、発見された問題については正式な文書化と追跡を実施し、継続的な検証のために自動化ツールを割り当てています。Secure 一環として、コンプライアンス要件を満たすため、SDLCの各段階でセキュリティチェックが実施され、その状況が追跡されています。これらは、潜在的なセキュリティ上の欠陥を効率的に発見することを目的としています。発生したセキュリティ上の問題は各チームによって調査され、所定の期間内に是正措置が講じられます。この期間設定は、定義されたセキュリティKPIの一部となっています。

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

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

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

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

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

Secure 一環として、リリースプロセスは、アプリケーションセキュリティテストおよび検証の結果に基づき、Secure 順守と製品の全体的なセキュリティの両方を確保するためのリリース基準を適用します。製品のバージョン管理は、リリースごとにセキュリティの向上を維持し、セキュリティ関連の回帰を防止し、達成されたセキュリティ態勢を維持する上で極めて重要な役割を果たしており、各リリースの基本的な要件となっています。 

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

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

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 」の対象となります。

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

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

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

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

Secure に関するエスカレーション手順：本ポリシーの違反については、R&Dオペレーションズを起点として社内で対応し、必要に応じて最高製品責任者（CPO）へとエスカレーションされます。

ISO 27001、SOC2、NIST SSDFの対象となる製品向けのコンポーネントまたはサービスを提供するベンダーは、「Secure フレームワーク」に規定される以下の要件を遵守することが求められます。この遵守状況については、定期的なセキュリティ監査、第三者による評価、および締結された契約に基づく各当事者の義務の対象となります。 

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

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

パイプラインコンポーネントのベンダーは、「Secure 」のセクションに記載されている当社の慣行に沿った開発環境を整備する必要があります。さらに、その開発プロセスは、OPSWAT「Secure 」に準拠している必要があります。 

サービスベンダーは、OPSWATサービスと同等のセキュリティ体制を備えた、米国に拠点を置く環境を活用することが求められます。そのSecure 、OPSWAT要件を反映した「Secure プログラム」と「Secure プロセス」の両方が含まれていなければなりません。