Vectis

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 14194 est in_progress 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/14194/badge)](https://www.bestpractices.dev/projects/14194)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14194"><img src="https://www.bestpractices.dev/projects/14194/badge"></a>


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

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

        

 Notions de base 12/13 ●

  • Général

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

    Open-source cryptographic data protection toolkit for sensitive data workflows.

    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.

    Vectis is an experimental open source cryptographic data protection toolkit under active development. It provides profile-driven hybrid cryptography,
    format-preserving encryption, tokenization, masking, MACs, blind indexes, commitments, secret sharing, protected messaging, and verifiable audit records.

    The project emphasizes bounded input validation, signed configuration, encrypted application-level storage, explicit trust boundaries, key lifecycle
    enforcement, negative testing, property-based testing, Schemathesis, native fuzzing, dependency auditing, CodeQL, and reproducible release workflows.

    Vectis v0.8.5 completed a source-backed security self-assessment with no Critical or High severity vulnerabilities identified. This was not an
    independent external security audit, certification, or compliance assessment. Vectis should currently be used for evaluation, testing, demos, and
    design-partner proofs of concept rather than as the sole protection layer for
    production sensitive data.

    Project scope, accepted risks, and operational assumptions are documented publicly in the threat model and security documentation.

  • Contenu basique du site Web du projet


    Assez pour un badge !

    Le site du projet DOIT décrire succinctement ce que le logiciel fait (quel problème résout-il ?). [description_good]
    Cela DOIT être dans un langage que les utilisateurs potentiels peuvent comprendre (par exemple, il utilise un jargon minimal).

    Vectis is an open-source advanced data protection toolkit.

    TLS protects the connection, but sensitive data keeps moving in plaintext afterward — through logs, queues, databases, and internal APIs. Vectis protects the data itself.

    Sensitive input in. Protected representation out

    Vectis protects and transforms sensitive values through a consistent HTTP API and CLI. Operator-signed profiles define the allowed operations, algorithms, keys, permissions, and lifecycle policy.


    Assez pour un badge !

    Le site Web du projet DOIT fournir des informations sur la façon d'obtenir, de fournir des commentaires (comme des signalements de bogues ou des demandes d'amélioration) et de contribuer au logiciel. [interact]

    Security: https://github.com/liesware/Vectis/blob/main/SECURITY.md
    Contributing: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Assez pour un badge !

    L'information sur la façon de contribuer DOIT expliquer le processus de contribution (par exemple, les pull requests sont-ils utilisés ?) (URL requise) [contribution]
    Nous supposons que les projets sur GitHub utilisent les problèmes et les pull requests, sauf indication contraire. Cette information peut être courte, par exemple, en indiquant que le projet utilise les pull requests, un suivi des problèmes ou des messages dans une liste de diffusion (laquelle ?)

    Non-trivial contribution file in repository: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md.


    Informations inconnues requises, pas assez pour un badge.

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

  • Licence FLOSS


    Assez pour un badge !

    Le logiciel produit par le projet DOIT être distribué en tant que FLOSS. [floss_license]
    FLOSS est un logiciel distribué d'une manière qui répond à la Définition de l'Open Source ou à la Définition du Logiciel Libre. Des exemples de ces licences sont CC0, MIT, BSD 2-clause, BSD 3-clause révisée, Apache 2.0, Lesser GNU General Public License (LGPL), et GNU General Public License (GPL). Pour nos besoins, cela signifie que la licence DOIT être : Le logiciel PEUT également être distribué avec d'autres licences (par exemple, « GPLv2 ou propriétaire » est acceptable).

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Assez pour un badge !

    Il est PROPOSÉ que toute licence requise pour le logiciel produit par le projet soit approuvée par l'Open Source Initiative (OSI). [floss_license_osi]
    L'OSI utilise un processus d'approbation rigoureux pour déterminer quelles licences sont OSS.

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Assez pour un badge !

    Le projet DOIT afficher la ou les licences de ses résultats dans un emplacement standard dans leur dépôt source. (URL requise) [license_location]
    Une convention est de publier la licence sous la forme d'un fichier à la racine du dépôt appelé LICENSE ou COPYING, qui PEUT être suivi d'une extension telle que « .txt » ou « .md ». Une autre convention est d'avoir un réportoire nommé LICENSES contenant le(s) fichier(s) de licence ; ces fichiers sont généralement nommés comme leur identifiant de licence SPDX suivi d'une extension de fichier appropriée, comme décrit dans la Spécification REUSE. Notez que ce critère est requis uniquement pour le dépôt de sources. Vous n'avez PAS besoin d'inclure le fichier de licence lors de la génération d'un élément à partir du code source (tel qu'un exécutable, un paquet ou un conteneur). Par exemple, lors de la génération d'un paquet R pour le réseau d'archives complet R (CRAN), suivez la procédure standard CRAN : si la licence est une licence standard, utilisez la spécification de standard courte (pour éviter d'installer une autre copie du texte) et listez le fichier LICENSE dans un fichier d'exclusion tel que .Rbuildignore. De même, lors de la création d'un paquet Debian, vous pouvez mettre un lien dans le fichier de copyright vers le fichier de licence dans /usr/share/common-licenses, et exclure le fichier de licence du paquet créé (par exemple, en supprimant le fichier après avoir appelé dh_auto_install). Nous encourageons fortement l'inclusion d'informations de licence lisibles automatiquement dans des formats générés lorsque cela est possible.

    Non-trivial license location file in repository: https://github.com/liesware/Vectis/blob/main/LICENSE.


  • Documentation


    Assez pour un badge !

    Le projet DOIT fournir une documentation de base pour le logiciel produit par le projet. [documentation_basics]
    Cette documentation doit se trouver dans un certain format (comme le texte ou la vidéo) qui comprend : comment l'installer, comment le démarrer, comment l'utiliser (éventuellement avec un tutoriel à l'aide d'exemples) et comment l'utiliser en toute sécurité (par exemple, quoi faire et ne pas faire) si c'est un sujet approprié pour le logiciel. La documentation de sécurité n'a pas besoin d'être longue. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    Vectis provides basic documentation in its README, including its purpose,
    current capabilities, scope, installation and Quick Start instructions,
    configuration overview, CLI and API entry points, testing, and security status.

    README:
    https://github.com/liesware/Vectis#readme

    Quick Start:
    https://github.com/liesware/Vectis#quick-start

    Detailed documentation:
    https://github.com/liesware/Vectis/tree/main/doc


    Assez pour un badge !

    Le projet DOIT fournir une documentation de référence qui décrit l'interface externe (entrée et sortie) du logiciel produit par le projet. [documentation_interface]
    La documentation d'une interface externe explique à un utilisateur final ou un développeur comment l'utiliser. Cela inclut son interface de programmation (API) si le logiciel en possède une. S'il s'agit d'une bibliothèque, documentez les principales classes / types et méthodes / fonctions pouvant être appelés. S'il s'agit d'une application Web, définissez son interface URL (souvent son interface REST). S'il s'agit d'une interface de ligne de commande, documentez les paramètres et les options qu'elle supporte. Dans de nombreux cas, il est préférable que la majorité de cette documentation soit générée automatiquement, de sorte que cette documentation reste synchronisée avec le logiciel au fur et à mesure qu'il change, mais cela n'est pas nécessaire. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. La documentation PEUT être générée automatiquement (quand c'est possible, c'est souvent la meilleure façon de le faire). La documentation d'une interface REST peut être générée à l'aide de Swagger / OpenAPI. La documentation de l'interface de code PEUT être générée à l'aide d'outils tels que JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) et Doxygen (plusieurs). Le simple fait d'avoir des commentaires dans le code source n'est pas suffisant pour satisfaire ce critère ; il doit y avoir un moyen simple de voir l'information sans lire l'intégralité du code source. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    Vectis documents its external HTTP and CLI interfaces, including request and
    response fields, status codes, error behavior, command arguments, output
    formats, configuration, and environment variables.

    HTTP API reference:
    https://github.com/liesware/Vectis/blob/main/doc/API.md

    OpenAPI specification:
    https://github.com/liesware/Vectis/blob/main/doc/openapi.yaml

    CLI reference:
    https://github.com/liesware/Vectis/blob/main/doc/CLI.md

    Environment reference:
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


  • Autre


    Assez pour un badge !

    Les sites du projet (site Web, dépôt et URLs de téléchargement) DOIVENT supporter HTTPS en utilisant TLS. [sites_https]
    Cela nécessite que l'URL de la page d'accueil du projet et l'URL du référentiel de contrôle de version commencent par « https: » et non par « http: ». Vous pouvez obtenir des certificats gratuits de Let's Encrypt. Les projets PEUVENT mettre en œuvre ce critère en utilisant (par exemple) des pages GitHub, des pages GitLab ou des pages de projet SourceForge. Si vous prenez en charge HTTP, nous vous invitons à rediriger le trafic HTTP vers HTTPS.

    Given only https: URLs.


    Assez pour un badge !

    Le projet DOIT avoir un ou plusieurs mécanismes de discussion (y compris les changements et les problèmes proposés) qui peuvent être recherchés, permettent de désigner les messages et les sujets par une URL, permettent aux nouvelles personnes de participer à certaines des discussions et ne nécessitent pas d'installation côté client de logiciels propriétaires. [discussion]
    Parmi les exemples de mécanismes acceptables figurent les listes de diffusion archivées, les problèmes de GitHub et les discussions sur les pull requests, Bugzilla, Mantis et Trac. Les mécanismes de discussion asynchrones (comme IRC) sont acceptables s'ils répondent à ces critères ; assurez-vous qu'il existe un mécanisme d'archivage adressable par URL. Une solution propriétaire en JavaScript, tout en étant découragée, est autorisée.

    GitHub supports discussions on issues and pull requests.


    Assez pour un badge !

    Le projet DEVRAIT fournir de la documentation en anglais et être en mesure d'accepter les signalements de bogues et les commentaires sur le code en anglais. [english]
    L'anglais est actuellement la langue véhiculaire des technologies informatiques ; l'utilisation de l'anglais augmente le nombre de développeurs et de relecteurs potentiels dans le monde entier. Un projet peut répondre à ce critère même si la langue principale de ses principaux développeurs n'est pas l'anglais.

    Vectis documentation, contribution guidance, security policy, API reference,
    and source-code documentation are written in English. Bug reports, pull
    requests, and code-review comments are accepted in English through GitHub.

    Documentation:
    https://github.com/liesware/Vectis#readme

    Contribution guidance:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md

    Bug reports:
    https://github.com/liesware/Vectis/issues

    Pull requests:
    https://github.com/liesware/Vectis/pulls


    Assez pour un badge !

    Le projet DOIT être maintenu. [maintained]
    Au minimum, le projet doit tenter de répondre aux rapports de problèmes et de vulnérabilités importants. Un projet qui poursuit activement un badge est probablement maintenu. Tous les projets et tous les individus ont des ressources limitées, et les projets typiques doivent rejeter certaines modifications proposées, de sorte que les ressources limitées et les rejets de propositions n'indiquent pas en eux-mêmes un projet non maintenu.

    Lorsqu'un projet sait qu'il ne sera plus maintenu, il doit définir ce critère comme « Non satisfait » et utiliser le(s) mécanisme(s) approprié(s) pour indiquer aux autres qu'il n'est pas maintenu. Par exemple, utiliser « DEPRECATED » comme premier en-tête de son fichier README, ajouter « DEPRECATED » au début de sa page d'accueil, ajouter « DEPRECATED » au début de la description de projet de son dépôt de code, ajouter un badge sans maintenance dans son README et/ou sa page d'accueil, le marquer comme obsolète dans tous les dépôts de paquets (par exemple, npm deprecate), et/ou utiliser le système de marquage du dépôt de code pour l'archiver (par exemple, le paramètre « archive » de GitHub, le marquage « archivé » de GitLab, le statut « lecture seule » de Gerrit ou le statut de projet « abandonné » de SourceForge). Une discussion supplémentaire peut être trouvée ici.

    Vectis is under active development and is maintained through regular commits,
    continuous integration, dependency and security scanning, and a public issue
    tracker. The supported release series is documented in SECURITY.md, together
    with a private vulnerability-reporting process and an acknowledgment target.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/actions
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Contrôle des modifications 9/9 ●

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


    Assez pour un badge !

    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]
    L'URL PEUT être identique à l'URL du projet. Le projet PEUT utiliser des branches privées (non publiques) dans des cas spécifiques alors que la modification n'est pas diffusée publiquement (par exemple, pour la correction d'une vulnérabilité avant qu'elle ne soit révélée au public).

    Repository on GitHub, which provides public git repositories with URLs.


    Assez pour un badge !

    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    Assez pour un badge !

    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]
    Les projets PEUVENT choisir d'omettre des versions intermédiaires spécifiques dans leurs dépôts source publics (par exemple, celles qui corrigent des vulnérabilités de sécurité non publiques spécifiques, ne peuvent jamais être rendues publiques ou incluent des éléments qui ne peuvent être légalement publiés et ne sont pas dans la version finale).

    Vectis is developed in its public Git repository. The main branch contains intermediate development commits between releases, and the complete commit
    history and proposed pull-request changes are available for review. The repository is not limited to final release snapshots or generated artifacts.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/pulls
    https://github.com/liesware/Vectis


    Assez pour un badge !

    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [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.


  • Numérotation unique de la version


    Assez pour un badge !

    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]
    Cela PEUT être satisfait de diverses façons, y compris les identifiants de commit (comme git commit id ou mercure changeset id) ou un numéro de version (y compris les numéros de version qui utilisent la version sémantique ou les systèmes basés sur la date comme YYYYMMDD).

    Each Vectis release is assigned a unique Semantic Versioning identifier from Cargo.toml. The version is exposed by vectis version, recorded in
    CHANGELOG.md, and used in release artifact names.

    The release workflow requires the Git tag to match v${Cargo.toml.version} before publishing release artifacts, preventing a release from being published under an inconsistent version identifier.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml


    Assez pour un badge !

    Il est PROPOSÉ d'utiliser le format de numérotation de version appelé Versionage Sémantique (SemVer) ou Versionage Calendaire (CalVer). Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro. [version_semver]
    Les projets devraient généralement préférer le format attendu par leurs utilisateurs, par exemple, parce que c'est le format normal utilisé par leur écosystème. De nombreux écosystèmes préfèrent SemVer, et SemVer est généralement préféré pour les interfaces de programmation d'applications (API) et les kits de développement logiciel (SDK). CalVer a tendance à être utilisé par des projets de grande envergure, ayant un nombre inhabituellement élevé de dépendances développées indépendamment, ayant une portée en constante évolution ou étant sensibles au temps. Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro, car l'inclusion d'un niveau micro prend en charge les branches maintenues simultanément chaque fois que cela devient nécessaire. D'autres formats de numérotation de version peuvent être utilisés, y compris les ID de commit git ou les ID de jeu de modifications mercurial, à condition qu'ils identifient de manière unique les versions. Cependant, certaines alternatives (telles que les ID de commit git) peuvent poser des problèmes en tant qu'identificateurs de version, car les utilisateurs peuvent ne pas être en mesure de déterminer facilement s'ils sont à jour. Le format de l'ID de version peut être sans importance pour l'identification des versions logicielles si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue).

    À peine suffisant pour un badge.

    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]

    Vectis has a release workflow that requires release tags to match v${Cargo.toml.version}, but the first public release has not yet been identified with a Git tag.


  • Notes de version


    Assez pour un badge !

    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]
    Les notes de version PEUVENT être mises en œuvre de différentes façons. De nombreux projets les fournissent dans un fichier nommé « NEWS », « CHANGELOG » ou « ChangeLog », éventuellement avec des extensions telles que « .txt », « .md » ou « .html ». Historiquement, le terme « journal des modifications » signifiait un enregistrement de chaque changement, mais pour répondre à ces critères, il faut un résumé lisible par un humain. Les notes de version PEUVENT être fournies à la place par des mécanismes de système de contrôle de version tels que le GitHub Releases workflow.

    Non-trivial release notes file in repository: https://github.com/liesware/Vectis/blob/main/CHANGELOG.md.


    Assez pour un badge !

    Les notes de version DOIVENT identifier toutes les vulnérabilités connues du public corrigées dans cette version qui avaient déjà une affectation CVE ou similaire lors de la création de la version. Ce critère peut être marqué comme non applicable (N/A) si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes (par exemple, comme c'est souvent le cas pour les mises à jour du noyau). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez N/A. [release_notes_vulns]
    Ce critère aide les utilisateurs à déterminer si une mise à jour donnée corrigera une vulnérabilité connue publiquement, pour aider les utilisateurs à prendre une décision éclairée concernant la mise à jour. Si les utilisateurs ne peuvent généralement pas mettre à jour le logiciel eux-mêmes sur leur ordinateur, mais doivent à la place dépendre d'un ou plusieurs intermédiaires pour effectuer la mise à niveau (comme c'est souvent le cas pour un noyau et un logiciel de bas niveau associé à un noyau), le projet peut choisir « non applicable » (N/A) à la place, car ces informations supplémentaires ne seront pas utiles à ces utilisateurs. De même, un projet peut choisir N/A si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. Énumérer les vulnérabilités de toutes les dépendances transitives d'un projet devient ingérable à mesure que les dépendances augmentent et varient, et n'est pas nécessaire car les outils qui examinent et suivent les dépendances peuvent le faire de manière plus évolutive.

    N/A. At the time Vectis v0.8.5 was prepared, there were no publicly known run-time vulnerabilities in Vectis with a CVE or equivalent public identifier that were fixed by the release.

    Dependency advisories are monitored separately and are not treated as vulnerabilities in the Vectis project results for this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Compte-rendu 6/8 ●

  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/liesware/Vectis/blob/main/SECURITY.md. [osps_do_02_01]


    Assez pour un badge !

    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    Vectis uses GitHub Issues as its public issue tracker. Individual bug reports,
    enhancement proposals, documentation problems, and user questions can be created, discussed, tracked, and closed there.

    Suspected unpatched vulnerabilities are handled separately through the private reporting process documented in SECURITY.md.

    Evidence:
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Informations inconnues requises, pas assez pour un badge.

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    Informations inconnues requises, pas assez pour un badge.

    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]
    La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.

    Assez pour un badge !

    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    Vectis uses GitHub Issues as a publicly available and searchable archive for bug reports, enhancement requests, questions, and maintainer responses. Open and closed reports remain available for later review and searching.

    Public archive:
    https://github.com/liesware/Vectis/issues?q=is%3Aissue


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]
    Les projets hébergés sur GitHub DEVRAIENT envisager d'activer le signalement privé d'une vulnérabilité de sécurité . Les projets sur GitLab DEVRAIENT envisager d'utiliser sa capacité à signaler une vulnérabilité en privé . Les projets PEUVENT identifier une adresse postale sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Ce processus de rapport de vulnérabilité PEUT être le même que son processus de rapport de bogue. Les rapports de vulnérabilité PEUVENT toujours être publics, mais de nombreux projets ont un mécanisme de rapport de vulnérabilité privé.

    Vectis publishes its vulnerability-reporting process in SECURITY.md. The policy defines the private reporting channel, requested report contents, supported versions, expected acknowledgment period, disclosure process, and information that reporters must not include.

    Vulnerability-reporting process:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Assez pour un badge !

    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]
    Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

    Vectis accepts private vulnerability reports through the maintainer's direct email address, using the subject specified in SECURITY.md. Reporters are instructed not to open a public issue for an unpatched vulnerability. If a more protected exchange is needed, the reporter can request an appropriate channel
    in the initial private message.

    Private reporting instructions:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md#reporting-a-vulnerability


    Assez pour un badge !

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]
    S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

    N/A. Vectis has not received any vulnerability reports during the last six months. SECURITY.md establishes a target acknowledgment period of five business
    days for future reports.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Qualité 13/13 ●

  • Système de construction opérationnel


    Assez pour un badge !

    Si le logiciel produit par le projet nécessite d'être construit pour être utilisé, le projet DOIT fournir un système de construction fonctionnel qui peut reconstruire automatiquement le logiciel à partir du code source. [build]
    Un système de construction détermine quelles actions doivent se produire pour reconstruire le logiciel (et dans quel ordre), puis exécute ces étapes. Par exemple, il peut invoquer un compilateur pour compiler le code source. Si un exécutable est créé à partir du code source, il doit être possible de modifier le code source du projet, puis de générer un exécutable mis à jour avec ces modifications. Si le logiciel produit par le projet dépend de bibliothèques externes, le système de construction n'a pas besoin de construire ces bibliothèques externes. S'il n'est pas nécessaire de construire quoi que ce soit pour utiliser le logiciel après la modification de son code source, sélectionnez « non applicable » (N/A).

    Vectis uses Cargo as its automated build system. The complete application can be rebuilt from source with cargo build --locked or cargo build --release --locked.

    Cargo.toml defines the package and dependencies, Cargo.lock pins dependency resolution, and rust-toolchain.toml defines the Rust toolchain. GitHub Actions
    continuously verifies that the project builds from source.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    Assez pour un badge !

    Il est PROPOSÉ d'utiliser des outils courants pour la construction du logiciel. [build_common_tools]
    Par exemple, Maven, Ant, cmake, autotools, make, rake (Ruby) ou devtools (R).

    Vectis uses Cargo and rustup, the standard build and toolchain-management tools of the Rust ecosystem. Common Cargo commands are used for development, testing, linting, and release builds; no proprietary or project-specific build system is required.

    Typical commands include:

    cargo build --locked
    cargo test --locked
    cargo clippy --locked --all-targets --all-features -- -D warnings

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Assez pour un badge !

    Le projet DEVRAIT être constructible en utilisant uniquement des outils FLOSS. [build_floss_tools]

    Vectis can be built entirely with FLOSS tools. Its standard build uses the open-source Rust compiler, Cargo, LLVM-based tooling, and common GNU/Linux build
    tools.

    The container build demonstrates this path using Debian with Cargo, rustc, Clang, GCC, CMake, Make, and other open-source packages, followed by
    cargo build --release --locked. No proprietary compiler or build system is required.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml


  • Suite de tests automatisée


    Assez pour un badge !

    Le projet DOIT utiliser au moins une suite de tests automatisée publiée publiquement comme FLOSS (cette suite de tests peut être maintenue sous la forme d'un projet FLOSS distinct). Le projet DOIT clairement montrer ou documenter comment exécuter la ou les suites de tests (par exemple, via un script d'intégration continue (CI) ou via la documentation dans des fichiers tels que BUILD.md, README.md ou CONTRIBUTING.md). [test]
    Le projet PEUT utiliser plusieurs suites de tests automatisées (par exemple, une qui s'exécute rapidement, par rapport à une autre qui est plus approfondie, mais nécessite un équipement spécial). De nombreuses plate-formes de tests et environnements de tests sont disponibles, tels que Selenium (automatisation de navigateur Web), Junit (JVM, Java), RUnit (R), testthat (R).

    Vectis includes publicly available automated test suites released under the project's Apache-2.0 license. The primary Rust suite runs with cargo test --locked.

    The project also includes Python HTTP integration tests, Schemathesis OpenAPI contract testing, native cargo-fuzz targets, and dedicated CLI and cryptographic integration tests. Execution instructions and the role of each suite are documented in doc/Test.md, and the standard suite runs automatically through GitHub Actions.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/LICENSE


    Assez pour un badge !

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

    Vectis uses Cargo's standard Rust test interface. The primary unit and integration test suite is invoked with:

    cargo test --locked

    Targeted Rust tests can also be selected through Cargo's standard test filters. Additional Python, Schemathesis, and cargo-fuzz suites are documented separately, but they do not replace the standard Cargo test entry point.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    À peine suffisant pour un badge.

    Il est PROPOSÉ que la suite de tests couvre la plupart (ou idéalement toutes) les branches du code, les champs de saisie et les fonctionnalités. [test_most]

    Vectis has extensive unit, integration, negative-contract, property-based, HTTP, Schemathesis, and native fuzz testing. These suites cover the primary
    cryptographic capabilities, input fields, validation boundaries, storage behavior, and public API workflows.

    However, Vectis does not yet publish or enforce a coverage result demonstrating that most code branches are executed. This suggested criterion has been
    considered but is not currently claimed as met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz


    Assez pour un badge !

    Il est PROPOSÉ que le projet utilise 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). [test_continuous_integration]

    Vectis uses GitHub Actions for continuous integration. The Rust workflow runs automatically for every pull request targeting main and for every push to main.

    The workflow checks formatting, runs the complete Rust test suite, runs Clippy with warnings treated as errors, validates shell scripts, audits dependencies,
    builds the binary, and then executes the Python integration tests.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


  • Nouveau test de fonctionnalité


    Assez pour un badge !

    Le projet DOIT avoir une politique générale (formelle ou non) qui spécifie que, dès qu'une nouvelle fonctionnalité majeure est ajoutée au logiciel produit par le projet, des tests de cette fonctionnalité devraient être ajoutés à une suite de tests automatisée. [test_policy]
    Dès qu'une politique est en place, même par le bouche à oreille, qui spécifie que les développeurs devraient ajouter des tests à une suite de tests automatisée pour toute nouvelle fonctionnalité importante, sélectionnez « Atteint ».

    Vectis requires tests to be added alongside new behavior. Its engineering rules state that validation functions require unit tests and public contracts require
    positive and negative end-to-end tests. New endpoints are expected to add validators, limits, unit tests, and negative contract coverage as part of the
    same change.

    CONTRIBUTING.md also states that tests must not be omitted to make a change appear smaller and requires contributors to run the automated Rust suite before submitting.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Assez pour un badge !

    Le projet DOIT avoir la preuve que la politique de test pour l'ajout de tests a été respectée dans les dernières modifications majeures apportées au logiciel produit par le projet. [tests_are_added]
    Les principales fonctionnalités sont généralement mentionnées dans les notes de version. La perfection n'est pas nécessaire, il suffit de prouver que les tests sont généralement ajoutés en pratique à la suite de tests automatisée lorsque de nouvelles fonctionnalités majeures sont ajoutées au logiciel produit par le projet.

    Recent major Vectis capabilities were implemented together with automated tests:

    • SLH-DSA artifact signing added unit tests, parser validation tests, four native fuzz targets, and seed corpora.
    • One-time tokenization added SQLite transaction tests, HTTP positive and negative tests, CLI tests, and fuzz coverage.
    • Authenticated Shamir secret sharing added core and operation tests, positive and negative HTTP tests, CLI coverage, and fuzz inputs.
    • Cryptographic commitments added unit, HTTP contract, negative, CLI, and fuzz tests.

    This commit history demonstrates that the project's policy of adding tests with new functionality is followed in practice.

    Evidence:
    https://github.com/liesware/Vectis/commit/154cb816c41667d521c1f30cf25c50f6f524321d
    https://github.com/liesware/Vectis/commit/7f7f0fa4814494f7dad7fc740e1c70dd2606ba1d
    https://github.com/liesware/Vectis/commit/a337628e14e69ca4f2116a55d292fa9915a5eeca
    https://github.com/liesware/Vectis/commit/4bbf0047773cdc590da923f465a6b13cd7f02ea6


    Assez pour un badge !

    Il est PROPOSÉ que cette politique sur l'ajout de tests (voir la politique de test) soit documentée dans les instructions pour les propositions de modification. [tests_documented_added]
    Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


  • Options d'avertissement


    Assez pour un badge !

    Le projet DOIT activer une ou plusieurs options d'avertissement du compilateur, un mode du langage « sûr » ou utiliser un outil « linter » séparé pour rechercher des erreurs de qualité de code ou des erreurs simples courantes, s'il existe au moins un outil FLOSS qui peut implémenter ce critère dans le langage sélectionné. [warnings]
    Des exemples d'options d'avertissement du compilateur incluent « -Wall » pour gcc/clang. Des exemples d'un mode de langage « sûr » incluent « use strict » en JavaScript et « use warnings » de perl5. Un outil « linter » distinct est simplement un outil qui examine le code source pour rechercher des erreurs de qualité de code ou des erreurs simples courantes. Ceux-ci sont généralement activés par le code source ou par les instructions de construction.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


    Assez pour un badge !

    Le projet DOIT résoudre les avertissements. [warnings_fixed]
    Ce sont les avertissements identifiés par la mise en œuvre du critère warnings. Le projet doit corriger les avertissements ou les marquer dans le code source comme faux positifs. Idéalement, il n'y aurait pas d'avertissement, mais un projet PEUT accepter certains avertissements (généralement moins de 1 avertissement pour 100 lignes ou moins de 10 avertissements).

    Vectis treats compiler and Clippy warnings as errors. The continuous integration workflow runs Clippy with -D warnings across all targets and features, so any
    new warning causes the check to fail and must be resolved before the change can be accepted.

    The project's engineering rules define zero warnings as the required state, and the same check is documented for contributors.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


    Assez pour un badge !

    Il est PROPOSÉ que les projets soient maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]
    Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

    Vectis applies strict warning handling across all targets and features. Clippy and compiler warnings are promoted to errors through -D warnings, so warnings
    cannot be merged while the CI check is required.

    The project uses only narrow, local lint allowances for specific cases such as intentionally unused internal helpers and configuration functions whose
    signatures reflect explicit validation hooks. It does not disable warning categories globally.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


 Sécurité 15/16 ●

  • Connaissance du développement sécurisé


    Assez pour un badge !

    Le projet DOIT avoir au moins un développeur principal qui sait comment concevoir un logiciel sécurisé. (Voir les « détails » pour les exigences exactes.) [know_secure_design]
    Cela nécessite de comprendre les principes de conception suivants, y compris les 8 principes de Saltzer et Schroeder :
    • économie de moyens (maintenez la conception aussi simple et petite que pratique, par exemple en adoptant des simplifications conséquentes)
    • valeurs sûres par défaut (les décisions d'accès par défaut devraient être de refuser l'accès et l'installation des projets devrait être sécurisée par défaut)
    • médiation complète (tous les accès qui pourraient être limités doivent être vérifiés pour l'autorité et ne pas être contournables)
    • conception ouverte (les mécanismes de sécurité ne doivent pas dépendre de l'ignorance par l'attaquant de sa conception, mais plutôt d'informations plus facilement protégées et modifiées comme des clés et des mots de passe)
    • séparation des privilèges (idéalement, l'accès aux objets importants devrait dépendre de plus d'une condition, de sorte que la défaillance d'un système de protection n'autorisera pas l'accès complet. Par exemple, l'authentification multi-facteurs, comme l'exigence d'un mot de passe et d'un jeton matériel, est plus forte qu'une authentification à un seul facteur)
    • principe de plus faible privilège (les processus doivent fonctionner avec le minimum de privilège requis)
    • mécanisme de partage minimal (la conception devrait minimiser les mécanismes communs à plus d'un utilisateur et nécessaires à tous les utilisateurs, par exemple, les répertoires pour les fichiers temporaires)
    • acceptabilité psychologique (l'interface humaine doit être conçue pour faciliter l'utilisation - la conception pour « l'étonnement minimal » peut aider)
    • surface d'attaque limitée (la surface d'attaque - l'ensemble des différents points où un attaquant peut essayer d'entrer ou d'extraire des données - devrait être limitée)
    • validation d'entrée avec des listes blanches (les entrées devraient généralement être vérifiées pour déterminer si elles sont valides avant qu'elles ne soient acceptées ; cette validation devrait utiliser des listes blanches (qui n'acceptent que des bonnes valeurs connues), et non des listes noires (qui tentent de répertorier les valeurs mauvaises connues)).
    Un « développeur principal » dans un projet est celui qui connaît la base de code du projet, est à l'aise pour faire des modifications et est reconnu comme tel par la plupart des autres participants au projet. Un développeur principal a effectué généralement un certain nombre de contributions au cours de l'année écoulée (du code, de la documentation ou des réponses aux questions). Des développeurs sont généralement considérés comme des développeurs principaux s'ils ont lancé le projet (et n'ont pas quitté le projet il y a plus de trois ans), ont la possibilité de recevoir des informations sur un canal privé de déclaration de vulnérabilités (s'il y en a un), peuvent accepter des contributions au nom du projet, ou effectuer les distributions finales du logiciel du projet. S'il n'y a qu'un seul développeur, cette personne est le développeur principal. De nombreux livres et cours sont disponibles pour vous aider à comprendre comment développer des logiciels plus sûrs et pour discuter de leur conception. Par exemple, le cours Bases du développement logiciel sécurisé est un ensemble gratuit de trois cours qui expliquent comment développer des logiciels plus sûrs (il est possible de le suivre gratuitement comme auditeur ; il est aussi possible de payer pour obtenir un certificat prouvant que vous avez compris les enseignements du cours).

    Eduardo Lopez is the original author, primary developer, maintainer, release operator, and recipient of private vulnerability reports for Vectis.

    Vectis applies secure-design principles throughout its implementation and documentation: narrow scope and economy of mechanism; fail-closed sealed
    startup and authorization; centralized lifecycle and permission mediation; public design and threat-model documentation; separation of policy, keys, and
    operations; least-privilege container execution; bounded inputs and attack surface; allowlist-based validation; explicit trust boundaries; and simple,
    inspectable HTTP, CLI, JSON, and OpenAPI interfaces.

    The project's Design and Threat Model documents explain these principles, their implementation, and the security properties Vectis deliberately leaves
    to other layers.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/NOTICE


    Assez pour un badge !

    Au moins l'un des principaux développeurs du projet DOIT connaître les types courants d'erreurs qui conduisent à des vulnérabilités dans ce genre de logiciel, ainsi qu'au moins une méthode pour contrer ou atténuer chacun d'eux. [know_common_errors]
    Des exemples (selon le type de logiciel) incluent l'injection SQL, l'injection OS, le débordement mémoire classique, le cross-site scripting, l'authentification manquante et l'autorisation manquante. Voir CWE/SANS top 25 ou OWASP Top 10 pour les listes couramment utilisées. De nombreux livres et cours sont disponibles pour vous aider à comprendre comment développer des logiciels plus sûrs et discuter des erreurs courantes de mise en œuvre qui conduisent à des vulnérabilités. Par exemple, le cours Bases du développement logiciel sécurisé est un ensemble gratuit de trois cours qui expliquent comment développer des logiciels plus sûrs (gratuitement ; vous pouvez payer pour obtenir un certificat démontrant que vous avez assimilé le matériel présenté).

    Vectis's primary developer understands common vulnerability classes relevant to a networked cryptographic data-protection service and applies corresponding
    mitigations, including:

    • SQL injection: SQLx queries use bound parameters; dynamic SQL is limited to internally generated placeholders.
    • Missing authentication or authorization: protected endpoints use API-key authentication, signed permissions, KID scoping, peer authorization, and
      centralized lifecycle checks.
    • SSRF and destination injection: peer and final-application destinations come from signed configuration, not request-supplied addresses.
    • Invalid or malicious input: external fields are bounded and validated using allowlists, typed parsers, strict JSON contracts, and canonical structured
      contexts.
    • Cryptographic misuse: Vectis uses published algorithms through Botan and established libraries, CSPRNG-generated material, profile-controlled policy,
      context-bound AEAD, and verify-before-decrypt.
    • Timing attacks: API-key, MAC, commitment, signature-hash, and share authentication comparisons use constant-time comparison.
    • Secret disclosure: sensitive values are redacted from errors and logs, zeroized where practical, and encrypted before application-level storage.
    • Resource-exhaustion attacks: HTTP bodies, fields, batches, files, timeouts, and shutdown behavior have explicit bounds.
    • Concurrency and state races: token consumption and lifecycle changes use transactions or compare-and-swap semantics where required.
    • Memory-safety errors: Vectis is implemented in Rust and avoids manual memory management in production application logic.

    These threats and mitigations are documented and tested through unit, integration, negative-contract, property-based, and fuzz testing.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/src/core/validation.rs
    https://github.com/liesware/Vectis/blob/main/src/core/storage/sqlite.rs


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

    Pas assez pour un badge.

    Le logiciel produit par le projet DOIT utiliser, par défaut, uniquement les protocoles cryptographiques et les algorithmes publiés publiquement et revus par des experts (si des protocoles et algorithmes cryptographiques sont utilisés). [crypto_published]
    Ces critères cryptographiques ne s'appliquent pas toujours car certains logiciels n'ont pas besoin d'utiliser directement de capacités cryptographiques.

    Vectis uses publicly published and expert-reviewed cryptographic algorithms, including AES-GCM, ChaCha20-Poly1305, SHA-3, BLAKE2, HMAC, KMAC, HKDF,
    Ed25519/Ed448, X25519/X448, ML-KEM, ML-DSA, SLH-DSA, and FF1. Its transport and time protocols use established TLS, NTS, and Roughtime implementations.

    However, Vectis also defines project-specific cryptographic compositions and envelope formats for protected messages, hybrid signatures, tokenization,
    commitments, and audit checkpoints. These designs are publicly documented but have not yet completed independent expert cryptographic review. Therefore, the project does not currently claim that this strict criterion is fully met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/README.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Assez pour un badge !

    Si le logiciel produit par le projet est une application ou une bibliothèque, et si son objectif principal n'est pas d'implémenter de la cryptographie, alors il DEVRAIT simplement appeler un logiciel spécialement conçu pour implémenter des fonctions cryptographiques ; il ne DEVRAIT PAS ré-implémenter les siennes. [crypto_call]

    Vectis's primary purpose is to provide cryptographic data-protection capabilities, including encryption, signatures, FPE, tokenization, MACs,
    commitments, secret sharing, and protected messaging. Therefore, the condition for this criterion does not apply.

    Nevertheless, Vectis delegates established cryptographic primitives to specialized FLOSS implementations such as Botan, RustCrypto crates, rustls,
    and the FF1 implementation maintained in liesware/fpe. Vectis does not implement block ciphers, cryptographic hash functions, digital-signature
    algorithms, or post-quantum primitives from scratch. Project code primarily implements policy, validation, key derivation, formats, and compositions around
    those primitives.

    Evidence:
    https://github.com/liesware/Vectis#readme
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md


    Assez pour un badge !

    Toutes les fonctionnalités du logiciel produit par le projet qui dépendent de la cryptographie DOIVENT être réalisables à l'aide de FLOSS. [crypto_floss]
    Consultez les Exigences des standards ouverts pour les logiciels par l'Open Source Initiative.

    All cryptography-dependent functionality in Vectis can be built and operated using FLOSS components. Vectis is licensed under Apache-2.0 and publishes its
    complete source code.

    Cryptographic primitives are provided by open-source implementations including Botan, RustCrypto crates, rustls, and the open-source Vectis FF1 fork. Vectis
    does not require proprietary cryptographic libraries, SDKs, hardware, or hosted services for its current functionality. Dependencies are declared and pinned
    through Cargo.toml and Cargo.lock, and the project can be rebuilt from source
    using the documented FLOSS toolchain.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/LICENSE
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/fpe
    https://github.com/randombit/botan
    https://github.com/rustls/rustls


    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT utiliser des longueurs de clés par défaut qui satisfont au moins aux exigences minimales du NIST jusqu'à l'année 2030 (comme indiqué en 2012). Il DOIT être possible de configurer le logiciel afin que les plus petites longueurs de clés soient complètement désactivées. [crypto_keylength]
    Ces longueurs de bit minimales sont : pour une clé symétrique 112, pour un modulo de factorisation 2048, pour une clé de logarithme discret 224, pour un groupe du logarithmique discret 2048, pour une courbe elliptique 224 et pour un hachage 224 (le hachage de mot de passe n'est pas couvert par cette longueur de bit, plus d'informations sur le hachage de mot de passe peuvent être trouvées dans le critère crypto_password_storage). Voir https://www.keylength.com pour une comparaison des recommandations sur les longueurs de clés de diverses organisations. Le logiciel PEUT permettre de plus petites longueurs de clés dans certaines configurations (idéalement non, car cela permet des attaques de dégradation, mais des longueurs de clés plus courtes sont parfois nécessaires pour l'interopérabilité).

    Vectis uses cryptographic profiles whose weakest supported components provide at least 128 bits of security, exceeding the 112-bit NIST minimum required
    through 2030.

    The default hybrid-performance-v1 profile uses ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other profiles use AES-128, AES-192, or
    AES-256 together with equal or stronger signature and key-establishment parameters. Internal encryption, FPE, tokenization, MAC, commitments, secret
    sharing authentication, and key derivation use 256-bit key material.

    Vectis does not expose legacy or reduced key sizes. The default VECTIS_CRYPTO_POLICY=profile-only rejects individual algorithm overrides and
    allows only the fixed, validated profiles. Even development overrides are restricted to an allowlist containing no algorithms below the required
    security strength.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md
    https://github.com/liesware/Vectis#crypto-profiles


    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes cryptographiques cassés (par exemple, MD4, MD5, DES unique, RC4, Dual_EC_DRBG) ou utiliser des modes de chiffrement inappropriés dans le contexte, sauf si ils sont nécessaires pour implémenter un protocole d'interopérabilité (où le protocole implémenté est la version la plus récente du standard supporté largement par l'écosystème du réseau, l'écosystème requiert l'utilisation de cet algorithme ou mode, et cet écosystème n'offre pas d'alternative plus sûre). La documentation DOIT décrire tous les risques de sécurité appropriés et les parades connues si ces algorithmes ou modes cassés sont nécessaires pour un protocole d'interopérabilité. [crypto_working]
    Le mode ECB n'est presque jamais approprié car il révèle des blocs identiques dans le texte chiffré, comme le montre le pingouin ECB, et le mode CTR est souvent inapproprié car il n'effectue pas d'authentification et provoque des doublons si l'état d'entrée est dupliqué. Dans de nombreux cas, il est préférable de choisir un mode d'algorithme de chiffrement de bloc conçu pour combiner le secret et l'authentification, par exemple Galois/Counter Mode (GCM) et EAX. Les projets PEUVENT permettre aux utilisateurs d'activer les mécanismes cassés (par exemple pendant la configuration) si nécessaire pour la compatibilité, mais les utilisateurs savent alors qu'ils le font.

    Vectis does not use cryptographic algorithms known to be broken, including MD4, MD5, SHA-1, DES, Triple DES, RC4, or Dual_EC_DRBG.

    The default profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other supported profiles use SHA-3, AES-GCM,
    Ed25519 or Ed448, X25519 or X448, ML-DSA, and ML-KEM.

    Encryption uses authenticated encryption modes: ChaCha20Poly1305 or AES-GCM. Stored internal material uses AES-256/GCM, and FPE uses FF1 with AES-256 and enforces a minimum domain size. Keyed operations use HMAC or KMAC. HTTPS uses rustls and its modern TLS defaults.

    Algorithm selection is restricted through explicit allowlists. The default profile-only policy rejects request-supplied algorithm overrides, and no compatibility fallback enables broken algorithms or inappropriate cipher modes.

    Vectis currently has no interoperability requirement that requires a broken algorithm, so no exception or legacy-risk mitigation is necessary.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md


    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DEVRAIENT 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]
    Les préoccupations concernant le mode CBC en SSH sont discutées dans CERT : vulnérabilité SSH CBC.

    Vectis default security mechanisms do not depend on cryptographic algorithms or modes with known serious weaknesses.

    The default cryptographic profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Internal storage encryption uses
    AES-256/GCM. Other supported profiles use SHA-3 and AES-GCM with stronger parameter sets.

    Vectis does not use SHA-1, MD5, DES, Triple DES, RC4, ECB, unauthenticated CBC encryption, or legacy TLS cipher suites. Encryption uses authenticated
    modes with contextual AAD, while TLS is provided through rustls with modern defaults.

    FPE uses FF1 with AES-256 and validates the minimum domain size required by the current FF1 specification. The default profile-only policy also prevents
    requests from selecting arbitrary cryptographic algorithms.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    À peine suffisant pour un badge.

    Les mécanismes de sécurité dans le logiciel produit par le projet DEVRAIENT implémenter la confidentialité persistante pour les protocoles d'échange de clés afin qu'une clé de session dérivée d'un ensemble de clés à long terme ne soit pas compromise si l'une des clés à long terme est compromise dans le futur. [crypto_pfs]

    Vectis partially satisfies this criterion through TLS: HTTPS connections use rustls and modern ephemeral TLS key exchange.

    However, the protected-message protocol does not currently provide full perfect forward secrecy. Each sender generates a fresh ephemeral X25519 or
    X448 key and a fresh ML-KEM encapsulation, but both are established against the recipient's persistent operational public keys.

    The envelope retains the sender's ephemeral public key, ML-KEM ciphertext, salt, and encrypted payload. An attacker who records an envelope and later
    obtains the recipient's complete operational private key material could reconstruct both shared secrets and derive the historical message key.

    Fresh per-message key establishment prevents key and nonce reuse and isolates messages from each other, but it does not protect historical messages after
    recipient long-term key compromise.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md


    Assez pour un badge !

    Si le logiciel produit par le projet entraîne la sauvegarde de mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être sauvegardés comme hachages itérés avec un salage par utilisateur en utilisant un algorithme d'étirement de clé (itéré) (par exemple Argon2id, Bcrypt, Scrypt, ou PBKDF2). Voir également le pense-bête sur le stockage des clés d'OWASP. [crypto_password_storage]
    Ce critère s'applique uniquement lorsque le logiciel applique l'authentification des utilisateurs utilisant des mots de passe pour les utilisateurs extérieurs (càd l'authentification entrante), telles que des applications Web côté serveur. Il ne s'applique pas dans les cas où le logiciel sauvegarde des mots de passe pour l'authentification dans d'autres systèmes (càd l'authentification sortante, par exemple, le logiciel implémente un client pour un autre système), car au moins certaines parties de ce logiciel doivent avoir souvent accès au mot de passe en clair.

    Not applicable. Vectis does not provide password-based authentication and does not store passwords belonging to external users.

    HTTP authentication uses high-entropy API keys generated from a CSPRNG. The server stores a keyed HMAC verifier derived from protected init key material,
    rather than storing the API key in plaintext. Client authorization data uses the same keyed identifier model inside signed configuration.

    The unseal key, database credentials, TLS private keys, and similar operator secrets are not external-user passwords and are governed by separate storage
    and deployment controls.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/apikey.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/internal_keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/permissions.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    Assez pour un badge !

    Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT générer toutes les clés cryptographiques et les nonces en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé, et NE DOIVENT PAS le faire en utilisant des générateurs qui ne seraient pas cryptographiquement sécurisés. [crypto_random]
    Un générateur de nombres aléatoires cryptographiquement sécurisé peut être un générateur de nombres aléatoires matériel ou un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) utilisant un algorithme tel que Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Des exemples d'appels de générateurs de nombres aléatoires sûrs incluent java.security.SecureRandom en Java et window.crypto.getRandomValues ​​de JavaScript. Des exemples d'appels de générateurs de nombres aléatoires non sûrs incluent java.util.Random en Java et Math.random en JavaScript.

    Vectis generates cryptographic keys, nonces, salts, tokens, commitment openings, and secret-sharing coefficients using Botan's cryptographically
    secure random number generator.

    The core crypto module centralizes random generation through RandomNumberGenerator::new(), random_bytes(), and random_bytes_with_rng(). Cryptographic operations may reuse one Botan RNG during a single operation, but they do not replace it with a non-cryptographic generator.

    This CSPRNG is used for:

    • symmetric and asymmetric operational key generation;
    • EdDSA, X25519/X448, ML-DSA, ML-KEM, and SLH-DSA material;
    • AES-GCM and ChaCha20Poly1305 nonces;
    • ML-KEM and HKDF salts;
    • reversible random tokens;
    • commitment openings;
    • Shamir secret-sharing coefficients and set identifiers;
    • API keys, unseal keys, signature serials, and audit chain identifiers.

    Non-cryptographic counters used for request correlation are not used as keys, nonces, salts, tokens, or other cryptographic material. Vectis does not use
    thread_rng, fastrand, timestamps, counters, or similar non-cryptographic sources for security-sensitive randomness.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/key_material.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/src/core/tokenization.rs
    https://github.com/liesware/Vectis/blob/main/src/core/sharing.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/commitments.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/init.rs


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


    Assez pour un badge !

    Le projet DOIT utiliser un mécanisme de livraison qui contrecarre les attaques MITM. L'utilisation de https ou ssh+scp est acceptable. [delivery_mitm]
    Un mécanisme encore plus fort distribue le logiciel sous forme de paquetages signés numériquement, car cela atténue les attaques sur le système de distribution, mais cela ne fonctionne que si les utilisateurs peuvent être convaincus que les clés publiques pour les signatures sont correctes et si les utilisateurs vérifient la signature.

    Distribution channels use HTTPS exclusively. [osps_br_03_02]


    Assez pour un badge !

    Un hachage cryptographique (par exemple, un sha1sum) NE DOIT PAS être récupéré par http et utilisé sans vérifier une signature cryptographique. [delivery_unsigned]
    Ces hachages peuvent être modifiés en transit.

    Vectis does not retrieve cryptographic hashes over plain HTTP and use them for integrity decisions without signature verification.

    Source and dependency downloads use HTTPS. Cargo dependencies are resolved through Cargo.lock, which records package checksums and pins the Git-based FPEdependency to a specific commit. Container base images are referenced by immutable SHA-256 digests.

    Release SHA256SUMS are generated locally inside the trusted GitHub Actions release workflow; they are not downloaded from an untrusted HTTP source.
    Release archives also receive GitHub build-provenance attestations before publication.

    No build, installation, update, or release workflow retrieves a checksum over plain HTTP and then trusts that checksum without an authenticated mechanism.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml


  • Vulnérabilités publiquement identifiées et corrigées


    Assez pour un badge !

    Il ne DOIT pas y avoir de vulnérabilités non corrigées de gravité moyenne ou supérieure connues publiquement depuis plus de 60 jours. [vulnerabilities_fixed_60_days]
    La vulnérabilité doit être corrigée et diffusée par le projet lui-même (les correctifs peuvent être développés ailleurs). Une vulnérabilité devient publique (à cet effet) une fois qu'elle a un CVE avec des informations non payantes publiquement publiées (signalée, par exemple, dans la Base de données Nationale des Vulnérabilités) ou lorsque le projet a été informé et que l'information a été diffusée au public (éventuellement par le projet). Une vulnérabilité est considérée de gravité moyenne ou supérieure si son score de base qualitatif du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.Note : cela signifie que les utilisateurs peuvent être laissés vulnérables à tous les attaquants du monde entier jusqu'à 60 jours. Ce critère est souvent beaucoup plus facile à atteindre que ce que Google recommande dans son Redémarrage de la divulgation responsable, car Google recommande que la période de 60 jours commence lorsque le projet est notifié même si le rapport n'est pas public. Notez que ce critère de badge, comme d'autres critères, s'applique à un projet individuel. Certains projets font parti d'organisations ou de projets englobants, parfois à plusieurs niveaux, et de nombreux projets fournissent leurs résultats à d'autres organisations et projets au sein d'une chaîne approvisionnement potentiellement complexe. Un projet individuel ne peut souvent pas contrôler le reste, mais un projet individuel peut travailler à fournir un correctif de vulnérabilité à temps. Pour cette raison, nous nous concentrons seulement sur le temps de réponse des projets individuels. Une fois qu'un correctif est disponible de la part d'un projet individuel, les autres projets peuvent déterminer comment appliquer le correctif (par exemple, ils peuvent mettre à jour la dernière version ou ils peuvent appliquer uniquement le correctif).

    As of 2026-08-21, Vectis has no publicly known unpatched vulnerability of Medium, High, or Critical severity that has remained unresolved for more than
    60 days.

    The project runs cargo audit in CI against the committed Cargo.lock. A current scan of 362 Rust dependencies completed successfully with no vulnerabilities.
    The previously reported RUSTSEC-2026-0258 vulnerability in h2 was remediated by upgrading to h2 0.4.16.

    Container release candidates are scanned with Trivy before publication, and CodeQL analyzes the source code. Security findings and dependency updates are
    handled through the documented vulnerability-reporting process.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Assez pour un badge !

    Les projets DEVRAIENT corriger rapidement toutes les vulnérabilités critiques après leur signalement. [vulnerabilities_critical_fixed]

    No Critical severity vulnerability has been reported or publicly identified in Vectis to date, and no confirmed Critical vulnerability remains unresolved.

    Vectis accepts private vulnerability reports through its published security policy, aims to acknowledge reports within five business days, provides status
    updates during investigation, and coordinates fixes and disclosure with the reporter.

    Critical findings would receive immediate triage and an expedited tested release before coordinated public disclosure. Cargo Audit, CodeQL, Trivy,
    OpenSSF Scorecard, and security-focused testing provide continuous detection paths for vulnerabilities requiring this response.

    Because no Critical vulnerability has been reported, Vectis does not yet have a historical Critical-vulnerability remediation time to report.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


  • Autres problèmes de sécurité


    Assez pour un badge !

    Les dépôts publics NE DOIVENT PAS fuiter un certificat privé valide (par exemple, un mot de passe ou une clé privée) qui est destiné à limiter l'accès public. [no_leaked_credentials]
    Un projet PEUT fuiter des « échantillons » de certificats pour les tests et pour des bases de données sans importance, pour autant qu'ils ne soient pas destinés à limiter l'accès public.

    Vectis public repositories do not contain valid private credentials intended to control access to private resources.

    Runtime secret files such as .env, .unseal_key, init.json, TLS private keys, databases, generated configuration, and local demo state are excluded from
    version control. Demo and integration scripts generate temporary credentials at runtime instead of embedding reusable credentials.

    GitHub Actions retrieves publishing credentials through the GitHub Secrets context. The Helm chart accepts secrets through operator-supplied values or an
    existing Kubernetes Secret and does not contain populated credentials.

    Values shown in env.dist and documentation are synthetic localhost examples. They do not grant access to any public or private service and are not production
    credentials.

    A review of tracked files and repository history found no committed private-key blocks or recognizable live access-token formats.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.gitignore
    https://github.com/liesware/Vectis/blob/main/env.dist
    https://github.com/liesware/Vectis/blob/main/charts/vectis/values.yaml
    https://github.com/liesware/Vectis/blob/main/charts/vectis/templates/secret.yaml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Analyse 8/8 ●

  • Analyse statique de code


    Assez pour un badge !

    Au moins un outil d'analyse statique de code (au-delà des avertissements du compilateur et des modes « sûrs » des languages) DOIT être appliqué à toute distribution majeure proposée avant sa sortie s'il existe au moins un outil FLOSS qui implémente ce critère dans le langage sélectionné. [static_analysis]
    Un outil d'analyse statique de code examine le code logiciel (au niveau du code source, du code intermédiaire ou de l'exécutable) sans l'exécuter avec des entrées spécifiques. Aux fins de ce critère, les avertissements du compilateur et les modes de langage « sûrs » ne comptent pas comme des outils d'analyse statique de code (ceux-ci évitent généralement une analyse approfondie car la rapidité est vitale). Certains outils d'analyse statique se concentrent sur la détection de défauts génériques, d'autres se concentrent sur la détection de défauts spécifiques (tels que les vulnérabilités) et d'autres encore proposent une combinaison de ces deux types d'outils. Des exemples de tels outils d'analyse statique de code incluent cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (y compris FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy et HP Enterprise Fortify Static Code Analyzer. Des listes plus vastes d'outils peuvent être trouvées dans des endroits tels que la liste Wikipedia d'outils pour l'analyse statique de code, l'information OWASP sur l'analyse statique de code, la liste NIST des analyseurs de sécurité du code source et la liste des outils d'analyse statique de Wheeler. S'il n'y a pas d'outil d'analyse statique FLOSS disponible pour le(s) langage(s) d'implémentation utilisé(s), sélectionnez « N/A ».

    Vectis uses CodeQL as a static source-code analysis tool beyond compiler warnings and Rust's memory-safety guarantees.

    CodeQL analyzes both Rust source code and GitHub Actions workflows. It runs for pull requests targeting main, every push to main, on a weekly schedule, and on manual request. Proposed release commits are merged into main and reviewed through this analysis before being tagged for release.

    Cargo Clippy, Cargo Audit, Trivy, and OpenSSF Scorecard provide additional analysis, but CodeQL is the static source-code analysis mechanism used to
    satisfy this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning


    Assez pour un badge !

    Il est PROPOSÉ qu'au moins l'un des outils d'analyse statique utilisés pour le critère d'analyse statique inclue des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé. [static_analysis_common_vulnerabilities]
    Les outils d'analyse statique spécialement conçus pour détecter les vulnérabilités les plus courantes sont plus susceptibles de les détecter. Cela dit, l'utilisation d'outils statiques aidera généralement à trouver des problèmes, nous suggérons donc, sans l'exiger, de le faire pour le badge de niveau « passant ».

    Vectis uses the CodeQL default security query suite for Rust and GitHub Actions.

    The Rust query suite includes vulnerability-focused data-flow and source-to-sink analysis mapped to common CWE categories, including:

    • SQL injection;
    • server-side request forgery;
    • path and regular-expression injection;
    • log injection and sensitive-data logging;
    • cleartext storage and transmission;
    • disabled TLS certificate verification;
    • hard-coded cryptographic values;
    • weak cryptographic algorithms;
    • uncontrolled allocation sizes;
    • invalid pointer and lifetime access.

    CodeQL also analyzes GitHub Actions workflows for security-relevant workflow issues. The analysis runs on pull requests, pushes to main, weekly, and on
    manual request.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning
    https://docs.github.com/en/code-security/code-scanning/managing-your-code-scanning-configuration/rust-built-in-queries
    https://codeql.github.com/codeql-query-help/rust-cwe/


    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse statique de code DOIVENT être corrigées en temps approprié après leur confirmation. [static_analysis_fixed]
    Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public. Remarquez que le critère vulnerabilities_fixed_60_days nécessite que de telles vulnérabilités soient corrigées dans les 60 jours de leur divulgation publique.

    Not applicable at present. CodeQL has not produced a confirmed exploitable Medium, High, or Critical severity vulnerability in Vectis that requires
    remediation.

    CodeQL continues to analyze Rust source code and GitHub Actions on pull requests, pushes to main, weekly, and on manual request. Any future finding is
    reviewed to distinguish an exploitable vulnerability from a false positive or non-security issue.

    A confirmed exploitable finding of Medium severity or higher will be fixed, covered by a regression test where practical, and recorded in the relevant
    release notes or security advisory.

    Evidence:
    https://github.com/liesware/Vectis/security/code-scanning
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md


    Assez pour un badge !

    Il est PROPOSÉ que l'analyse statique du code source se produise à chaque commit ou au moins quotidiennement. [static_analysis_often]

    Vectis runs static source-code analysis on every commit that is proposed for or integrated into the main branch.

    The CodeQL workflow is triggered by:

    • every push to main;
    • every pull request targeting main, including new commits pushed to that PR;
    • a weekly scheduled scan as a fallback;
    • manual workflow dispatch.

    Therefore, each commit entering the supported development and release branch is analyzed without relying solely on the scheduled scan.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml


  • Analyse dynamique de code


    Assez pour un badge !

    Il est PROPOSÉ qu'au moins un outil d'analyse dynamique soit appliqué à tout candidat pour une version majeure du logiciel avant sa distribution. [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.

    Vectis applies dynamic analysis to every change proposed for or integrated into the main branch.

    The CI integration job starts a real Vectis server with generated keys and configuration, then runs project-specific HTTP mutation testing and
    OpenAPI-based property testing with Schemathesis. These tools exercise live handlers, parsers, validation, authorization, cryptographic workflows, and
    failure paths using generated and mutated inputs.

    Vectis also runs its native cargo-fuzz targets weekly with sanitizer instrumentation and accumulated corpora. This workflow can be triggered manually before a major production release.


    Assez pour un badge !

    Il est PROPOSÉ que, si le logiciel produit par le projet comprend un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple, C ou C ++), au moins un outil dynamique (par exemple, un fuzzer ou un scanner d'application Web) soit utilisé de façon routinière en combinaison avec un mécanisme pour détecter des problèmes de sécurité mémoire tels que les dépassements de zone mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, choisissez « non applicable » (N/A). [dynamic_analysis_unsafe]
    Des exemples de mécanismes pour détecter les problèmes de sécurité de la mémoire comprennent Address Sanitizer (ASAN) (disponible dans GCC et LLVM), Memory Sanitizer et valgrind. D'autres outils potentiellement utilisés incluent thread sanitizer et undefined behavior sanitizer. La généralisation de l'utilisation des assertions fonctionnera également.

    Not applicable. Vectis is implemented in Rust and does not include project-maintained production code written in a memory-unsafe language such as
    C or C++.

    Vectis interfaces with Botan through FFI, but Botan is an external dependency rather than memory-unsafe source code produced or maintained by the Vectis
    project. Native fuzzing and sanitizer-based testing are nevertheless used to exercise Vectis input-processing boundaries.


    Assez pour un badge !

    Il est PROPOSÉ que le projet utilise une configuration pour au moins une analyse dynamique (comme le test ou le fuzzing) qui active de nombreuses assertions. Dans de nombreux cas, ces assertions ne doivent pas être activées dans les versions de production. [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.

    Vectis runs its automated test suite using Rust's test profile. This profile enables debug assertions and integer overflow checks that are not enabled by
    default in production release builds.

    The test suite contains assertions covering validation, cryptographic round-trips, lifecycle rules, authorization, storage, audit-chain integrity,
    and HTTP contracts. Native cargo-fuzz targets add explicit semantic assertions for properties such as canonical serialization, stable encoding, sanitized
    errors, and parser round-trips.

    These assertion-enabled test and fuzz configurations are separate from the production release profile.


    Assez pour un badge !

    Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse de code dynamique DOIVENT être corrigées en un temps approprié après leur confirmation. [dynamic_analysis_fixed]
    Si vous n'utilisez pas d'analyse de code dynamique et n'avez donc trouvé aucune vulnérabilité de cette manière, choisissez « non applicable » (N/A). Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.

    Not applicable at present. Vectis has no outstanding confirmed exploitable vulnerabilities of Medium or higher severity discovered through dynamic
    analysis.

    Findings produced by fuzzing and dynamic API testing are investigated before being dismissed. Confirmed defects are fixed, added to the regression test
    suite, and preserved as readable fuzz seeds when applicable.

    A recent canonical JSON fuzzing finding was corrected with centralized input validation, unit and HTTP regression tests, and a permanent cargo-fuzz seed. It was not formally classified as a Medium-or-higher vulnerability.



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 Liesware et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Liesware.
Soumission créée le 2026-08-21 14:40:13 UTC, dernière mise à jour le 2026-08-21 16:38:28 UTC.