Doka.EntityFrameworkCore.SafeMigrations

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。

バッジステータスの埋め込み方法は次のとおりです。

バッジステータスを表示するには、あなたのプロジェクトのマークダウンファイルに以下を埋め込みます

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14265/badge)](https://www.bestpractices.dev/projects/14265)

あるいは、以下をHTMLに埋め込みます

<a href="https://www.bestpractices.dev/projects/14265"><img src="https://www.bestpractices.dev/projects/14265/badge"></a>

これらは

レベルの基準です。

または

レベル基準を表示することもできます。

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

分析 8/8 ●

静的コード解析

Criterion [static_analysis]
適合

不適合

該当なし

?

選択した言語でこの基準を実装するFLOSSツールが少なくとも1つある場合、少なくとも1つの静的コード分析ツール（コンパイラの警告と「安全な」言語モード以外）を、ソフトウェアの主要な製品リリースの提案に、リリース前に適用する必要があります。 ^{[static_analysis]}
静的コード解析ツールは、ソフトウェアコードを実行せずに特定の入力を用いて（ソースコード、中間コード、または実行可能ファイルとして）調べます。この基準のために、コンパイラの警告と「安全な」言語モードは、静的コード解析ツールとしてカウントされません（これらは通常、速度が重要なため深い解析を行いません）。このような静的コード解析ツールの例には、cppcheck (C, C++)、clang静的解析 (C, C++)、SpotBugs (Java)、FindBugs (Java) (FindSecurityBugsを含む)、PMD (Java)、Brakeman (Ruby on Rails)、lintr (R)、goodpractice (R), Coverity Quality Analyzer、SonarQube、 Codacyおよび HP Enterprise Fortify Static Code Analyzer.大きなツールのリストは、静的コード解析のためのWikipediaツール一覧, 静的コード解析に関するOWASP情報、 NISTソースコードセキュリティアナライザのリスト、およびウィーラーの静的解析ツール一覧などがあります。使用する実装言語で使用できるFLOSS静的解析ツールがない場合は、「該当なし」（N/A）を選択します。

CodeQL default setup analyzes C#, Python, and GitHub Actions, while the .NET SDK also runs recommended analyzers. For assessed revision 478639494e1a2e4c66d62cde95cd8453fe1b8aed, CodeQL completed with 52 C# rules, 43 Python rules, and 17 Actions rules and reported zero results. The release workflow can publish only the qualified revision.
https://github.com/doka-labs/Doka.EntityFrameworkCore.SafeMigrations/actions/runs/33116946605

Criterion [static_analysis_common_vulnerabilities]
適合

不適合

該当なし

?

static_analysis基準に使用される静的解析ツールの少なくとも1つが、分析された言語または環境における共通の脆弱性を探すためのルールまたはアプローチを含むことが、推奨されています。 ^{[static_analysis_common_vulnerabilities]}
一般的な脆弱性を探すために特別に設計された静的解析ツールは、それらを見つける可能性が高いです。つまり、静的ツールを使用すると、通常は問題を見つけるのに役立ちますので、利用を提案しますが、「合格」レベルのバッジには要求しません。

CodeQL includes security queries for common vulnerabilities in the analyzed C#, Python, and GitHub Actions code, and the repository also runs .NET analyzers with warnings-as-errors.
https://github.com/doka-labs/Doka.EntityFrameworkCore.SafeMigrations/actions/runs/33116946605

Criterion [static_analysis_fixed]
適合

不適合

該当なし

?

静的コード解析で発見された中程度および重大度の悪用可能な脆弱性はすべて、それらが確認された後、適時に修正されなくてはなりません。 ^{[static_analysis_fixed]}
Common Vulnerability Scoring System (CVSS)の基本的な定性的なスコアが中程度以上であれば、脆弱性は中程度以上の深刻度とみなされます。CVSS のバージョン 2.0 から 3.1 では、これは CVSS のスコア 4.0 以上に相当します。プロジェクトは、広く利用されている脆弱性データベース（国家脆弱性データベースなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを用いて使用することができます。また、脆弱性が公開された時点で計算入力が公開されている場合には、脆弱性が公開された時点でのCVSSの最新バージョンを用いて深刻度を計算することもできます。基準 vulnerabilities_fixed_60_days では、公開後 60 日以内にすべての脆弱性を修正することが要求されていることに注意してください。

The assessed CodeQL analyses reported zero results and no confirmed medium-or-higher exploitable static-analysis vulnerability required remediation. Reassess immediately when a qualifying finding is confirmed.

Criterion [static_analysis_often]
適合

不適合

該当なし

?

静的ソースコード解析は、コミットごと、または少なくとも毎日実行することをお勧めします。 ^{[static_analysis_often]}

CodeQL default setup analyzes pull requests and the default branch and also has a weekly schedule. SDK analyzers run in the required qualification workflow for pull requests and main pushes.
https://github.com/doka-labs/Doka.EntityFrameworkCore.SafeMigrations/actions

動的コード分析

Criterion [dynamic_analysis]
適合

不適合

?

リリース前に、ソフトウェアの主要な製品リリースに少なくとも1つの動的解析ツールを適用することが示唆されています。 ^{[dynamic_analysis]}
動的解析ツールは、ソフトウェアを特定の入力で実行して検査します。たとえば、プロジェクトは、ファジングツール（アメリカンファジーロップなど）やウェブアプリケーションスキャナ（例： ZAP または w3af ）です。場合によっては、 OSS-Fuzz プロジェクトがプロジェクトにファズテストを適用する可能性があります。この基準のために、動的分析ツールは、様々な種類の問題を探すために何らかの方法で入力を変更するかまたは少なくとも80％のブランチカバレッジを持つ自動テストスイートである必要があります。動的解析に関するWikipediaのページとファジングに関するOWASPページで、いくつかの動的解析ツールを特定しています。解析ツールは、セキュリティの脆弱性を探すことに重点を置くことができますが、これは必須ではありません。

The official criterion accepts an automated test suite with at least 80% branch coverage as dynamic analysis. The assessed successful CI coverage artifact measured 84.29% for Core, 85.34% for MySQL/MariaDB, and 86.88% for PostgreSQL. The suites execute real provider behavior through Testcontainers with varied positive, negative, boundary, failure, cancellation, and generated-state inputs.
https://github.com/doka-labs/Doka.EntityFrameworkCore.SafeMigrations/actions/runs/33079411038

Criterion [dynamic_analysis_unsafe]
適合

不適合

該当なし

?

プロジェクトで作成されたソフトウェアにメモリ安全でない言語（CやC ++など）を使用して作成されたソフトウェアが含まれている場合、少なくとも1つの動的ツール（たとえば、ファジーまたはウェブアプリケーションスキャナ）を、バッファの上書きなどのメモリの安全性の問題を検出するメカニズムと一緒にいつも使用します。プロジェクトがメモリ安全でない言語で書かれたソフトウェアを作成しない場合は、「該当なし」（N/A）を選択します。 ^{[dynamic_analysis_unsafe]}
メモリの安全性の問題を検出するメカニズムの例としては、アドレスサニタイザー（ASAN）（GCCおよびLLVMで利用可能）、 Memory Sanitizer 、および valgrind が含まれます。他に使用される可能性のあるツールには、スレッドサニタイザと定義されていない動作サニタイザを参照してください。広範なアサーションも機能します。

SafeMigrations product source is C# and contains no unsafe blocks, native interop declarations, or enabled unsafe compilation. The official criterion directs projects without memory-unsafe product code to select N/A.

Criterion [dynamic_analysis_enable_assertions]
適合

不適合

?

プロジェクトでは、多くのアサーションを可能にする少なくとも一部の動的分析（テストやファジングなど）の構成を使用することをお勧めします。多くの場合、これらのアサーションは本番ビルドでは有効にしないでください。 ^{[dynamic_analysis_enable_assertions]}
この基準は、本番環境でアサーションを有効にすることを示唆するものではありません。それは完全にプロジェクトとそのユーザーが決定することです。この基準の焦点は、展開前の動的分析中の障害検出を改善することです。プロダクション環境でのアサーションの有効化は、動的分析（テストなど）中にアサーションを有効にすることとはまったく異なります。場合によっては、プロダクション環境でアサーションを有効にすることは非常に賢明ではありません（特に高整合性コンポーネントの場合）。プロダクション環境でアサーションを有効にすることには多くの議論があります。たとえば、ライブラリは呼び出し元をクラッシュさせてはなりません。ライブラリが存在するとアプリストアによる拒否が発生する可能性があります。また、プロダクション環境でアサーションをアクティブにすると、秘密鍵などの秘密データが公開される可能性があります。多くのLinuxディストリビューションではNDEBUGが定義されていないため、これらのディストリビューションのプロダクション環境ではデフォルトで C/C++ assert() が有効になります。これらの環境でのプロダクション環境では、別のアサーションメカニズムを使用するか、 NDEBUGを定義することが重要です。

The dynamic test configuration executes the xUnit assertion corpus and the product's fail-closed validation and runtime guards in Release builds; those checks are not compiled out. The assessed qualification run executed this configuration across Core and every provider matrix cell.
https://github.com/doka-labs/Doka.EntityFrameworkCore.SafeMigrations/actions/runs/33079411038

Criterion [dynamic_analysis_fixed]
適合

不適合

該当なし

?

動的コード分析で発見されたすべての中程度および重大度の悪用可能な脆弱性は、確認された後、適時に修正されなければなりません。 ^{[dynamic_analysis_fixed]}
動的コード分析を実行しておらず、この方法で脆弱性が見つからない場合は、「該当なし」（N/A）を選択してください。 Common Vulnerability Scoring System (CVSS)の基本的な定性的スコアが中以上の場合、脆弱性は中程度以上の重大度と見なされます。 CVSSバージョン2.0から3.1では、これは4.0以上のCVSSスコアに相当します。プロジェクトは、広く使用されている脆弱性データベース（ National Vulnerability Databaseなど）で公開されているCVSSスコアを、そのデータベースで報告されている最新バージョンのCVSSを使用して使用できます。代わりに、脆弱性が公表された後に計算入力が公開された場合、プロジェクトは脆弱性の開示時に最新バージョンのCVSSを使用して重大度を自ら計算することができます。

No confirmed medium-or-higher exploitable vulnerability was discovered by the assessed dynamic test and coverage runs. The secure-development policy requires root-cause reproduction, positive and negative regression tests, and release qualification for any future finding.

ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/14265/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。DominicおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクトバッジ登録の所有者： Dominic.
エントリの作成日時 2026-08-27 21:02:48 UTC、 最終更新日 2026-08-27 22:38:45 UTC 最後に2026-08-27 22:38:45 UTCにバッジ合格を達成しました。

Doka.EntityFrameworkCore.SafeMigrations

基本的情報 13/13 ●

一般

基本的なプロジェクトウェブサイトのコンテンツ

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

公開されたバージョン管理ソースリポジトリ

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テストスイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

セキュリティに関する開発知識

優良な暗号手法を使用する

MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信

広く知られた脆弱性を修正

その他のセキュリティ上の課題

分析 8/8 ●

静的コード解析

動的コード分析

Doka.EntityFrameworkCore.SafeMigrations

基本的情報 13/13 ●

一般

基本的なプロジェクト ウェブサイトのコンテンツ

FLOSSライセンス

ドキュメンテーション

その他

変更管理 9/9 ●

公開されたバージョン管理ソースリポジトリ

一意的なバージョン番号

リリースノート

報告 8/8 ●

バグ報告プロセス

脆弱性報告プロセス

品質 13/13 ●

作業ビルドシステム

自動テスト スイート

新機能テスト

警告フラグ

セキュリティ 16/16 ●

セキュリティに関する開発知識

優良な暗号手法を使用する

MITM（man-in-the-middle：中間者）攻撃に対応できる安全な配信

広く知られた脆弱性を修正

その他のセキュリティ上の課題

分析 8/8 ●

静的コード解析

動的コード分析

基本的なプロジェクトウェブサイトのコンテンツ

自動テストスイート