sentinel

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

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
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 14063 est passing Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14063/badge)](https://www.bestpractices.dev/projects/14063)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14063"><img src="https://www.bestpractices.dev/projects/14063/badge"></a>


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

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base 0/5

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    The security update management platform for SUSE and openSUSE Linux distributions

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.
  • Conditions préalables


    Le projet DOIT atteindre un badge de niveau argent. [achieve_silver]

  • Supervision du projet


    Le projet DOIT avoir un « facteur bus » de 2 ou plus. (URL requise) [bus_factor]
    Un « bus factor » (aussi connu en tant que « truck factor ») est le nombre minimum de membres du projet qui doivent disparaître soudainement d'un projet (« écrasé par un bus ») avant que le projet ne se bloque en raison du manque de personnel compétent. L'outil truck-factor peut l'estimer pour des projets sur GitHub. Pour plus d'informations, voir Évaluation du « bus factor » des dépôts Git par Cosentino et al.

    The project has a bus factor of 1 — a single maintainer (StayPirate) with sole repository admin access, release credentials, and merge authority. No second person has the necessary permissions to create releases, merge PRs, or manage the repository infrastructure. This is the same underlying gap as the previous criterion.



    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]
    Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

    Sentinel currently has a single primary contributor/maintainer. There are no two unassociated significant contributors to the project. This is consistent with the "Unmet" bus factor criterion noted earlier — both reflect the single-maintainer reality of the project's current stage.


  • Autre


    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. [license_per_file]
    Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

    Sentinel source files do not currently include SPDX license identifiers. The project has a top-level LICENSE file (MIT) but individual source files lack per-file license statements.


 Contrôle des modifications 3/4

  • Dépôt source public sous contrôle de version


    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

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



    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. (URL requise) [small_tasks]
    Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.

    Sentinel does not currently use GitHub's "good first issue" label or any equivalent mechanism to identify tasks suitable for new or casual contributors. There are no labeled issues marking small, approachable tasks.



    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [require_2FA]

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]



    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]
    Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge TOTP.

    The project's GitHub organization/account uses GitHub's two-factor authentication, which supports cryptographic mechanisms — TOTP (time-based one-time passwords via authenticator apps), hardware security keys (WebAuthn/FIDO2), and GitHub Mobile push notifications. SMS-based 2FA is not relied upon as the sole mechanism. GitHub's 2FA enforcement has been mandatory for all contributors since 2023.


 Qualité 6/7

  • Normes de codage


    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]
    Voir aussi two_person_review et contribution_requirements.

    Sentinel's code review requirements are comprehensively documented in CONTRIBUTING.md (https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md), which references the detailed conventions. The full review process includes:

    • Automated reviewer agents: 15+ specialized reviewer agents (security, design, data-model, test, API convention, spec coherence, docs, etc.) are invoked per guardrail rules defined in AGENTS.md (https://github.com/StayPirate/sentinel/blob/master/AGENTS.md) — each guardrail specifies when to invoke which reviewer and what must be checked
    • What must be checked: mandatory testing for all changes (Guardrail 6), security review for security-sensitive code (Guardrail 10), data model review for schema changes (Guardrail 8), documentation completeness (Guardrail 9), spec coherence (Guardrail 15), API convention conformity (Guardrail 20), and more
    • Acceptance criteria: all CI checks must pass (ruff, mypy --strict, bandit, pip-audit, pytest), applicable reviewer agents must be invoked and findings addressed, PR description must include test evidence and manual verification notes
    • PR requirements: documented in docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md) (Pull Request Requirements) — title format, issue linkage, scope summary, reviewer results, verification evidence
    • Finding evaluation: Guardrail 26 documents how reviewer findings are evaluated — independent verification, discard criteria, proportionality, escalation procedure
    • CI enforcement: required status checks on master branch protection (7 checks), conversation resolution required before merge

    URL: https://github.com/StayPirate/sentinel/blob/master/CONTRIBUTING.md



    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [two_person_review]

    Branch protection on master requires a pull request before merge, but the required approvals count is set to 0. This means a PR author can merge their own changes without any non-author human review. The project is currently single-maintainer, which makes enforcing non-author approval impractical (there is no second person to approve), but the criterion as stated is not satisfied by the current configuration. [osps_qa_07_01]


  • Système de construction opérationnel


    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]
    Une construction reproductible signifie que plusieurs parties peuvent refaire indépendamment le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Dans certains cas, cela peut être résolu en forçant un ordre de tri. Les développeurs JavaScript peuvent envisager d'utiliser npm shrinkwrap et webpack OccurenceOrderPlugin. Les utilisateurs GGC et clang peuvent trouver l'option -frandom-seed utile. L'environnement de construction (y compris le jeu d'outils) peut souvent être défini pour les parties externes en spécifiant le hachage cryptographique d'un conteneur spécifique ou d'une machine virtuelle qu'ils peuvent utiliser pour la reconstruction. Le projet de construction reproductible dispose de documentation sur la façon de le faire.

    Sentinel is a pure Python application — the source code is interpreted directly, not compiled into binary artifacts. There is no compilation step that would produce build output requiring bit-for-bit reproducibility. The Docker image build installs Python packages from a lockfile (uv.lock) but the application itself has no build/compilation phase.


  • Suite de tests automatisée


    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. (URL requise) [test_invocation]
    Par exemple, « make check », « mvn test » ou « rake test » (Ruby).

    Sentinel's test suite is invocable using pytest, the standard Python testing framework:

    • Standard invocation: cd backend && uv run pytest — the conventional command documented in the project
    • Configuration: test settings are defined in backend/pyproject.toml (https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.toml) under [tool.pytest.ini_options], following the standard pytest configuration convention
    • CI invocation: the CI pipeline (.github/workflows/ci.yml) invokes the same uv run pytest command with coverage flags
    • Markers: tests use standard pytest markers (@pytest.mark.unit, @pytest.mark.integration, @pytest.mark.e2e) for selective execution

    URL: https://github.com/StayPirate/sentinel/blob/master/backend/pyproject.tomlard invocation is required.



    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. (URL requise) [test_continuous_integration]
    Dans la plupart des cas, cela signifie que chaque développeur qui travaille à plein temps sur le projet intègre son code au moins tous les jours.

    Sentinel implements continuous integration via GitHub Actions. Every push and pull request to master triggers the CI pipeline, which runs the full automated test and analysis suite:

    • Linting: ruff check . + ruff format --check .
    • Static type checking: mypy --strict
    • Security analysis: bandit (SAST) + pip-audit (SCA)
    • Shell analysis: shellcheck + shfmt -d + actionlint
    • Automated tests: uv run pytest (850+ tests with coverage)
    • Container scanning: Trivy image scan
    • PR title validation: Conventional Commits format enforcement
    • PR metadata validation: issue linkage requirement

    Branch protection on master requires 7 status checks to pass before merge. All changes arrive via pull request with squash merge — no direct pushes to master.

    URL: https://github.com/StayPirate/sentinel/blob/master/.github/workflows/ci.yml



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

    Sentinel achieves 99% statement coverage (98.99% measured precisely), well above the 90% threshold. Coverage is measured by pytest-cov (a FLOSS tool) and enforced in CI with a minimum threshold of 85%. Results are uploaded to Codecov on every CI run. The latest successful CI run shows TOTAL: 3113 statements, 27 missed, 568 branches, 10 missed — 99% coverage.

    URL: https://app.codecov.io/github/staypirate/sentinel



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

    From the same CI run, Sentinel's test suite achieves high branch coverage as well. The coverage report shows 568 branches, 10 missed — which is 98% branch coverage, well above the 80% threshold. Branch coverage is measured by pytest-cov (a FLOSS tool) using the --cov-branch flag, and results are uploaded to Codecov on every CI run.


 Sécurité 5/5

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

    Le logiciel produit par le projet DOIT 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 DOIVENT ê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]

    Sentinel supports secure protocols for all network communications and does not enable insecure protocols by default:

    • API server: serves over HTTPS; TLS configuration is handled at the deployment layer (reverse proxy / load balancer)
    • External service integrations: all HTTP clients (IBS, SMELT, AIMAAS, NVD, MITRE, Bugzilla, etc.) use HTTPS exclusively. The networking infrastructure (docs/features/platform/networking.md) configures TLS with certificate verification enabled by default
    • Database: connects to PostgreSQL via asyncpg, which supports TLS connections (sslmode parameter in DATABASE_URL)
    • Redis: connects via REDIS_URL, which supports rediss:// (TLS) scheme
    • RabbitMQ: connects via IBS_RABBITMQ_URL, which supports amqps:// (TLS) scheme
    • Git transport: git-based fetchers clone via HTTPS
    • No insecure defaults: no HTTP, FTP, telnet, or unencrypted protocols are used in application code. Plain HTTP is only accepted for local development (CORS_ORIGINS may include http://localhost:*)

    See docs/features/platform/networking.md (https://github.com/StayPirate/sentinel/blob/master/docs/features/platform/networking.md) and docs/data-sources.md (https://github.com/StayPirate/sentinel/blob/master/docs/data-sources.md) for the full external service catalog and protocol details.



    Le logiciel produit par le projet DOIT, 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]

    Sentinel's TLS configuration supports TLS 1.2 and later:

    • Python runtime: Python 3.13's ssl module uses OpenSSL's default minimum protocol version, which is TLS 1.2 on all modern distributions (TLS 1.0 and 1.1 were deprecated in OpenSSL 1.1.1 and disabled by default in OpenSSL 3.x)
    • HTTP clients: the httpx library (used for all external service integrations) uses Python's ssl module, which enforces TLS 1.2+ by default
    • Database: asyncpg TLS connections negotiate TLS 1.2+ via the system OpenSSL
    • Redis/RabbitMQ: TLS connections via rediss:// and amqps:// schemes use Python's ssl module, defaulting to TLS 1.2+
    • Custom TLS context: the networking infrastructure (docs/features/platform/networking.md) supports configurable TLS contexts with certificate verification enabled by default, using the system trust store

    TLS versions prior to 1.2 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1) are disabled by the underlying OpenSSL library in the Python 3.13 base image (python:3.13-slim).


  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]
    Notez que GitHub et GitLab sont connus pour le faire. Des sites tels que https://securityheaders.com/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff ») et X-Frame-Options. Les sites Web complètement statiques sans possibilité de se connecter à travers les pages Web peuvent éventuellement omettre certains entêtes de durcissement avec moins de risques, mais il n'existe aucune manière fiable de détecter ces sites, donc nous exigeons ces en-têtes mêmes pour les sites complètement statiques.

    Sentinel's repository and website are hosted on GitHub, which serves all pages with hardening headers including:

    • Content-Security-Policy: restrictive policy limiting script and resource sources
    • X-Content-Type-Options: nosniff
    • X-Frame-Options: DENY
    • Strict-Transport-Security: HSTS with long max-age, includeSubDomains, and preload
    • X-XSS-Protection: 0 (modern approach — CSP replaces this deprecated header)
    • Referrer-Policy: restrictive policy

    These are enforced by GitHub's infrastructure for all repositories and GitHub Pages sites. The project does not operate a separate website or download site outside of GitHub.

    URL: https://github.com/StayPirate/sentinel


  • Autres problèmes de sécurité


    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]
    Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.

    The project maintains an extensive docs/reviews/ directory with security review findings for every major component — over 50 review documents covering authentication, RBAC, networking, API specification, fetcher infrastructure, and all integration points. Each review includes findings from a dedicated @security-reviewer agent (among others), threat model assessments (e.g., brute-force resistance in local-authentication, trusted-upstream assumptions in networking, pre-disclosure data exposure in RBAC), and explicit risk acceptance decisions with rationale. The CI pipeline also runs bandit (static security analysis) and pip-audit (dependency vulnerability scanning) on every merge. Security-sensitive areas are subject to mandatory review per Guardrail 10. [osps_sa_03_01]



    Des 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é. (URL requise) [hardening]
    Les mécanismes de durcissement peuvent inclure des en-têtes HTTP comme Content Security Policy (CSP), des options de compilation pour atténuer les attaques (telles que -fstack-protector) ou des options de compilation pour éliminer les comportements indéfinis. Pour nos besoins, le principe de plus faible privilège n'est pas considéré comme un mécanisme de durcissement (le principe de plus faible privilège est important, mais séparé).

    Sentinel employs multiple hardening mechanisms to reduce the likelihood that software defects result in security vulnerabilities:

    • Memory-safe language: Python is memory-safe by design — no buffer overflows, use-after-free, or memory corruption
    • Strict static type checking: mypy --strict is a mandatory CI gate, catching type errors, unhandled None values, and forgotten await calls before production
    • SQL injection prevention: all database queries use SQLAlchemy's parameterized query API — no raw SQL string concatenation
    • Input validation at boundaries: Pydantic schemas reject malformed input before business logic; database CHECK constraints provide defense-in-depth
    • Secret masking: SecretStr type prevents accidental credential exposure in tracebacks, logs, and repr output
    • SAST: bandit detects common Python security anti-patterns (hardcoded passwords, eval, insecure deserialization) in CI
    • SCA: pip-audit blocks dependencies with known vulnerabilities pre-merge
    • Container scanning: Trivy scans the Docker image for OS and library vulnerabilities
    • Least-privilege CI: workflows default to permissions: read-all; jobs escalate only specific permissions needed
    • Secret scanning: GitHub Secret Scanning with Push Protection prevents accidental credential commits
    • Pessimistic locking: centralized mutation modules use SELECT ... FOR UPDATE to prevent race conditions
    • No custom cryptography: all crypto delegates to vetted FLOSS libraries (bcrypt, PyJWT, OpenSSL)

    These mechanisms are documented across docs/conventions.md (https://github.com/StayPirate/sentinel/blob/master/docs/conventions.md), docs/architecture.md (https://github.com/StayPirate/sentinel/blob/master/docs/architecture.md), and docs/deployment.md (https://github.com/StayPirate/sentinel/blob/master/docs/deployment.md) (CI Pipeline).


 Analyse 1/2

  • Analyse dynamique de code


    Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. [dynamic_analysis]
    Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.

    Sentinel does not currently apply dynamic analysis tools (e.g., fuzzing, property-based testing with Hypothesis, runtime sanitizers, or similar) to production releases. The project relies on static analysis (mypy --strict, bandit, ruff), dependency auditing (pip-audit), container scanning (Trivy), and an extensive automated test suite (850+ tests), but no dynamic analysis tool is part of the CI pipeline or release process. This is consistent with the "Unmet" status on the runtime assertions criterion above.



    Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]
    Ce critère ne suggère pas d'activer les assertions en production ; c'est entièrement au projet et à ses utilisateurs de le décider. L'objectif de ce critère est plutôt d'améliorer la détection des défauts lors de l'analyse dynamique avant le déploiement. L'activation des assertions en production est complètement différente de l'activation des assertions pendant l'analyse dynamique (comme les tests). Dans certains cas, il est extrêmement imprudent d'activer les assertions en production (en particulier dans les composants à haute intégrité). Il existe de nombreux arguments contre l'activation des assertions en production, par exemple, les bibliothèques ne devraient pas faire échouer les appelants, leur présence peut provoquer le rejet par les magasins d'applications et/ou l'activation d'une assertion en production peut exposer des données privées telles que des clés privées. Attention, dans de nombreuses distributions Linux, NDEBUG n'est pas défini, donc assert() sera activé par défaut en C/C++ pour la production dans ces environnements. Il peut être important d'utiliser un mécanisme d'assertion différent ou de définir NDEBUG pour la production dans ces environnements.

    Sentinel does not currently make significant use of run-time assertions (assert statements) in its production code. Python's assert statements are stripped when running with optimization flags (-O), and the project relies instead on explicit validation (Pydantic schemas, service-layer guard clauses raising typed exceptions, database CHECK constraints) rather than assert-based runtime assertions. No dynamic analysis tool (e.g., fuzzing, property-based testing with Hypothesis) is currently integrated into the test suite or CI pipeline.



Vous pouvez utiliser des outils et des systèmes d'IA pour proposer des modifications via une URL simple, par exemple https://www.bestpractices.dev/fr/projects/14063/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consultez notre système de propositions d'automatisation pour savoir comment procéder. Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Gianluca Gabrielli et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Gianluca Gabrielli.
Soumission créée le 2026-08-13 13:55:49 UTC, dernière mise à jour le 2026-08-14 06:09:03 UTC. Le dernier badge obtenu l'a été le 2026-08-13 16:48:08 UTC.