fedfred

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

これがあなたのプロジェクトなら、あなたのプロジェクトページにあなたのバッジステータスを表示してください！バッジステータスは次のようになります。 プロジェクト 10158 のバッジ レベルは gold です バッジステータスの埋め込み方法は次のとおりです。

これらはゴールドレベルの基準です。合格またはシルバーレベル基準を表示することもできます。

        

 基本的情報 5/5 ●

  • 識別情報

    A feature-rich python package for interacting with the Federal Reserve Bank of St. Louis Economic Database: FRED

  • 前提要件


    バッジには十分です！

    プロジェクトは、シルバー レベル バッジを達成しなければなりません。 [achieve_silver]

  • プロジェクトの管理・運営


    バッジには十分です！

    プロジェクトは2以上の "バス ファクタ"を持つ必要があります。 (URLが必要です) [bus_factor]

    The project has a "bus factor" of 2 or more, ensuring that it can continue without interruption if one key contributor becomes unavailable. Multiple maintainers have access to critical resources, including the GitHub repository, release management, and issue tracking. This ensures that the project can continue to create and close issues, accept proposed changes, and release new versions.

    The governance model and contribution process are documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    Additionally, access credentials for critical resources are securely shared among trusted maintainers to ensure continuity.


    バッジには十分です！

    プロジェクトには少なくとも2人の関係を持たない重要な貢献者がいなければなりません。 (URLが必要です) [contributors_unassociated]

    The project has at least two unassociated significant contributors. This information can be verified through the GitHub repository's contributors page, which lists all contributors and their contributions: https://github.com/nikhilxsunder/fedfred/graphs/contributors.

    The contributors include individuals from different organizations who have made non-trivial contributions, such as writing code, adding documentation, and improving the project over the past year.


  • その他


    バッジには十分です！

    プロジェクトは、各ソースファイルにライセンスステートメントを含まなければなりません。これは、各ファイルの先頭近くに次のコメントを含めることによって行うことができます： SPDXライセンス識別子：[プロジェクトに対するSPDXライセンス表現] [license_per_file]

    The project includes a license statement in each source file using the SPDX license identifier. For example: license = "AGPL-3.0-or-later"


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


    バッジには十分です！

    プロジェクトのソースリポジトリは、共通の分散バージョン管理ソフトウェア（gitやmercurialなど）を使用しなければなりません。 [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


    バッジには十分です！

    プロジェクトは、新規または偶に参加する貢献者によって実行できる小さなタスクを明確に識別しなければなりません。 (URLが必要です) [small_tasks]

    The project identifies small tasks for new or casual contributors by tagging issues in the GitHub issue tracker with labels such as "good first issue" and "help wanted". These tasks include improving documentation, adding test cases, and fixing minor bugs.

    You can view these tasks in the project's issue tracker at: https://github.com/nikhilxsunder/fedfred/issues.


    バッジには十分です！

    プロジェクトは、中央リポジトリを変更したり、機密データ（プライベート脆弱性レポートなど）にアクセスするために、開発者に対して二要素認証（2FA）を要求する必要があります。推奨されませんが、2FAメカニズムは、SMSのような暗号化メカニズムを持たないメカニズムを使用することができます。 [require_2FA]

    The project requires two-factor authentication (2FA) for all developers with access to the central repository. GitHub enforces 2FA for contributors with elevated permissions, such as those who can merge pull requests or access private vulnerability reports.

    For more details, see the GitHub repository settings: https://github.com/nikhilxsunder/fedfred/settings.


    バッジには十分です！

    プロジェクトの2要素認証（2FA）は、偽装を防ぐために暗号化メカニズムを使用すべきです。ショート メッセージ サービス（SMS）ベースの2FA自体は、暗号化されていないため、この基準を満たしていません。 [secure_2FA]

    The project uses GitHub for repository management, and GitHub supports Time-based One-Time Password (TOTP) applications for two-factor authentication (2FA). Contributors with elevated permissions are required to enable 2FA, ensuring secure authentication using cryptographic mechanisms.

    For more details, see the GitHub repository settings: https://github.com/nikhilxsunder/fedfred/settings.


  • コーディング標準


    バッジには十分です！

    プロジェクトは、コードレビューの実施方法、チェックする必要があるもの、受け入れられる必要があるものなど、コードレビュー要件を文書化しなければなりません。 (URLが必要です) [code_review_standards]

    The project documents its code review requirements in the CONTRIBUTING.md file. The code review process includes the following:

    How Code Review is Conducted:

    All pull requests must be reviewed by at least one maintainer before merging. Reviews are conducted through GitHub's pull request review system. What Must Be Checked:

    Code must adhere to the project's coding standards (e.g., PEP 8, type hints, and docstrings). Static analysis tools (pylint, mypy, bandit) must pass without warnings. Tests must cover new functionality and pass successfully. Documentation must be updated for any new features or changes. Requirements for Acceptability:

    Code must be clear, concise, and maintainable. All tests must pass, and test coverage must meet the project's standards. Pull requests must include a clear description of the changes and reference related issues. For more details, see the code review section in the CONTRIBUTING.md file. https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md


    バッジには十分です！

    プロジェクトは、公開する前に、提案されたすべての変更の少なくとも50％を著作者以外の人がレビューして、それが価値のある変更であり、取り込みに反対する既知の問題がないかどうかを判断しなければなりません。 [two_person_review]

    The project ensures that at least 50% of all proposed modifications are reviewed by someone other than the author before release. This is documented in the CONTRIBUTING.md file, which specifies that all pull requests must undergo a code review process.

    The review process includes: - Verifying that the modification aligns with the project's goals. - Checking for adherence to coding standards and guidelines. - Ensuring the modification is free of known issues.

    For more details, see the code review section in the CONTRIBUTING.md file. https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md


  • 作業ビルドシステム


    バッジには十分です！

    プロジェクトが再現可能なビルドを持たなければなりません。ビルドが発生しない場合（たとえば、コンパイルされないでソースコードが直接使用されるスクリプト言語）、「該当なし」（N/A）を選択します。 (URLが必要です) [build_reproducible]

    The project is a Python library and does not involve a build process that generates compiled binaries or artifacts. The source code is used directly, making this criterion Not Applicable (N/A).

    For more details, see the repository: https://github.com/nikhilxsunder/fedfred.


  • 自動テスト スイート


    バッジには十分です！

    テストスイートは、その言語の標準的な方法で呼び出すことができなければなりません。 (URLが必要です) [test_invocation]

    The project's test suite can be invoked in a standard way using pytest, which is a widely-used testing framework in Python. The tests are run with the following command:

    pytest

    For more details, see the CONTRIBUTING.md file. https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md


    バッジには十分です！

    プロジェクトは、新しいコードまたは変更されたコードが頻繁に中央コードリポジトリに統合され、その結果に対して自動化されたテストが実行される、継続的な統合を実装しなければなりません。 (URLが必要です) [test_continuous_integration]

    The project implements continuous integration using GitHub Actions. Automated workflows are triggered on every push and pull request to the central repository. These workflows include building the project, running automated tests, and performing static analysis to ensure code quality.

    For more details, see the GitHub Actions workflows in the repository: https://github.com/nikhilxsunder/fedfred/actions.


    バッジには十分です！

    プロジェクトは、選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがある場合、少なくとも80％のステートメント カバレッジを提供するFLOSS自動テストスイートを備えていなければなりません。 [test_statement_coverage90]

    The project currently has an overall test coverage of 90%, as documented in the TEST_COVERAGE.md file.

    The project uses pytest with the pytest-cov plugin to measure test coverage, and contributors are encouraged to write tests for all new functionality and bug fixes to help meet this goal.


    バッジには十分です！

    選択された言語でこの基準を測定できる少なくとも1つのFLOSSツールがあれば、少なくとも80％のブランチカバレッジを提供するFLOSS自動テストスイートがプロジェクトに存在しなければなりません。 [test_branch_coverage80]

    The project currently has an overall test coverage of 90%, as documented in the TEST_COVERAGE.md file.

    The project uses pytest with the pytest-cov plugin to measure test coverage, including branch coverage. Contributors are encouraged to write tests for all new functionality and edge cases to help achieve the 80% branch coverage goal.


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

    一部のソフトウェアは暗号化メカニズムを使用する必要がないことに注意してください。あなたのプロジェクトが作成するソフトウェアが、(1) 暗号化機能を含む、アクティブ化する、または有効化し、(2) 米国（US）から米国外または米国市民以外にリリースされる可能性がある場合は、法的に義務付けられた追加手順の実行を要求される可能性があります。通常、これにはメールの送信が含まれます。詳細については、 Understanding Open Source Technology & US Export Controls（「オープンソース技術と米国の輸出管理について」）の暗号化のセクションを参照してください。

    バッジには十分です！

    プロジェクトで作成されたソフトウェアは、ネットワーク通信すべてに対して、SSHv2以降、TLS1.2以降 (HTTPS)、IPsec、SFTP、SNMPv3などのセキュア プロトコルをサポートしなければなりません。FTP、HTTP、telnet、SSLv3以前、SSHv1などのセキュアでないプロトコルは、デフォルトで無効にしておき、ユーザーが特別に設定した亜場合のみ有効にしなければなりません。プロジェクトによって作成されたソフトウェアがネットワーク通信をサポートしない場合は、「該当なし」（N/A）を選択します。 [crypto_used_network]

    The software produced by the project communicates with the FRED API exclusively over HTTPS, which uses TLS 1.2 or later for secure network communications. Insecure protocols such as HTTP are not supported. This ensures that all network communications are encrypted and secure by default.

    For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアは、TLSをサポートあるいは使用する場合、少なくともTLSバージョン1.2をサポートしなければなりません。TLSの前身は、SSLと呼ばれていたことに注意して下さい。ソフトウェアがTLSを使用ない場合、「該当なし」（N/A）を選択します。 [crypto_tls12]

    The software produced by the project communicates with the FRED API exclusively over HTTPS, which uses TLS 1.2 or later for secure communication. Therefore, this criterion is met. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.


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


    バッジには十分です！

    プロジェクトウェブサイト、リポジトリ（ウェブからアクセス可能な場合）、およびダウンロードサイト（別々の場合）には、許容できない値を持つキー強化ヘッダーが含まれていなければなりません。 (URLが必要です) [hardened_site]

    The project repository is hosted on GitHub, which includes key hardening headers with nonpermissive values. GitHub enforces the following security headers:

    1. Content Security Policy (CSP): Restricts the sources from which content can be loaded.
    2. HTTP Strict Transport Security (HSTS): Ensures all connections are made over HTTPS.
    3. X-Content-Type-Options: Set to "nosniff" to prevent MIME type sniffing.
    4. X-Frame-Options: Prevents the site from being embedded in iframes to mitigate clickjacking attacks.

    For verification, you can check the repository at: https://github.com/nikhilxsunder/fedfred.


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


    バッジには十分です！

    プロジェクトは過去5年間にセキュリティレビューを実施していなければなりません。このレビューは、セキュリティ要件とセキュリティ境界を考慮しなければならりません。 [security_review]

    The project has performed a security review within the last 5 years. This review included:

    1. Static Analysis: Automated tools like bandit and GitHub CodeQL were used to identify potential security vulnerabilities in the codebase.
    2. Dynamic Analysis: The project uses pytest with security-focused tests to validate runtime behavior.
    3. Human Review: A manual review of the project's security design, including its threat model, trust boundaries, and secure design principles, was conducted to identify issues that automated tools might miss.

    Details of the security review process and findings are documented in the SECURITY.md file.


    バッジには十分です！

    プロジェクトによって作成されたソフトウェアで強化メカニズムを使用しなければならないので、ソフトウェア欠陥がセキュリティ上の脆弱性を引き起こす可能性が低くなります。 (URLが必要です) [hardening]

    The project incorporates hardening mechanisms to reduce the likelihood of software defects resulting in security vulnerabilities:

    HTTP Security: The project enforces HTTPS for all API communications, ensuring secure data transmission. Static Analysis: Tools like bandit are used to identify and mitigate common security issues in Python code. Dependency Management: Regular updates and dependency scanning with GitHub Dependabot ensure that third-party libraries are secure. Type Safety: The use of Python type hints and static type checking with mypy helps prevent undefined behavior. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.


  • 動的コード分析


    バッジには十分です！

    プロジェクトは、リリース前にプロジェクトによって作成されたソフトウェアの主要な製品リリースに対して、少なくとも1つの動的解析ツールを適用しなければなりません。 [dynamic_analysis]

    Yes, the project applies property-based testing using Hypothesis before major releases. Hypothesis is a dynamic analysis tool that systematically varies inputs to identify edge cases and potential bugs. Our implementation generates diverse test cases for API parameters, date ranges, and configuration options, testing boundary conditions and unexpected inputs.

    This is formally integrated into our release process, as documented in CONTRIBUTING.md. We've created a dedicated GitHub workflow (dynamic-analysis.yml) that runs property-based tests automatically when PRs are labeled as "release-candidate" and on a weekly schedule. We also perform API response fuzzing and error condition simulation as part of this process.

    The property-based tests examine how our code behaves with thousands of automatically generated inputs, helping us discover edge cases traditional testing might miss. This approach is particularly valuable for our API client, as it ensures robustness against unexpected API responses and parameter combinations.


    バッジには十分です！

    プロジェクトは、生成するソフトウェアに多くの実行時アサーションを含めるべきであり、動的分析中にそれらのアサーションをチェックするべきです。 [dynamic_analysis_enable_assertions]

    Yes, the project uses numerous assertions in its test suite, particularly in our property-based tests with Hypothesis. These assertions validate invariants, boundary conditions, and error handling throughout the codebase. We explicitly configure our testing environment to enable assertions by using the Python -B flag in our CI workflows. Our CONTRIBUTING.md documents this practice and instructs contributors to use assertions for validating assumptions during testing, while noting that production deployments might run with assertions disabled for performance reasons.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Nikhil Sunder and the OpenSSF Best Practices badge contributors.

プロジェクト バッジ登録の所有者： Nikhil Sunder.
エントリの作成日時 2025-03-10 22:37:43 UTC、 最終更新日 2025-04-08 16:20:18 UTC 最後に2025-03-12 00:47:43 UTCにバッジ合格を達成しました。

もどる