Vectis

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 14194 ist in_progress So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14194/badge)](https://www.bestpractices.dev/projects/14194)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/14194"><img src="https://www.bestpractices.dev/projects/14194/badge"></a>


Dies sind die Kriterien das Level Passing. Sie können auch die Kriterien für die Level Silber oder Gold sehen.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 12/13 ●

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

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

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

    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.

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]
    Dies MUSS in einer Sprache sein, die potenzielle Nutzer verstehen können (z. B. möglichst wenig Fachbegriffe verwenden).

    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.


    Genug für ein Badge!

    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

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


    Genug für ein Badge!

    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]
    Wir nehmen an, dass Projekte auf GitHub Issues und Pull-Requests verwenden, sofern nichts anders angegeben ist. Diese Information kann kurz sein, z. B., dass das Projekt Pull-Requests, einen Issue-Tracker oder eine Mailing-Liste verwendet (welche?)

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


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z. B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]

  • FLOSS-Lizenz


    Genug für ein Badge!

    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]
    FLOSS-Software erfüllt die Open Source Definition oder die Free Software Definition. Beispiele für solche Lizenzen sind die CC0 , MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0 , Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL) . Für unsere Zwecke bedeutet dies, dass die Lizenz: Die Software kann auch über andere Wege lizenziert werden (z.B. "GPLv2 oder proprietär" ist akzeptabel).

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


    Genug für ein Badge!

    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]
    Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

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


    Genug für ein Badge!

    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]
    Eine Konvention ist es die Lizenz als eine Top-Level-Datei mit der Bezeichnung LICENSE oder COPYING zu veröffentlichen. Lizenzdateinamen DÜRFEN eine Erweiterung wie ".txt" oder ".md" haben. Eine alternative Konvention ist es einen Ordern mit dem namen LICENSES zu erstellen und dort alle Lizenz(en) abzuspeicehrn; diese dateien sind typischerweise mit ihreren SPDX License Identifier benannt und einer passendend Dateiendung; siehe Beschreibung dieser Konvention in der REUSE Specification. Beachten Sie, dass dieses Kriterium nur eine Voraussetzung für das Quell-Repository ist. Sie müssen die Lizenzdatei NICHT hinzufügen, wenn Sie etwas aus dem Quellcode generieren (z. B. eine ausführbare Datei, ein Paket oder einen Container). Wenn Sie beispielsweise ein R-Paket für das Comprehensive R Archive Network (CRAN) generieren, befolgen Sie die Standard-CRAN-Praxis: Wenn die Lizenz eine Standardlizenz ist, verwenden Sie die Standard-Kurzlizenzspezifikation (um die Installation einer weiteren Kopie des Textes zu vermeiden) die LICENSE-Datei in einer Ausschlussdatei wie .Rbuildignore. Ebenso können Sie beim Erstellen eines Debian-Pakets einen Link in die Copyright-Datei zum Lizenztext in /usr/share/common-licenses einfügen und die Lizenzdatei vom erstellten Paket ausschließen (z.B. durch Löschen der Datei nach dem Aufruf von dh_auto_install). Wir empfehlen, maschinenlesbare Lizenzinformationen in generierten Formaten zu integrieren, wo dies praktisch ist.

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


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]
    Diese Dokumentation muss in irgendeinem Medium sein (z.B. Text oder Video), das Folgendes beinhaltet: wie man die Software installiert, wie man sie startet, wie man sie benutzt (evtl. ein Tutorial mit Beispielen) und wie man sie sicher benutzt (z. B. was zu tun und zu lassen ist), wenn das ein passendes Einsatzgebiet für die Software ist. Die Sicherheitsdokumentation muss nicht lange sein. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    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


    Genug für ein Badge!

    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]
    Die Dokumentation einer externen Schnittstelle erklärt einem Endbenutzer oder Entwickler, wie man sie benutzt. Dies beinhaltet auch eine Programmierschnittstelle (API), falls die Software eine hat. Wenn es sich um eine Bibliothek handelt, dokumentieren Sie die wichtigsten Klassen/Typen und Methoden/Funktionen, die aufgerufen werden können. Wenn es sich um eine Webanwendung handelt, definieren Sie ihre URL-Schnittstelle (häufig eine REST-Schnittstelle). Wenn es sich um eine Befehlszeilenschnittstelle handelt, dokumentieren Sie die Parameter und Optionen, die sie unterstützt. In vielen Fällen ist es am besten, wenn die meisten dieser Dokumente automatisch generiert werden, so dass diese Dokumentation mit der sich ändernden Software synchronisiert bleibt, aber dies ist nicht erforderlich. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Dokumentation DARF automatisch generiert werden (falls möglich ist dies oft der beste Weg). Die Dokumentation einer REST-Schnittstelle kann mit Swagger/OpenAPI erzeugt werden. Code-Interface-Dokumentation kann mit Werkzeugen wie JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) und Doxygen (verschiedene) generiert werden. Nur Kommentare im Quelltext reicht nicht aus, um dieses Kriterium zu erfüllen; Es muss einen einfacheren Weg geben, um die Informationen zu sehen, ohne den ganzen Quellcode durchzulesen. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    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


  • Andere


    Genug für ein Badge!

    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]
    Dies setzt voraus, dass die Projekt-Homepage-URL und die URL des Versionskontroll-Repositories mit "https:", nicht "http:" beginnt. Sie können kostenlose Zertifikate von Let's Encrypt erhalten. Projekte KÖNNEN dieses Kriterium implementieren, indem Sie (z. B.) GitHub-Pages verwenden, GitLab-Pages oder SourceForge project pages. Wenn Sie HTTP unterstützen, empfehlen wir Ihnen, den HTTP-Datenverkehr an HTTPS umzuleiten.

    Given only https: URLs.


    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]
    Beispiele für akzeptable Mechanismen umfassen archivierte Mailingliste(n), GitHub Issues und Pull-Request-Diskussionen, Bugzilla, Mantis und Trac. Asynchrone Diskussionsmechanismen (wie IRC) sind akzeptabel, wenn sie diese Kriterien erfüllen; Stellen Sie sicher, dass es einen URL-adressierbaren Archivierungsmechanismus gibt. Proprietäres JavaScript ist ungern gesehen, aber erlaubt.

    GitHub supports discussions on issues and pull requests.


    Genug für ein Badge!

    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]
    Englisch ist derzeit die Lingua Franca der Computertechnik; Wenn Englisch unterstützt wird, erhöht das die Anzahl der verschiedenen potenziellen Entwickler und Reviewer weltweit. Ein Projekt kann dieses Kriterium auch dann erfüllen, wenn die Hauptsprache der Kernentwickler nicht Englisch ist.

    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


    Genug für ein Badge!

    Das Projekt MUSS gepflegt werden. [maintained]
    Als Minimum sollte das Projekt versuchen, auf wichtige Problem- und Schwachstellenberichte zu reagieren. Ein Projekt, das aktiv ein Badge anstrebt, wird wahrscheinlich gepflegt. Alle Projekte und Menschen haben begrenzte Ressourcen, und typische Projekte müssen einige vorgeschlagene Änderungen ablehnen, daher deuten begrenzte Ressourcen und Ablehnungen von Vorschlägen allein nicht auf ein ungepflegtes Projekt hin.

    Wenn ein Projekt weiß, dass es nicht mehr gepflegt wird, sollte es dieses Kriterium auf "Unerfüllt" setzen und die entsprechenden Mechanismen verwenden, um anderen anzuzeigen, dass es nicht gepflegt wird. Verwenden Sie zum Beispiel "DEPRECATED" als erste Überschrift seiner README, fügen Sie "DEPRECATED" am Anfang seiner Homepage hinzu, fügen Sie "DEPRECATED" am Anfang der Projektbeschreibung seines Code-Repositorys hinzu, fügen Sie ein no-maintenance-intended Badge in seiner README und/oder Homepage hinzu, markieren Sie es als veraltet in allen Paket-Repositories (z. B. npm deprecate) und/oder verwenden Sie das Markierungssystem des Code-Repositorys, um es zu archivieren (z. B. GitHubs "archive"-Einstellung, GitLabs "archived"-Markierung, Gerrits "readonly"-Status oder SourceForges "abandoned"-Projektstatus). Weitere Diskussionen finden Sie hier.

    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


 Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
    Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).

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


    Genug für ein Badge!

    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

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


    Genug für ein Badge!

    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]
    Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).

    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


    Genug für ein Badge!

    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

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


  • Einzigartige Versionsnummerierung


    Genug für ein Badge!

    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
    Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datumsbasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.

    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


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]
    Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder datumsbasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).

    Gerade genug für ein Badge.

    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [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.


  • Versionshinweise


    Genug für ein Badge!

    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]
    Die Releasenotes DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll, in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Releasenotes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.

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


    Genug für ein Badge!

    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]
    Dieses Kiterium hilft Benutzer zu verstehen ob ein Update eine bestimmte öffentlich bekannte Sicherheitslücke schließt, und zu entscheiden ob das Update eingespielt wird oder nicht. Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie stattdessen "nicht anwendbar" (N/A), da diese zusätzliche Information für den Benutzer nicht hilfreich ist. Ein Projekt kann auch N/A auswählen wenn alle Empfänger nur die neuste Version benutzen (z. B. wenn der Code für eine einzelne Webseite oder Internetdienst ist der continuierlich mittels Contious Delivery geupdated wird). Diese Kriterium betrifft nur die Projektergenbisse, nicht seine Abhängigkeiten. Alle Sicherheitslücken für alle Abhängigkeiten eines Projektes aufzulisten ist unhandlich weil Abhängikeiten sich regelmäßig ändern könen; außerdem ist es unnötig weil Tools die sich auf die Analyse von Abhängikeiten spezialisieren das viel skalierbarer hin bekommen.

    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


 Berichterstattung 6/8 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

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


    Genug für ein Badge!

    Das Projekt SOLLTE einen Issue-Tracker für die Nachverfolgung einzelner Issues verwenden. [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


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
    Die Antwort DARF "nein" oder eine Diskussion über ihre Vorzüge sein. Das Ziel ist einfach, dass es einige Antworten auf einige Anfragen gibt, was darauf hinweist, dass das Projekt noch am Leben ist. Für die Zwecke dieses Kriteriums müssen die Projekte keine falschen Anfragen (z.B. von Spammern oder automatisierten Systemen) zählen. Wenn ein Projekt keine weiteren Verbesserungen vornimmt, wählen Sie bitte "Unerfüllt" und geben Sie die URL ein, die diesen Zustand den Benutzern klar macht. Wenn ein Projekt von der Anzahl der Verbesserungsvorschläge überwältigt wird, wählen Sie bitte "Unerfüllt" und erklären Sie die Situation.

    Genug für ein Badge!

    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [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


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]
    z.B., eine klar benannte Mailing-Adresse auf https://PROJECTSITE/security, oft in der Form security@example.org. Dies KANN die gleiche sein wie die für den Fehlerberichtsprozess. Informationen über Schwachstellen können immer öffentlich sein, aber viele Projekte verfügen über einen privaten Schwachstellen-Berichtsmechanismus.

    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


    Genug für ein Badge!

    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]
    Beispiele hierfür sind ein privater Defektbericht, der im Internet über HTTPS (TLS) oder eine mit OpenPGP verschlüsselte E-Mail verschickt wird. Wenn die Informationsübertragung von Schwachstellen immer öffentlich sind (also gibt es niemals private Informationsübertragung von Schwachstellen), wählen Sie "nicht anwendbar" (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


    Genug für ein Badge!

    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (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ät 13/13 ●

  • Produktivsystem


    Genug für ein Badge!

    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Quellcode automatisch in Software übersetzt. [build]
    Ein Build-System bestimmt, welche Aktionen durchgeführt werden müssen, um die Software neu zu bauen (und in welcher Reihenfolge) und führt dann diese Schritte aus. Zum Beispiel kann es einen Compiler aufrufen, um den Quellcode zu kompilieren. Wenn eine ausführbare Datei aus dem Quellcode erstellt wird, muss es möglich sein, den Quellcode des Projekts zu ändern und dann eine aktualisierte ausführbare Datei mit diesen Modifikationen zu erzeugen. Wenn die vom Projekt produzierte Software von externen Bibliotheken abhängt, muss das Build-System diese externen Bibliotheken nicht bauen. Wenn es keine Notwendigkeit gibt, irgendetwas zu bauen, um die Software zu verwenden, nachdem ihr Quellcode geändert wurde, wählen Sie "nicht anwendbar" (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


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. [build_common_tools]
    Beispielsweise, Maven, Ant, cmake, die Autotools, make, rake (Ruby) oder 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


    Genug für ein Badge!

    Das Projekt SOLLTE allein mit FLOSS-Werkzeugen gebaut werden können. [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


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Das Projekt MUSS mindestens eine automatisierte Test-Suite verwenden, die öffentlich als FLOSS veröffentlicht wird (diese Test-Suite kann als separates FLOSS-Projekt gepflegt werden). Das Project MUSS verständlich zeigen oder dokumentieren, wie die Test-Suite ausgeführt wird (z. B. durch ein Continuous Integration (CI) Script oder als Dokumentation in Dateien, wie z. B. BUILD.md, README.md oder CONTRIBUTING.md). [test]
    Das Projekt KANN mehrere automatisierte Test-Suiten benutzen (z. B. eine, die schnell läuft, eine andere, die gründlicher ist, aber spezielle Ausrüstung erfordert). Es gibt viele Test-Frameworks und Systeme die Tests unterstützten, einschließlich Selenium (web browser automation), 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


    Genug für ein Badge!

    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "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


    Gerade genug für ein Badge.

    Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [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


    Genug für ein Badge!

    Es wird erwartet, dass das Projekt eine kontinuierliche Integration durchführt (wo neuer oder geänderter Code häufig in ein zentrales Code-Repository integriert wird und automatisierte Tests auf diesen Ergebnissen durchgeführt werden). [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


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

    Das Projekt MUSS allgemeine Grundregeln (formal oder nicht) haben, die als wesentliche neue Funktionalität der Software des Projektes hinzugefügt werden. Tests dieser Funktionalität sollten zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy]
    Solange Grundregeln vorhanden sind, selbst wenn durch Mundpropaganda, sollten die Entwickler/innen Tests für die automatisierte Test-Suite für große neue Funktionalität hinzufügen, wählen Sie "Met".

    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


    Genug für ein Badge!

    Das Projekt MUSS nachweisen, dass die test_policy für das Hinzufügen von Tests in den jüngsten großen Änderungen an der Projektsoftware eingehalten wurde. [tests_are_added]
    Wichtige Funktionalitäten würden typischerweise in den Patchnotes erwähnt. Perfektion ist nicht erforderlich, nur Beweise dafür, dass Tests in der Praxis in der Regel der automatisierten Test-Suite hinzugefügt werden, wenn neue Hauptfunktionalität der Projektsoftware hinzugefügt wird.

    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


    Genug für ein Badge!

    Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.

    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


  • Warnhinweise


    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache [warnings]
    Beispiele für Compiler-Warn-Flags sind gcc / clang "-Wall". Beispiele für einen "sicheren" Sprachmodus beinhalten JavaScript "use strict" und perl5's "use warnings". Ein separates "Linter" -Tool ist einfach ein Werkzeug, das den Quellcode untersucht, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen. Diese werden in der Regel im Quellcode aktiviert oder in den Einstellungen.

    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


    Genug für ein Badge!

    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]
    Dies sind die Warnungen, die durch die Umsetzung des warnings Kriteriums identifiziert wurden. Das Projekt sollte Warnungen beheben oder im Quellcode als falsch positives Ergebnis markieren. Idealerweise gibt es keine Warnungen, aber ein Projekt DARF einige Warnungen akzeptieren (typischerweise weniger als 1 Warnung pro 100 Zeilen oder weniger als 10 Warnungen).

    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


    Genug für ein Badge!

    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]
    Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

    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


 Sicherheit 15/16 ●

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]
    Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:
    • Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
    • Fehlersichere Voreinstellungen (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
    • Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Berechtigungen überprüft werden und darf nicht umgangen werden können)
    • Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter schützbare und änderbare Informationen wie Schlüssel und Passwörter)
    • Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z. B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
    • So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
    • So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
    • Psychologische Akzeptanz (Die menschliche Schnittstelle muss benutzerfreundlich entworfen werden - Design für "geringeste Überraschung" kann dabei helfen)
    • Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
    • Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).
    Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    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


    Genug für ein Badge!

    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]
    Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    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


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Nicht genug für ein Badge.

    Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]
    Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.

    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


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [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


    Genug für ein Badge!

    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]
    Siehe Open Standards Requirement for Software by the 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


    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]
    Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, und hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe https://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

    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


    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]
    Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR-Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z. B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

    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


    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    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


    Gerade genug für ein Badge.

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [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


    Genug für ein Badge!

    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Siehe auch OWASP Password Storage Cheat Sheet). [crypto_password_storage]
    Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von externan Benutzern mit Passwörtern erzwingt (inbound authentication), wie z. B. bei serverseitigen Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (outbound authentication, z. B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

    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


    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]
    Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Javas java.security.SecureRandom und JavaScripts window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Javas java.util.Random und JavaScripts Math.random.

    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


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Genug für ein Badge!

    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]
    Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.

    Distribution channels use HTTPS exclusively. [osps_br_03_02]


    Genug für ein Badge!

    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]
    Diese Hashes könnten bei der Übermittlung verändert werden.

    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


  • Öffentlich bekannte Schwachstellen wurden behoben


    Genug für ein Badge!

    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]
    Die Sicherheitslücke muss vom Projekt selbst gepatched und freigegeben werden (Patches dürfen woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen, nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird, selbst dann, wenn der Bericht nicht öffentlich ist. Beachten Sie auch, dass dieses Badge-Kriterium, wie andere Kriterien, auf einzelne Projekte zutrifft. Manche Projekte sind teil einer größeren Organisation oder eines größeren Projektes, möglicherweise als Teil mehrer Lagen, und manche Projekte füttern ihre Ergebnisse an andere Organisationen oder Projekte als teil einer möglicherweisen komplexen Lieferkette. Daher fokussieren wir uns auf die Antwortzeit einzelner Projekte. Wenn ein Projekt einen Patch bereitgestellt hat können andere entscheiden wie sie damit umgehen möchten (z. B. können sie auf eine neue Version upgraden oder nur einzelne Patches auswählen und einspielen).

    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


    Genug für ein Badge!

    Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. [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


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]
    Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.

    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 ●

  • Statische Codeanalyse


    Genug für ein Badge!

    Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert. [static_analysis]
    Ein Tool zur statischen Codeanalyse untersucht den Softwarecode (als Quellcode, Zwischencode oder ausführbare Datei), ohne ihn mit bestimmten Eingaben auszuführen. Für dieses Kriterium zählen Compilerwarnungen und "sichere" Sprachmodi nicht als statische Codeanalyse-Tools (diese vermeiden typischerweise eine tiefgreifende Analyse, da Geschwindigkeit entscheidend ist). Manche statischen Codeanalyse-Tools spezialisieren sich auf das Auffinden von generischen Defekten, andere spezialisieren sich auf das Finden von bestimmte Arten von Defekten (z.B. Schwachstellen) und manche können beides. Beispiele für solche Tools zur statischen Codeanalyse sind cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (including FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, und HP Enterprise Fortify Static Code Analyzer.. Mehr Tools finden Sie beispielsweise in der Wikipedia-Liste von Tools zur statischen Codeanalyse, OWASP Informationen zur statischen Code-Analyse , NIST-Liste der Quellcode-Sicherheitsanalyse-Tools und Wheelers Liste der statischen Analyse-Tools. Das SWAMP ist eine kostenlose Plattform zur Bewertung von Schwachstellen in Software mit einer Vielzahl von Tools. Wenn für die verwendete(n) Implementierungssprache(n) keine statischen FLOSS-Analysewerkzeuge verfügbar sind, wählen Sie "N/V".

    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


    Genug für ein Badge!

    Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, Regeln oder Ansätze einschließt, um nach häufigen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. [static_analysis_common_vulnerabilities]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    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/


    Genug für ein Badge!

    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]
    Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Beachten Sie, dass das Kriterium vulnerabilities_fixed_60_days verlangt, dass alle diese Schwachstellen innerhalb 60 Tagen nach Bekanntgabe gefixt werden.

    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


    Genug für ein Badge!

    Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. [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


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. [dynamic_analysis]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Zweig-Abdeckung sein. Die Englische Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite über Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    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.


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z. B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    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.


    Genug für ein Badge!

    Es ist EMPFHOLEN, dass das Projekt eine Konfigurations benutzt, die zumindest etwas dynamischen Analyse nutzt (wie z.B. testing oder fuzzing), welche Assertions erlauben. In vielen Fällen sollten diese Assertions nicht in Production Builds aktiviert sein. [dynamic_analysis_enable_assertions]
    Dieses Kriterium schlägt nicht vor, Assertions in der Produktionsumgebung zu aktivieren; das liegt ganz beim Projekt und seinen Benutzern. Stattdessen liegt der Fokus dieses Kriteriums darauf, die Fehlererkennung während der dynamischen Analyse vor der Bereitstellung zu verbessern. Das Aktivieren von Assertions im Produktionseinsatz unterscheidet sich völlig vom Aktivieren von Assertions während der dynamischen Analyse (wie z.B. Tests). In einigen Fällen ist das Aktivieren von Assertions im Produktionseinsatz äußerst unklug (insbesondere bei hochintegren Komponenten). Es gibt viele Argumente gegen das Aktivieren von Assertions in der Produktion, z.B. sollten Bibliotheken keine Aufrufer zum Absturz bringen, ihre Anwesenheit kann zur Ablehnung durch App Stores führen und/oder das Auslösen einer Assertion in der Produktion kann private Daten wie private Schlüssel offenlegen. Beachten Sie, dass in vielen Linux-Distributionen NDEBUG nicht definiert ist, sodass C/C++ assert() standardmäßig für die Produktion in diesen Umgebungen aktiviert wird. Es kann wichtig sein, einen anderen Assertion-Mechanismus zu verwenden oder NDEBUG für die Produktion in diesen Umgebungen zu definieren.

    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.


    Genug für ein Badge!

    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. [dynamic_analysis_fixed]
    Wenn Sie keine dynamische Codeanalyse ausführen und somit keine Schwachstellen auf diese Weise finden, wählen Sie "nicht anwendbar" (N/A). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde.

    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.



Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Liesware und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Liesware.
Eintrag erstellt: 2026-08-21 14:40:13 UTC, zuletzt aktualisiert: 2026-08-21 16:38:28 UTC.