fedfred

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 10158 est gold Voici comment l'intégrer :

Ce sont les critères du niveau Argent. Vous pouvez également afficher les critères des niveaux Basique ou Or.

        

 Notions de base 17/17

  • Identification

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

  • Conditions préalables


    Le projet DOIT atteindre un badge de niveau basique. [achieve_passing]

  • Contenu basique du site Web du projet


    Les informations sur la façon de contribuer DOIVENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute règle de codage requise). (URL requise) [contribution_requirements]

    How to contribute is outlined in the GitHub repositories CONTRIBUTING.md file. https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md


  • Supervision du projet


    Le projet DEVRAIT avoir un mécanisme juridique par lequel tous les développeurs de quantités non triviales de logiciel du projet affirment qu'ils sont légalement autorisés à effectuer ces contributions. L'approche la plus commune et facilement mise en œuvre pour ce faire est d'utiliser un Certificat d'origine du développeur (DCO), où les utilisateurs ajoutent une information « sign-off-by » dans leurs commits et le projet pointe vers le site Web du DCO. Cependant, cela PEUT être mis en œuvre en tant que contrat de licence de contributeur (CLA), ou tout autre mécanisme juridique. (URL requise) [dco]

    The project uses a Developer Certificate of Origin (DCO) to ensure that all contributors assert they are legally authorized to make contributions. Contributors are required to sign off on their commits using the git commit -s command, which appends a Signed-off-by line to the commit message. This indicates their agreement to the terms of the DCO.

    The DCO is documented in the repository and linked in the DCO.md file: https://github.com/nikhilxsunder/fedfred/blob/main/DCO.md. The CONTRIBUTING.md file also explains how to sign commits and includes a reference to the DCO: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md. Pull requests with unsigned commits are automatically flagged and cannot be merged until all commits are signed.

    For more information, see the Developer Certificate of Origin: https://developercertificate.org/.



    Le projet DOIT définir et documenter clairement son modèle de gouvernance de projet (la façon dont il prend ses décisions, y compris les rôles clés). (URL requise) [governance]

    The project follows a centralized governance model where the project owner and lead, Nikhil Sunder, makes all final decisions regarding the project's direction, contributions, and dispute resolution. This governance model is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    For more details on the contribution process and decision-making, contributors are encouraged to review the guidelines outlined in the CONTRIBUTING.md file.



    Le projet DOIT adopter un code de conduite et le publier dans un lieu standard. (URL requise) [code_of_conduct]

    The project has adopted the Contributor Covenant Code of Conduct, which sets expectations for behavior within the community and ensures a welcoming and inclusive environment. The Code of Conduct is posted in the repository at the following URL: https://github.com/nikhilxsunder/fedfred/blob/main/CODE_OF_CONDUCT.md.

    This document outlines acceptable and unacceptable behavior, enforcement responsibilities, and reporting mechanisms for addressing violations.



    Le projet DOIT clairement définir et documenter publiquement les rôles clés dans le projet et leurs responsabilités, y compris les tâches que ces rôles doivent accomplir. Il DOIT être clairement exprimé qui a quel(s) rôle(s), mais cela pourrait ne pas être documenté de la même manière. (URL requise) [roles_responsibilities]

    The project defines and documents key roles and responsibilities in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    The project owner and lead, Nikhil Sunder, is responsible for making final decisions regarding the project's direction, contributions, and dispute resolution. Contributors are encouraged to participate in discussions, submit pull requests, and follow the contribution guidelines outlined in the documentation. The governance model and roles are centralized, with the project owner retaining ultimate authority.



    Le projet DOIT pouvoir continuer avec une interruption minimale si une personne décède, est invalidée ou ne peut/veut plus continuer à maintenir le projet. En particulier, le projet DOIT être en mesure de créer et de fermer des problèmes, d'accepter les modifications proposées et de publier des versions du logiciel, dans un délai d'une semaine après confirmation du retrait d'un individu du projet. Cela PEUT être fait en s'assurant que quelqu'un d'autre possède les clés, les mots de passe et les droits juridiques nécessaires pour poursuivre le projet. Les personnes qui exécutent un projet FLOSS PEUVENT faire cela en fournissant des clés dans un coffre-fort et un testament fournissant les droits légaux nécessaires (par exemple, pour les noms DNS). (URL requise) [access_continuity]

    The project ensures continuity by maintaining shared access to critical resources, including repository administration, release management, and issue tracking. Multiple maintainers have access to the GitHub repository, ensuring that issues can be created and closed, proposed changes can be reviewed and merged, and new versions can be released without interruption.

    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, such as API keys and deployment tools, are securely stored and shared among trusted maintainers to ensure the project can continue in the event of the loss of support from any individual.



    Le projet DEVRAIT avoir un « bus factor » de 2 ou plus. (URL requise) [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.


  • Documentation


    Le projet DOIT avoir une feuille de route documentée qui décrit ce que le projet a l'intention de faire et ne pas faire pour au moins l'année suivante. (URL requise) [documentation_roadmap]

    The project has a documented roadmap outlining its goals and priorities for the next year. The roadmap is available at: https://github.com/nikhilxsunder/fedfred/blob/main/ROADMAP.md. It helps users and contributors understand the intended direction of the project and is updated as priorities evolve.



    Le projet DOIT inclure la documentation de l'architecture (aussi appelée conception de haut niveau) du logiciel produit par le projet. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). (URL requise) [documentation_architecture]

    The project includes documentation of its architecture in the README.md and the source directory. The README.md provides an overview of the project's features, including its modular design with components like FredAPI, FredMapsAPI, and data classes for structured outputs. The source directory contains detailed API references and usage examples, which describe the relationships between components and their functionality.

    For more details, see the documentation at: https://github.com/nikhilxsunder/fedfred/blob/main/README.md and https://nikhilxsunder.github.io/fedfred/.



    Le projet DOIT documenter ce à quoi l'utilisateur peut et ne peut pas s'attendre en termes de sécurité à partir du logiciel produit par le projet (ses « exigences de sécurité »). (URL requise) [documentation_security]

    The project documents its security requirements in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

    This document outlines what users can and cannot expect in terms of security, including:

    1. Security Measures:

      • Enforced certificate verification for all HTTP clients.
      • Strict validation of API parameters and responses.
      • Regular dependency scanning and updates to address vulnerabilities.
    2. User Responsibilities:

      • Secure storage of API keys (e.g., using environment variables).
      • Avoiding hardcoding sensitive information in scripts.
    3. Limitations:

      • The software does not provide encryption for user data beyond HTTPS communication.
      • Users are responsible for securing their runtime environments.

    For more details, refer to the SECURITY.md file.



    Le projet DOIT fournir un guide de « démarrage rapide » pour les nouveaux utilisateurs afin de les aider à faire rapidement quelque chose avec le logiciel. (URL requise) [documentation_quick_start]

    The project provides a "Quick Start" guide in the quickstart.rst file, which is also available in the online documentation. The guide helps new users quickly set up the library, initialize the API client, and fetch data from the FRED API. It includes examples for both synchronous and asynchronous usage.

    The Quick Start guide can be accessed at: https://nikhilxsunder.github.io/fedfred/quickstart/.



    Le projet DOIT faire un effort pour maintenir la documentation conforme à la version actuelle des résultats du projet (y compris les logiciels produits par le projet). Tous les défauts de la documentation connus la rendant incohérente DOIVENT être corrigés. Si la documentation est généralement à jour, mais inclut de manière erronée certaines informations antérieures qui ne sont plus vraies, considérez cela comme un défaut, puis faites le suivi et corrigez comme d'habitude. [documentation_current]

    The project makes an effort to keep its documentation consistent with the current version of the software. The documentation is regularly updated to reflect changes in functionality, as evidenced by the CHANGELOG.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CHANGELOG.md.

    Additionally, the project maintains a dedicated ROADMAP.md file: https://github.com/nikhilxsunder/fedfred/blob/main/ROADMAP.md, which outlines future goals and priorities. Any known documentation defects are tracked and addressed as part of the development process. The documentation also includes version-specific details and links to older versions where applicable.



    La page d'accueil et/ou le site Web du dépôt du projet DOIVENT identifier et pointer tous les accomplissements, y compris ce badge sur les meilleures pratiques, dans les 48 heures suivant la reconnaissance publique que l'accomplissement a été atteint. (URL requise) [documentation_achievements]

    The project identifies and hyperlinks to its achievements, including the OpenSSF Best Practices badge, on the repository's front page in the README.md file. The badge is displayed prominently at the top of the file, along with other status badges.

    The README.md file can be accessed at: https://github.com/nikhilxsunder/fedfred/blob/main/README.md.


  • Accessibilité et internationalisation


    Le projet (à la fois les sites du projet et les résultats du projet) DEVRAIT suivre les meilleures pratiques d'accessibilité afin que les personnes handicapées puissent encore participer au projet et utiliser les résultats du projet où il est raisonnable de le faire. [accessibility_best_practices]

    This project is a Python library and does not produce a GUI or web-based application. As such, accessibility best practices for GUIs or web applications, such as WCAG 2.0 guidelines, are not directly applicable. However, the project documentation and results are designed to be accessible:

    1. Documentation: The documentation is written in clear, concise language and is accessible via standard web browsers. It includes text alternatives for images (e.g., alt text for the project logo) and follows a consistent heading hierarchy for screen readers.

    2. Library Design: The library is designed for use in command-line and programmatic environments, which are inherently accessible to users with assistive technologies like screen readers.

    For these reasons, this criterion is marked as Not Applicable (N/A).



    Le logiciel produit par le projet DEVRAIT être internationalisé pour permettre une localisation facile pour la culture, la région ou la langue du public cible. Si l'internationalisation (i18n) ne s'applique pas (par exemple, le logiciel ne génère pas de texte destiné aux utilisateurs finaux et ne trie pas de texte lisible par les humains), sélectionnez « non applicable » (N/A). [internationalization]

    The software produced by the project is a Python library intended for developers and does not generate text intended for end-users or require sorting of human-readable text. As such, internationalization (i18n) does not apply. This criterion is marked as Not Applicable (N/A).


  • Autre


    Si les sites du projet (site Web, dépôt et URL de téléchargement) entreposent des mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être entreposés comme hachages itérés avec salage par utilisateur en utilisant un algorithme d'étirement des clés (itéré) (par exemple, Argon2id, Bcrypt, Scrypt, ou PBKDF2). Si les sites du projet n'entreposent pas de mots de passe à cette fin, sélectionnez « non applicable » (N/A). [sites_password_security]

    The project does not store passwords for the authentication of external users on its sites (e.g., website, repository, or download URLs). Authentication is handled through GitHub, which meets this criterion. Therefore, this criterion is marked as Not Applicable (N/A).


  • Versions précédentes


    Le projet DOIT maintenir les anciennes versions les plus utilisées du produit ou fournir un chemin de mise à niveau vers des versions plus récentes. Si le chemin de mise à niveau est difficile, le projet DOIT documenter comment effectuer la mise à niveau (par exemple, les interfaces qui ont changé et une suggestion d'étapes détaillées pour aider la mise à niveau). [maintenance_or_update]

    The project maintains older versions of the product and provides an upgrade path to newer versions. The CHANGELOG.md file (https://github.com/nikhilxsunder/fedfred/blob/main/CHANGELOG.md) documents all changes, including new features, bug fixes, and deprecated functionality, to help users understand what has changed between versions.

    For major updates that introduce breaking changes, the project follows Semantic Versioning and includes detailed instructions in the CHANGELOG.md to guide users through the upgrade process. This ensures users can either continue using older versions or transition smoothly to newer ones.


  • Procédure de signalement des bogues


    Le projet DOIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]
  • Processus de signalement de vulnérabilité


    Le projet DOIT créditer les auteurs de tous les signalements de vulnérabilité résolus au cours des 12 derniers mois, à l'exception des auteurs qui demandent l'anonymat. S'il n'y a pas eu de vulnérabilité résolue au cours des 12 derniers mois, sélectionnez « non applicable » (N/A). (URL requise) [vulnerability_report_credit]

    The project has not resolved any reported vulnerabilities in the last 12 months. Therefore, this criterion is marked as Not Applicable (N/A).

    For future reference, the project documents vulnerability reports and credits reporters in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.



    Le projet DOIT avoir un processus documenté pour répondre aux signalements de vulnérabilité. (URL requise) [vulnerability_response_process]

    The project has a documented process for responding to vulnerability reports in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

    The process includes the following steps:

    1. Reporting: Vulnerabilities must be reported via email to nsunder724@gmail.com, not through public GitHub issues.
    2. Acknowledgment: The project team will acknowledge receipt of the report within 48 hours.
    3. Verification: The team will verify the vulnerability and assess its impact.
    4. Remediation: A fix will be developed and tested.
    5. Disclosure: The team will coordinate with the reporter on the disclosure timeline and credit the reporter unless anonymity is requested.

    This ensures a clear and structured approach to handling vulnerabilities.


  • Normes de codage


    Le projet DOIT identifier les guides de style de codage spécifiques pour les langages principaux qu'il utilise, et exiger que les contributions le respectent en général. (URL requise) [coding_standards]

    The project identifies and enforces coding standards in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    The project adheres to the following coding style guides:

    1. PEP 8: The official Python style guide for code readability and consistency.
    2. PEP 257: For docstring conventions, including parameter descriptions, return values, and examples.
    3. Type Hints (PEP 484): All functions must include type annotations for parameters and return values.

    The CONTRIBUTING.md file also specifies the use of tools like pylint, mypy, and bandit to enforce these standards and ensure compliance. Contributors are required to run these tools before submitting pull requests.



    Le projet DOIT imposer automatiquement son ou ses styles de codage sélectionnés s'il existe au moins un outil FLOSS qui peut le faire dans le(s) langage(s) sélectionné(s). [coding_standards_enforced]

    The project automatically enforces its selected coding styles using the following tools, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    1. Pylint: Enforces PEP 8 compliance and general code quality. A minimum score of 9.0+ is required for all code.
    2. Mypy: Enforces type checking to ensure compliance with PEP 484.
    3. Bandit: Performs security-focused static analysis to identify common security issues.

    These tools are integrated into the development workflow via pre-commit hooks and GitHub Actions workflows. All pull requests are automatically checked for compliance, and any exceptions must be explicitly documented in the code with comments explaining the rationale.


  • Système de construction opérationnel


    Les systèmes de construction pour les binaires natifs DOIVENT honorer les variables (d'environnement) pertinentes du compilateur et du lieur qui leur sont transmises (par exemple, CC, CFLAGS, CXX, CXXFLAGS et LDFLAGS) et les transmettre aux invocations du compilateur et du lieur. Un système de construction PEUT les étendre avec des options supplémentaires ; il NE DOIT PAS simplement remplacer les valeurs fournies par les siennes. Si aucun fichier binaire natif n'est généré, sélectionnez « non applicable » (N/A). [build_standard_variables]

    The project does not generate native binaries, as it is a Python library. Therefore, this criterion is marked as Not Applicable (N/A).



    Le système de construction et d'installation DEVRAIT préserver les informations de débogage si elles sont demandées dans les options correspondants (par exemple, « install -s » n'est pas utilisé). S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_preserve_debug]

    The project is a Python library and does not involve a build or installation system that generates native binaries. Therefore, this criterion is marked as Not Applicable (N/A).



    Le système de construction pour le logiciel produit par le projet NE DOIT PAS reconstruire de manière récursive des sous-répertoires s'il existe des dépendances croisées dans les sous-répertoires. S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_non_recursive]

    The project is a Python library and does not use a build system that involves recursive builds or subdirectory dependencies. Therefore, this criterion is marked as Not Applicable (N/A).



    Le projet DOIT pouvoir répéter le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Si aucune construction ne se produit (par exemple, dans les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). [build_repeatable]

    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).


  • Système d'installation


    Le projet DOIT fournir un moyen d'installer et de désinstaller facilement le logiciel produit par le projet en utilisant une convention couramment utilisée. [installation_common]

    The project provides an easy way to install and uninstall the software using commonly-used conventions:

    Using pip: The software can be installed and uninstalled via the Python package manager pip, which is widely used in the Python ecosystem.

    Installation: pip install fedfred Uninstallation: pip uninstall fedfred Using conda: The software is available on Conda-Forge, allowing installation and uninstallation via the conda package manager.

    Installation: conda install -c conda-forge fedfred Uninstallation: conda remove fedfred Detailed installation instructions are documented in the README.md file: https://github.com/nikhilxsunder/fedfred/blob/main/README.md and the installation.rst file in the documentation: https://nikhilxsunder.github.io/fedfred/installation/.



    Le système d'installation pour les utilisateurs finaux DOIT honorer les conventions standard pour sélectionner l'emplacement où les artefacts construits sont écrits au moment de l'installation. Par exemple, s'il installe des fichiers sur un système POSIX, il DOIT honorer la variable d'environnement DESTDIR. S'il n'y a pas de système d'installation ou pas de convention standard, sélectionnez « non applicable » (N/A). [installation_standard_variables]

    The installation system for end-users MUST honor standard conventions for selecting the location where built artifacts are written to at installation time. For example, if it installs files on a POSIX system it MUST honor the DESTDIR environment variable. If there is no installation system or no standard convention, select "not applicable" (N/A). [installation_standard_variables]



    Le projet DOIT fournir un moyen pour les développeurs potentiels d'installer rapidement tous les résultats du projet ainsi que l'environnement nécessaire pour apporter des modifications, y compris les tests et l'environnement de test. Cela DOIT être effectué avec une convention couramment utilisée. [installation_development_quick]

    The project provides a quick and straightforward way for developers to install all necessary dependencies and set up the development environment using commonly-used conventions. This is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    Development Setup:

    1. Using Poetry:

      • Clone the repository: git clone https://github.com/nikhilxsunder/fedfred.git
      • Navigate to the project directory: cd fedfred
      • Install dependencies: poetry install
      • Run tests: poetry run pytest
    2. Using Conda:

      • Clone the repository: git clone https://github.com/nikhilxsunder/fedfred.git
      • Navigate to the project directory: cd fedfred
      • Create a Conda environment: conda create -n fedfred-dev python=3.9
      • Activate the environment: conda activate fedfred-dev
      • Install dependencies: pip install -e ".[dev,types]"
      • Run tests: pytest

    These steps ensure that developers can quickly set up the environment and run tests to start contributing to the project.


  • Composants maintenus à l'extérieur


    Le projet DOIT afficher ses dépendances externes de manière analysable par ordinateur. (URL requise) [external_dependencies]

    The project lists its external dependencies in a computer-processable way using pyproject.toml and poetry.lock files. These files are compatible with the Poetry package manager and specify all required dependencies, including their versions and groups (e.g., main, dev).

    The pyproject.toml file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/pyproject.toml.
    The poetry.lock file can be found at: https://github.com/nikhilxsunder/fedfred/blob/main/poetry.lock.



    Les projets DOIVENT surveiller ou vérifier périodiquement leurs dépendances externes (y compris les copies de commodité) pour détecter les vulnérabilités connues, et corriger les vulnérabilités exploitables ou les vérifier comme inexploitables. [dependency_monitoring]

    The project monitors its external dependencies for known vulnerabilities using automated tools and processes:

    GitHub Dependabot: Automatically scans dependencies for vulnerabilities and creates pull requests to update them when issues are detected. CodeQL: Performs security analysis on the codebase, including dependency vulnerabilities. Poetry: Dependency management ensures that only compatible and secure versions of packages are installed. These tools are integrated into the project's workflows and run regularly to ensure that vulnerabilities are detected and addressed promptly. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.



    Le projet DOIT :
    1. rendre facile l'identification et la mise à jour des composants maintenus extérieurement au projet ; ou
    2. utiliser des composants standards fournis par le système ou le langage de programmation.
    Ensuite, si une vulnérabilité se trouve dans un composant réutilisé, il sera facile de mettre à jour ce composant. [updateable_reused_components]

    The project meets this criterion by using standard Python package management systems, such as pip and poetry, to manage external dependencies. All reused components are listed in the pyproject.toml and poetry.lock files, making it easy to identify and update them. These files ensure that dependencies are managed in a centralized and consistent manner.

    Additionally, the project uses GitHub Dependabot to automatically monitor and suggest updates for dependencies when vulnerabilities or new versions are detected. For more details, see the pyproject.toml file: https://github.com/nikhilxsunder/fedfred/blob/main/pyproject.toml.



    Le projet DEVRAIT éviter d'utiliser des fonctions et des API obsolètes quand des alternatives FLOSS sont disponibles dans l'ensemble de technologies qu'il utilise (sa « pile de technologies ») et disponibles à une large majorité des utilisateurs supportés par le projet (afin que les utilisateurs puissent avoir accès à l'alternative). [interfaces_current]

    The project avoids using deprecated or obsolete functions and APIs by adhering to modern Python standards and regularly updating its dependencies. The project uses tools like pylint, mypy, and bandit to identify deprecated or unsafe code patterns. Additionally, dependency updates are managed through poetry and monitored using GitHub Dependabot to ensure compatibility with the latest versions of libraries.

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


  • Suite de tests automatisée


    Une suite de tests automatisée DOIT être appliquée à chaque commit dans un dépôt partagé pour au moins une branche. Cette suite de tests DOIT produire un rapport sur le succès ou l'échec du test. [automated_integration_testing]

    The project applies an automated test suite on each check-in to the shared repository for the main branch. This is implemented using GitHub Actions workflows, which run the test suite automatically on every push and pull request. The test suite uses pytest and generates a report on test success or failure.

    For more details, see the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md and the GitHub Actions workflows in the repository: https://github.com/nikhilxsunder/fedfred/actions.



    Le projet DOIT ajouter des tests de régression à une suite de tests automatisée pour au moins 50% des bogues corrigés au cours des six derniers mois. [regression_tests_added50]

    The project includes regression tests for bugs fixed within the last six months as part of its automated test suite. All new functionality and bug fixes are required to have corresponding tests, as documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    Additionally, the CHANGELOG.md file (https://github.com/nikhilxsunder/fedfred/blob/main/CHANGELOG.md) tracks bug fixes, and the associated tests are added to the tests directory to ensure coverage and prevent regressions.



    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage80]

    The project currently has an overall test coverage of 40%, as documented in the TEST_COVERAGE.md file: https://github.com/nikhilxsunder/fedfred/blob/main/TEST_COVERAGE.md. While the project does not yet meet the 80% statement coverage requirement, efforts are underway to improve test coverage, with a goal of achieving at least 80% overall coverage.

    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.


  • Nouveau test de fonctionnalité


    Le projet DOIT avoir une politique écrite formelle, que dès qu'une nouvelle fonctionnalité majeure est ajoutée, des tests pour la nouvelle fonctionnalité DOIVENT être ajoutés à une suite de tests automatisée. [test_policy_mandated]

    The project has a formal written policy requiring that tests for all new functionality be added to the automated test suite. This policy is documented in the CONTRIBUTING.md file: https://github.com/nikhilxsunder/fedfred/blob/main/CONTRIBUTING.md.

    The policy states:

    • All new functionality must include appropriate tests in the automated test suite.
    • Tests should cover both success and error conditions, including edge cases.
    • Pull requests without adequate test coverage will not be merged.

    This ensures that the test suite remains comprehensive and up-to-date as the project evolves.



    Le projet DOIT inclure, dans ses instructions documentées pour les propositions de changement, la politique selon laquelle des tests doivent être ajoutés pour toute nouvelle fonctionnalité majeure. [tests_documented_added]
  • Options d'avertissement


    Les projets DOIVENT être maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]

    Yes, the project uses maximum strictness with warnings where practical. We enforce a high pylint score (9.0+), use strict type checking in mypy (with most error flags enabled), and run thorough security checks with bandit. These strict settings are enforced in CI for all PRs, and our CONTRIBUTING.md document explicitly requires all new code to pass these strict checks.


  • Connaissance du développement sécurisé


    Le projet DOIT implémenter des principes de conception sécurisés (à partir de « know_secure_design »), quand cela est approprié. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). [implement_secure_design]

    The project implements secure design principles as outlined in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md. These principles include:

    1. Fail-Safe Defaults: The API client enforces secure defaults, such as HTTPS for all communications and strict parameter validation.
    2. Complete Mediation: All API requests verify authentication and authorization, ensuring no bypassable access points.
    3. Economy of Mechanism: The codebase is modular and avoids unnecessary complexity, focusing on simplicity and maintainability.
    4. Separation of Privilege: The project recommends storing API keys in environment variables or secure vaults, separate from application code.
    5. Open Design: The project is open source, relying on proper key management and secure practices rather than obscurity.

    These principles ensure that the software is secure by design and adheres to best practices for secure development.


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]

    The project does not depend on cryptographic algorithms or modes with known serious weaknesses. It uses secure cryptographic libraries provided by Python's standard library or well-maintained third-party libraries, such as cryptography or hashlib, which default to secure algorithms like SHA-256 or AES-GCM.

    For more details on the project's security practices, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.



    Le projet DEVRAIT supporter plusieurs algorithmes cryptographiques, afin que les utilisateurs puissent rapidement changer si l'un deux est cassé. Les algorithmes à clés symétriques courants incluent AES, Twofish et Serpent. Les alternatives d'algorithme de hachage cryptographique courantes incluent SHA-2 (y compris SHA-224, SHA-256, SHA-384 ET SHA-512) et SHA-3. [crypto_algorithm_agility]

    The project does not directly implement cryptographic algorithms but relies on well-maintained Python libraries like cryptography and hashlib for cryptographic operations. These libraries support multiple cryptographic algorithms, including AES, SHA-2, and SHA-3, ensuring algorithm agility. Users can leverage these libraries to switch algorithms if needed. For more details, see the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.



    Le projet DOIT supporter le stockage des informations d'authentification (comme les mots de passe et les jetons dynamiques) et des clés cryptographiques privées dans des fichiers distincts des autres informations (fichiers de configuration, bases de données et journaux) et permettre aux utilisateurs de les mettre à jour et de les remplacer sans recompilation de code. Si le projet ne traite jamais d'informations d'authentification et de clés cryptographiques privées, sélectionnez « non applicable » (N/A). [crypto_credential_agility]

    The project processes authentication credentials, such as API keys, but does not store them directly. It supports storing these credentials separately from other information by recommending the use of environment variables or secure vaults. Users can update and replace these credentials without requiring code recompilation. This is documented in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.



    Le logiciel produit par le projet DEVRAIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DEVRAIENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (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.



    Le logiciel produit par le projet DEVRAIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (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.



    Le logiciel produit par le projet DOIT, s'il prend en charge TLS, effectuer la vérification des certificats TLS par défaut lors de l'utilisation de TLS, y compris sur les sous-ressources. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_certificate_verification]

    The software produced by the project supports TLS and performs TLS certificate verification by default for all HTTPS communications. This ensures secure connections when interacting with the FRED API and other resources. Certificate verification is enforced by the underlying HTTP client library (httpx) used in the project.

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



    Le logiciel produit par le projet DOIT, s'il supporte TLS, effectuer une vérification de certificat avant d'envoyer des en-têtes HTTP avec des informations privées (telles que des cookies sécurisés). Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_verification_private]

    The software produced by the project supports TLS and performs certificate verification before sending HTTP headers with private information. This is enforced by the underlying HTTP client library (httpx), which ensures that all HTTPS connections verify certificates by default.

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


  • Livraison sécurisée


    Le projet DOIT signer cryptographiquement les versions des résultats du projet destinées à une utilisation répandue, et il DOIT y avoir un processus documenté expliquant aux utilisateurs comment ils peuvent obtenir les clés de signature publique et vérifier la ou les signatures. La clé privée pour ces signature(s) NE DOIT PAS être sur le(s) site(s) utilisé(s) pour distribuer directement le logiciel au public. Si les versions ne sont pas destinées à une utilisation répandue, sélectionnez « non applicable » (N/A). [signed_releases]

    The project cryptographically signs its releases intended for widespread use. All releases are signed with a GPG key, and the public key is made available for users to verify the signatures. The process for obtaining the public signing key and verifying signatures is documented in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

    To verify a release:

    1. Download the public GPG key from: https://raw.githubusercontent.com/nikhilxsunder/fedfred/main/fedfred_public_key.asc.
    2. Import the key: gpg --import fedfred_public_key.asc.
    3. Verify the release signature using: gpg --verify <release>.asc <release>.

    The private key used for signing is securely stored and is not present on public distribution sites.



    Il est PROPOSÉ que, dans le système de contrôle de la version, chaque tag d'une version importante (un tag faisant partie d'une version majeure, d'une version mineure ou qui corrige des vulnérabilités notées publiquement) soit cryptographiquement signé et vérifiable comme décrit dans signed_releases. [version_tags_signed]

    The project cryptographically signs important version tags using GPG. Each release is signed and can be verified by users to ensure authenticity. The process for verifying signed tags is documented in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

    To verify a signed tag:

    Download the public GPG key: https://raw.githubusercontent.com/nikhilxsunder/fedfred/main/fedfred_public_key.asc. Import the key: gpg --import fedfred_public_key.asc. Verify the tag: git tag -v . This ensures that all major, minor, and vulnerability-fix releases are securely signed and verifiable.


  • Autres problèmes de sécurité


    Les résultats du projet DOIVENT vérifier toutes les entrées provenant de sources potentiellement non fiables pour s'assurer qu'elles sont valides (une liste blanche) et rejeter les entrées non valides, en cas de restrictions sur les données. [input_validation]

    The project ensures input validation by implementing strict checks on all inputs from potentially untrusted sources. This is done using an allowlist approach, where inputs are validated against predefined rules and constraints. For example:

    Parameter Validation: The __parameter_validation method in the FredAPI class validates all API parameters, ensuring they meet specific criteria such as type, format, and value ranges. Type Annotations: The project uses Python's type hints (PEP 484) to enforce correct data types for function parameters and return values. Custom Validation Logic: Inputs like dates, category IDs, and series IDs are validated for format and logical correctness (e.g., valid date formats, non-negative integers). These validation mechanisms ensure that invalid or malicious inputs are rejected before processing. For more details, see the fedfred.py file: https://github.com/nikhilxsunder/fedfred/blob/main/src/fedfred/fedfred.py.



    Les mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. [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.



    Le projet DOIT fournir une analyse de fiabilité qui justifie pourquoi ses exigences de sécurité sont respectées. L'analyse de fiabilité DOIT inclure : une description du modèle de menace, une identification claire des limites de confiance, un argument selon lequel des principes de conception sécurisés ont été appliqués et un argument selon lequel les faiblesses de sécurité courantes de l'implémentation ont été contrées. (URL requise) [assurance_case]

    The project provides an assurance case that justifies why its security requirements are met in the SECURITY.md file: https://github.com/nikhilxsunder/fedfred/blob/main/SECURITY.md.

    The assurance case includes:

    Threat Model: The SECURITY.md file identifies potential threats, such as insecure API key handling, injection in API parameters, and certificate verification bypass. Trust Boundaries: The document defines trust boundaries, such as the separation of API keys from application code and the use of HTTPS for all communications. Secure Design Principles: The project follows secure design principles, including fail-safe defaults, complete mediation, and separation of privilege, as outlined in the Security Design Principles section. Countering Common Weaknesses: The project addresses common implementation security weaknesses, such as dependency vulnerabilities, insecure deserialization, and regular expression denial of service (ReDoS), through dependency scanning, strict input validation, and careful design. This comprehensive assurance case demonstrates the project's commitment to meeting its security requirements.


  • Analyse statique de code


    Le projet DOIT utiliser au moins un outil d'analyse statique avec des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé, s'il existe au moins un outil FLOSS qui peut mettre en œuvre ce critère dans le langage sélectionné. [static_analysis_common_vulnerabilities]

    Yes, the project uses Bandit, a security-focused static analysis tool specifically designed to detect common vulnerabilities in Python code. Bandit is configured in our development environment, integrated into our pre-commit hooks, and runs automatically in our CI/CD pipeline. This helps us identify security issues early in the development process, as documented in our CONTRIBUTING.md file.


  • Analyse dynamique de code


    Si le logiciel produit par le projet inclut un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple C ou C++), alors le projet DOIT utiliser au moins un outil dynamique (par exemple, un fuzzer ou un scanneur d'application Web) utilisé de manière routinière en combinaison avec un mécanisme permettant de détecter des problèmes de sécurité mémoire tels que les dépassement mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, sélectionnez « non applicable » (N/A). [dynamic_analysis_unsafe]

    Python is memory safe.



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.

Soumission du badge du projet appartenant à : Nikhil Sunder.
Soumission créée le 2025-03-10 22:37:43 UTC, dernière mise à jour le 2025-04-08 16:20:18 UTC. Le dernier badge obtenu l'a été le 2025-03-12 00:47:43 UTC.

Retour