vector_unity_cor

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 12787 - passing Вот как вставить его:
Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12787/badge)](https://www.bestpractices.dev/projects/12787)
- или HTML:
<a href="https://www.bestpractices.dev/projects/12787"><img src="https://www.bestpractices.dev/projects/12787/badge"></a>


Это критерии уровня Passing. Вы также можете просмотреть критерии уровня Silver или Gold.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы 13/13

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    vector_unity_cor ist der Infrastruktur-Kern für deterministische intelligente Systeme, der im Rahmen des Vector Unity-Ökosystems entwickelt wird. Das Projekt konzentriert sich auf die Erstellung einer energieeffizienten Datenmanagement-Architektur durch mehrdimensionale semantische Räume und Koordinatensynthese

    Используйте формат выражения лицензии SPDX; примеры включают «Apache-2.0», «BSD-2-Clause», «BSD-3-Clause», «GPL-2.0+», «LGPL-3.0+», «MIT» и «(BSD-2-Clause OR Ruby)».
    Если используется более одного языка, перечислите их через запятую (пробелы необязательны), и отсортируйте их от наиболее до наименее используемого. Если список длинный, пожалуйста, перечислите по крайней мере три наиболее распространенных. Если языка нет (например, это проект только для документации или только для тестирования), используйте один символ «-» (минус). Для каждого языка используйте общепринятую капитализацию названия, например «JavaScript».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

    Das Projekt ist offiziell bei der GVL (Gesellschaft zur Verwertung von Leistungsschutzrechten) unter dem Labelnamen „vector unity“ und dem Labelcode LC 104539 registriert. Die technische Architektur basiert auf einer Kombination aus Python für die semantische Analyse und Go für die performante Infrastruktursteuerung, um eine maximale Effizienz im autonomen Betrieb zu gewährleisten.

  • Основная информация на веб-сайте проекта


    Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). [description_good]
    Описание ОБЯЗАНО быть на языке, который могут понять потенциальные пользователи (например, с минимумом жаргона).

    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]
    Мы предполагаем, что проекты на GitHub используют issues и pull requests, если не указано иное. Описание может быть кратким, например, указывать, что проект использует pull requests, issue tracker или сообщения в список рассылки (какой?).

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



    В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]
  • Свободная лицензия


    ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. [floss_license]
    Свободное ПО (далее СПО) - это программное обеспечение, которое соответствует Определению Открытого ПО (официальный текст на англ.) или Определению Свободного Программного Обеспечения. Примеры таких лицензий включают CC0, MIT, BSD 2-Clause, BSD 3-Clause, Apache 2.0, Меньшая стандартная общественная лицензия GNU (LGPL) и Стандартная общественная лицензия GNU (GPL). Для наших целей это означает, что лицензия ОБЯЗАНА быть: ПО МОЖЕТ одновременно лицензироваться на других условиях (например, приемлема комбинация «GPLv2 или закрытая лицензия»).

    The MIT license is approved by the Open Source Initiative (OSI).



    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]
    Для одобрения OSI используется строгий процесс, чтобы определить, какие лицензии соответствуют Открытому ПО.

    The MIT license is approved by the Open Source Initiative (OSI).



    Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. (Требуется URL) [license_location]
    Например, в качестве файла верхнего уровня с именем LICENSE или COPYING. Имена файлов лицензии МОГУТ сопровождаться расширением, таким как «.txt» или «.md». Другим соглашением может быть наличие каталога с именем LICENSES, содержащего файлы лицензий; имена этих файлов обычно соответствуют SPDX-идентификатору лицензии, за которым следует соответствующее расширение файла, как описано в спецификации REUSE . Обратите внимание, что этот критерий является обязательным только для репозитория с исходным кодом. Вам НЕ нужно включать файл лицензии при генерации чего-либо из исходного кода (например, исполняемого файла, пакета или контейнера). Например, при создании пакета R для Comprehensive R Archive Network (CRAN) рекомендуется следовать стандартной практике CRAN: если лицензия является стандартной, используйте стандартную короткую спецификацию лицензии (чтобы избежать установки еще одной копии текста) и добавьте файл LICENSE в списке исключений, например .Rbuildignore. Аналогично, при создании пакета Debian вы можете поместить в файл copyright ссылку на текст лицензии в /usr/share/common-licenses и исключить файл лицензии из созданного пакета (например, удаляя файл после вызова dh_auto_install). Мы рекомендуем включать машиночитаемую информацию о лицензии в сгенерированных форматах, где это возможно.

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


  • Документация


    Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. [documentation_basics]
    Эта документация должна быть в некоторых формах (таких как текст или видео), которые включают в себя: как установить программное обеспечение, как его запустить, как его использовать (возможно, с помощью учебника с примерами) и как использовать его безопасно (например, что делать и чего не делать), если эти темы применимы для данного программного обеспечения. Документация по безопасности не обязательно должна быть длинной. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

    Das Projekt stellt eine grundlegende Dokumentation bereit, die alle notwendigen Schritte für die Installation, Konfiguration und den Start der Software umfasst. Die Dokumentation beinhaltet:

    Installationsanweisungen: Schritt-für-Schritt-Anleitung zur Einrichtung der Docker-Umgebung und der PostgreSQL-Datenbank.

    Konfiguration: Detaillierte Beschreibung der erforderlichen Umgebungsvariablen in der .env-Datei, einschließlich API-Schlüssel und Datenbankzugriffe.

    Bedienung: Erste Schritte zur Ausführung der Agenten und zur Nutzung des Data Hubs.
    Diese Dokumentation wird als README.md direkt im Repository gepflegt, um sicherzustellen, dass sie immer mit dem aktuellen Code-Stand übereinstimmt.



    Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. [documentation_interface]
    Документация внешнего интерфейса объясняет конечному пользователю или разработчику, как его использовать. Это может включать в себя интерфейс прикладного программирования (API), если программное обеспечение его имеет. Если это библиотека, документируйте основные классы/типы и методы/функции, которые можно вызвать. Если это веб-приложение, определите его URL-интерфейс (часто его интерфейс REST). Если это интерфейс командной строки, документируйте параметры и настройки, которые он поддерживает. Во многих случаях лучше всего, если большая часть этой документации будет автоматически сгенерирована, чтобы эта документация была синхронизирована с программным обеспечением по мере его изменения, но это не требуется. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Документация МОЖЕТ быть автоматически сгенерирована (там, где это применимо, это часто наилучший способ создания документации). Документация интерфейса REST может быть сгенерирована с использованием Swagger/OpenAPI. Документация по интерфейсу кода МОЖЕТ быть сгенерирована с использованием таких инструментов, как JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) и Doxygen (многие языки). Просто иметь комментарии в коде реализации недостаточно для выполнения этого критерия; должен быть простой способ увидеть информацию без чтения всего исходного кода. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

    Das Projekt stellt eine Referenzdokumentation in Form einer README.md-Datei im Hauptverzeichnis des Repositories bereit. Diese dokumentiert die API-Schnittstellen (z. B. die POST /task Endpunkte), die notwendigen Umgebungsvariablen in der .env-Datei sowie die Datenstruktur der PostgreSQL-Datenbank. Mit der Weiterentwicklung des Data Hubs wird die Dokumentation kontinuierlich um technische Spezifikationen der Input/Output-Vektoren ergänzt.


  • Другое


    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]
    Для выполнения этого критерия требуется, чтобы URL домашней страницы проекта начинался с "https:", а не "http:". Вы можете получить бесплатные сертификаты от проекта Let's Encrypt. Проекты МОГУТ выполнить этот критерий, используя (например) GitHub Pages, GitLab Pages или проектные страницы SourceForge. Если вы поддерживаете HTTP, мы настоятельно рекомендуем перенаправить HTTP-трафик на HTTPS.

    Given only https: URLs.



    Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. [discussion]
    Примерами приемлемых механизмов являются архивируемые списки рассылки, обсуждения в GitHub issues и pull requests, Bugzilla, Mantis и Trac. Асинхронные механизмы обсуждения (например, IRC) приемлемы, если они отвечают этим критериям; убедитесь, что есть механизм архивирования URL-адресов. Разрешено, хотя и не рекомендуется, использовать проприетарный JavaScript.

    GitHub supports discussions on issues and pull requests.



    Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. [english]
    Английский в настоящее время является лингва франка компьютерной техники; Поддержка английского языка увеличивает число потенциальных разработчиков и рецензентов во всем мире. Проект может соответствовать этому критерию, даже если английский не является основным языком его ключевых разработчиков.

    Das Projekt unterstützt aktiv die Internationalisierung und stellt Dokumentationen sowie technische Beschreibungen in drei Sprachen bereit: Englisch, Deutsch und Russisch. Fehlermeldungen (Issues), Kommentare im Code sowie Anfragen aus der Community können in jeder dieser Sprachen eingereicht und bearbeitet werden, um eine breite Zugänglichkeit für Entwickler weltweit zu gewährleisten.



    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]
    Как минимум, проект должен пытаться реагировать на сообщения о серьезных проблемах и уязвимостях. Проект, который активно добивается получения значка, вероятно, и поддерживается тоже. Ресурсы любого проекта и человека ограничены, и обычно проекты будут отклонять некоторые предлагаемые изменения; поэтому ограниченность ресурсов и отклонение предложений сами по себе не указывают на то, что проект не поддерживается.

    Если известно, что проект больше не будет поддерживаться, следует установить для этого критерия значение «Не соответствует» и использовать подходящие механизмы, чтобы указать другим, что он не поддерживается. Например, используйте “DEPRECATED” («УСТАРЕЛ») в качестве первого заголовка в файле README, добавьте “DEPRECATED” в начале его домашней страницы, добавьте “DEPRECATED” в начало описания проекта репозитория кода, добавьте значок об отсутствии поддержки в README проекта и/или домашнюю страницу, пометьте его как устаревший в любых репозиториях пакетов (напр., npm deprecate ) и/или используйте механизм, предоставленный репозиторием кода для его архивирования (например, параметр "archive" у GitHub или пометка "archive" у GitLab, статус «только для чтения» у Gerrit или статус «брошенного» проекта у SourceForge). Дополнительное обсуждение можно найти здесь .

    Das Projekt wird aktiv weiterentwickelt. Dies zeigt sich durch regelmäßige Commits im Repository, die Implementierung neuer Module wie des Data Hubs und die laufende Integration von Sicherheitsfiltern. Die aktuelle Roadmap sieht die Fertigstellung der Alpha-Phase vor, wobei der Fokus auf der Stabilität der autonomen Agenten und der Optimierung der PostgreSQL-Infrastruktur liegt. Der Umzug auf zusätzliche Hardwarekapazitäten zur Gewährleistung eines 24/7-Betriebs ist derzeit in der Umsetzung.


 Управление изменениями 9/9

  • Публичное хранилище исходного кода с поддержкой версий


    Проект ОБЯЗАН иметь репозиторий (хранилище) исходного кода с управлением версиями, который является общедоступным и имеет URL. [repo_public]
    URL МОЖЕТ быть таким же, как URL проекта. Проект МОЖЕТ использовать частные (непубличные) ветви в конкретных случаях, когда изменение не выпускается публично (например, для устранения уязвимости до того, как она будет открыта для публики).

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



    Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. [repo_track]

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



    Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. [repo_interim]
    Проекты МОГУТ опускать отдельные промежуточные версии из своих публичных репозиториев (например, те, которые фиксируют отдельные не обнародованные уязвимости, никогда не будут публично выпущены или включают материалы, которые не могут быть опубликованы на законных основаниях и не находятся в финальной версии).

    Das Projekt nutzt GitHub als primäres Quellcode-Repository. Alle Entwicklungsschritte, Fehlerbehebungen und Funktionserweiterungen werden kontinuierlich über Commits dokumentiert, bevor sie in einem finalen Release zusammengefasst werden. Dies ermöglicht eine lückenlose kollaborative Überprüfung jeder Zwischenversion direkt im Repository-Verlauf.



    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

    Das Projekt folgt dieser Empfehlung konsequent. Jede signifikante Version und jeder Release-Meilenstein wird im Git-Versionskontrollsystem mittels Git-Tags (z. B. git tag -a v0.1.1) eindeutig gekennzeichnet. Dies ermöglicht es Entwicklern und Benutzern, jederzeit auf den exakten Code-Stand einer bestimmten Version zuzugreifen und erhöht die Transparenz im Entwicklungsprozess der Vector Unity Infrastruktur.


  • Уникальная нумерация версий


    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]
    Это МОЖНО выполнить различными способами, включая идентификаторы коммита (например, идентификатор коммита git или идентификатор набора изменений mercurial) или номер версии (включая номера версий, которые используют семантическое версионирование или схемы на основе даты, такие как YYYYMMDD).

    Jede veröffentlichte Version des Projekts erhält eine eindeutige Versionskennung gemäß dem Semantic Versioning Prinzip (z. B. v0.1.0-alpha). Diese Kennungen werden im Quellcode-Repository über GitHub-Tags fixiert, sodass jede Version eindeutig identifizierbar und von früheren oder späteren Iterationen unterscheidbar ist. Dies gewährleistet die Nachvollziehbarkeit für Benutzer und automatisierte Systeme innerhalb der Vector Unity Infrastruktur.



    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]
    МОЖНО использовать в качестве номеров версий другие схемы нумерации версий, такие как идентификаторы коммитов (например, идентификатор коммита в git или идентификатор набора изменений в mercurial) или схемы на основе даты, такие как YYYYMMDD, поскольку они уникальны. Некоторые альтернативы могут вызвать трудности, поскольку пользователи могут быть не в состоянии легко определить, используют ли они последнюю версию. SemVer может оказаться менее полезным для идентификации версий программного обеспечения, если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-сервиса, который постоянно обновляется с помощью непрерывной доставки).


    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]

  • Примечания к выпуску


    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]
    Замечания к выпуску МОГУТ быть реализованы различными способами. Многие проекты предоставляют их в файле с именем «NEWS», «CHANGELOG» или «ChangeLog», возможно с расширениями, такими как «.txt», «.md» или «.html». Исторически термин «журнал изменений» означал журнал для каждого изменения, но для соответствия этим критериям требуется человекочитаемая сводка. Замечания к выпуску МОГУТ вместо этого быть предоставлены механизмами системы контроля версий, такими как процесс GitHub Releases.

    URL der Versionshinweise:
    Укажи ссылку на раздел релизов твоего репозитория (например: https://github.com/Vitalijwolf23/vector_unity_cor/releases).

    Begründung der Versionshinweise:

    Für jede neue Version des Projekts werden strukturierte Versionshinweise (Release Notes) erstellt, die über die reine Ausgabe von Git-Logs hinausgehen. Diese Zusammenfassungen beschreiben verständlich die funktionalen Erweiterungen, Sicherheitsupdates und architektonischen Änderungen innerhalb des Vector Unity Systems. Dies ermöglicht es den Nutzern, die Relevanz eines Upgrades sowie dessen Auswirkungen auf den autonomen Betrieb des Data Hubs sofort zu bewerten.



    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]
    Этот критерий помогает пользователям определить, исправит ли данное обновление общеизвестную уязвимость, чтобы помочь пользователям принять обоснованное решение об обновлении. Если пользователи обычно не могут практически самостоятельно обновлять программное обеспечение на своих компьютерах, а вместо этого должны полагаться на одного или нескольких посредников для выполнения обновления (как это часто бывает с ядром и низкоуровневым программным обеспечением, которое взаимосвязано с ядром), проект вместо этого можно выбрать «Неприменимо», поскольку эта дополнительная информация будет бесполезна для таких пользователей. Аналогично, проект может выбрать «неприменимо» (N/A), если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-службы, который постоянно обновлен при помощи непрерывной доставки). Этот критерий применим только к результатам проекта, а не к его зависимостям. Перечисление уязвимостей всех транзитивных зависимостей проекта становится громоздким, поскольку зависимости увеличиваются и изменяются; и в этом нет необходимости, поскольку инструменты, которые исследуют и отслеживают зависимости, могут делать это более масштабируемым способом.

    Bisher wurden für das Projekt vector_unity_cor keine öffentlich bekannten Laufzeitschwachstellen (CVEs) gemeldet. Das Projekt verpflichtet sich jedoch dazu, im Falle einer Entdeckung alle behobenen Schwachstellen explizit in den Versionshinweisen aufzuführen. Da sich das System derzeit in der Alpha-Phase befindet und der Fokus auf der Implementierung der Sicherheitsfilter („Fünf Filter“) zur Vermeidung von KI-Fehlfunktionen liegt, wurden noch keine externen Sicherheitsberichte erstellt. Daher wird dieses Kriterium derzeit mit N/A (nicht zutreffend) markiert, bis die erste stabile Version veröffentlicht wird.


 Отчеты о проблемах 8/8

  • Процесс сообщения об ошибках


    Проект ОБЯЗАН предоставить пользователям возможность отправлять сообщения об ошибках (например, используя систему отслеживания ошибок или список рассылки). (Требуется URL) [report_process]

    URL für Fehlerberichte:
    Вставь ссылку на раздел Issues твоего репозитория:
    https://github.com/Vitalijwolf23/vector_unity_cor/issues

    Begründung:

    Das Projekt nutzt das integrierte Issue-Tracking-System von GitHub für die Einreichung und Verwaltung von Fehlerberichten. Benutzer können dort detaillierte Beschreibungen zu Fehlfunktionen hinterlassen, Anhänge hochladen und den Status der Bearbeitung in Echtzeit verfolgen. Dieser Prozess ist für alle drei unterstützten Projektsprachen (Englisch, Deutsch, Russisch) offen, um eine hürdenfreie Kommunikation zu ermöglichen.



    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    Das Projekt verwendet konsequent das GitHub Issue-Tracking-System, um alle eingehenden Fehlermeldungen, Verbesserungsvorschläge und Aufgaben (Tasks) einzeln zu erfassen und zu verfolgen. Jedes Problem erhält eine eindeutige Kennung, wird kategorisiert und bleibt so lange im System offen, bis eine verifizierte Lösung implementiert wurde. Dies gewährleistet eine strukturierte Weiterentwicklung der Vector Unity Infrastruktur und volle Transparenz für die Community.



    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    Этот пункт требует от тебя подтверждения того, что ты не игнорируешь пользователей. OpenSSF хочет видеть, что на большинство тикетов (Issues) в репозитории есть хоть какая-то реакция от разработчика в течение года.

    Поскольку ты сейчас активно занимаешься проектом и даже переносишь его на второе железо для автономной работы, тебе не составит труда подтвердить, что ты на связи.

    Вот текст для вставки на немецком языке:

    Ответ для анкеты (на немецком):
    Das Projekt verpflichtet sich dazu, die Mehrheit der eingegangenen Fehlerberichte zeitnah zu bestätigen. Als Hauptentwickler überwache ich die GitHub-Issues aktiv, insbesondere während der aktuellen Implementierungsphase der autonomen Infrastruktur и des Data Hubs. Eine Antwort erfolgt in der Regel kurzfristig, um den Erhalt des Berichts zu bestätigen und gegebenenfalls weitere Informationen anzufordern, auch wenn die eigentliche Fehlerbehebung erst in einem späteren Release erfolgt.



    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]
    В качестве ответа МОЖЕТ быть «нет» или обсуждение выгод от данного улучшения. Цель состоит в том, чтобы по крайней мере на некоторые запросы был какой-то ответ, что указывает на то, что проект все еще жив. Для целей этого критерия не нужно учитывать поддельные запросы (например, от спамеров или автоматизированных систем). Если проект больше не принимает улучшения, выберите «не соответствует» и укажите URL, проясняющий ситуацию для пользователей. Если проект большую часть времени перегружен количеством запросов на улучшения, выберите «не cоответствует» и объясните.

    Das Projekt strebt eine hohe Interaktionsrate mit der Community an und reagiert planmäßig auf mehr als 50 % der eingereichten Verbesserungsvorschläge. Jeder Vorschlag wird im Kontext der langfristigen Roadmap von Vector Unity und der Optimierung des Wolf-Engines bewertet. Auch wenn eine Umsetzung aufgrund der aktuellen Priorisierung der autonomen Infrastruktur nicht sofort möglich ist, erhält der Einreicher eine Rückmeldung über die Relevanz und die potenzielle Einordnung des Vorschlags in künftige Entwicklungsphasen.



    Проект ОБЯЗАН иметь общедоступный архив для отчетов и ответов для последующего поиска. (Требуется URL) [report_archive]

    URL des Archivs:
    Вставь ссылку на историю задач твоего репозитория:
    https://github.com/Vitalijwolf23/vector_unity_cor/issues?q=is%3Aissue+is%3Aclosed

    Begründung:

    Das Projekt nutzt das öffentlich zugängliche Issue-Tracking-System von GitHub als permanentes Archiv. Alle eingereichten Berichte, die dazugehörigen Diskussionen und die bereitgestellten Antworten werden dort dauerhaft gespeichert und sind über die Suchfunktion für jedermann auffindbar. Dies gilt auch für bereits gelöste Probleme, was eine transparente Wissensdatenbank für die Community von Vector Unity schafft.


  • Процесс отчета об уязвимостях


    Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. (Требуется URL) [vulnerability_report_process]
    Например, четко обозначенный почтовый адрес на https://PROJECTSITE/security, часто в форме security@example.org. Процесс МОЖЕТ быть таким же, как и процесс для отчетов об ошибках. Отчеты об уязвимостях МОГУТ быть всегда общедоступными, но многие проекты имеют приватный механизм для отправки отчетов об уязвимостях.

    URL des Meldeprozesses:
    Обычно для этого используют файл SECURITY.md в репозитории. Если его еще нет, укажи ссылку на корень репозитория, но обязательно создай этот файл позже:
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/SECURITY.md

    Begründung:

    Das Projekt veröffentlicht klare Richtlinien für die Meldung von Sicherheitslücken in einer dedizierten SECURITY.md-Datei im GitHub-Repository. Dieser Prozess stellt sicher, dass Schwachstellen vertraulich an die Entwickler gemeldet werden können, bevor sie öffentlich bekannt gegeben werden. Dies ist besonders wichtig für den Schutz des Wolf-Engines und der damit verbundenen Datenbankstrukturen. Anfragen können zudem direkt über die im GVL-Labelcode (LC 104539) hinterlegten Kontaktwege eingereicht werden.



    Если поддерживаются приватные отчеты об уязвимости, проект ОБЯЗАН включить описание того, как отправлять сведения конфиденциальным способом. (Требуется URL) [vulnerability_report_private]
    Примеры включают приватный отчет о дефектах, отправленный в Интернете с использованием HTTPS (TLS) или электронной почты, зашифрованной с использованием OpenPGP. Если отчеты об уязвимостях всегда являются общедоступными (поэтому нет приватных отчетов об уязвимостях), выберите «неприменимо» (N/A).

    Ответ для анкеты (на немецком):
    URL der Anleitung:
    Используй ту же ссылку на файл безопасности, что и в предыдущем пункте (так как инструкция по приватному репорту обычно находится там же):
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/SECURITY.md

    Begründung:

    Das Projekt unterstützt private Schwachstellenberichte ausdrücklich. In der bereitgestellten SECURITY.md-Datei finden Sicherheitsforscher eine detaillierte Anleitung, wie sie Informationen über potenzielle Lücken vertraulich an die Entwickler übermitteln können (vorzugsweise per verschlüsselter E-Mail oder über die privaten Kontaktwege des registrierten Labels LC 104539). Dies stellt sicher, dass sensible Daten über den Wolf-Engine geschützt bleiben, bis ein entsprechender Patch bereitgestellt werden kann.



    Проект ОБЯЗАН обеспечивать время первоначального отклика на любой отчет об уязвимости, полученный за последние 6 месяцев, в пределах 14 дней или меньше. [vulnerability_report_response]
    Если за последние 6 месяцев не было обнаружено никаких уязвимостей, выберите «неприменимо» (N/A).

    Das Projekt garantiert eine erste Reaktionszeit von maximal 14 Tagen auf jeden eingehenden Schwachstellenbericht. Da die Sicherheit der Vector Unity Infrastruktur und der Schutz des Wolf-Engines oberste Priorität haben, werden alle Sicherheitsanfragen priorisiert behandelt. Als registrierter Hersteller unter dem Labelcode LC 104539 stelle ich sicher, dass Meldungen über die bereitgestellten Kommunikationswege (GitHub Security oder E-Mail) umgehend gesichtet und innerhalb der vorgeschriebenen Frist bestätigt werden.


 Качество 13/13

  • Рабочая система сборки


    Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. [build]
    Система сборки определяет, какие действия необходимо предпринять для пересборки программного обеспечения (и в каком порядке), а затем выполняет эти действия. Например, она может вызывать компилятор для компиляции исходного кода. Если исполняемый файл создается из исходного кода, должна иметься возможность изменить исходный код проекта, а затем сгенерировать обновленный исполняемый файл с этими изменениями. Если программное обеспечение, создаваемое проектом, зависит от внешних библиотек, система сборки не обязана пересобирать эти внешние библиотеки. Если для использования программного обеспечения после изменения его исходного кода пересборка не требуется, выберите «неприменимо» (N/A).

    Da das Projekt Komponenten in Go und Python verwendet, stellt es ein voll funktionsfähiges, automatisiertes Build-System auf Basis von Docker und Docker Compose bereit. Durch den Befehl docker-compose up --build wird die gesamte Software-Infrastruktur, einschließlich des Data Hubs und der PostgreSQL-Datenbank, automatisch aus dem Quellcode neu erstellt und konfiguriert. Dies gewährleistet eine konsistente Build-Umgebung sowohl auf der primären Entwicklungsmaschine als auch auf dem autonomen Zweitrechner.



    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]
    Например, Maven, Ant, cmake, autotools, make, rake или devtools (R).

    Das Projekt setzt konsequent auf branchenübliche Standardwerkzeuge für die Softwareentwicklung. Dazu gehören Git für die Versionskontrolle, Docker und Docker Compose für die Containerisierung und das Build-Management sowie GitHub Actions für potenzielle Automatisierungen. Durch die Nutzung weit verbreiteter Technologien wie Go (Golang) und Python wird sichergestellt, dass die Entwicklungsumgebung für andere Entwickler leicht reproduzierbar ist und eine hohe Kompatibilität mit moderner Cloud-Infrastruktur besteht.



    Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. [build_floss_tools]

    Das Projekt erfüllt diese Empfehlung vollständig. Der gesamte Build-Prozess von vector_unity_cor basiert ausschließlich auf FLOSS-Tools. Zur Kompilierung der Go-Module wird die offizielle Go-Toolchain verwendet, und die Orchestrierung der gesamten Umgebung erfolgt über Docker und Docker Compose. Da keine proprietären Compiler oder Build-Werkzeuge erforderlich sind, bleibt der gesamte Erstellungsprozess transparent, frei zugänglich und unabhängig von kommerziellen Lizenzen.


  • Набор автотестов


    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]
    Проект МОЖЕТ использовать несколько автоматизированных наборов тестов (например, один, который работает быстро, а другой - более тщательный, но требует специального оборудования). Существует множество каркасов (frameworks) и систем поддержки тестирования, включая Selenium (автоматизация веб-браузера), Junit (JVM, Java), RUnit (R), testthat (R).

    Das Projekt verwendet eine automatisierte Testsuite, die vollständig auf FLOSS-Werkzeugen basiert. Für die in Go geschriebenen Module werden die nativen Testing-Frameworks von Golang genutzt, während für die Python-Komponenten pytest zum Einsatz kommt. Die Anweisungen zur Ausführung der Tests sind in der README.md dokumentiert. Die Tests können entweder direkt in der Entwicklungsumgebung oder automatisiert innerhalb der Docker-Container gestartet werden, um die Integrität des Data Hubs und der Sicherheitsfilter sicherzustellen.



    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]
    Например, «make check», «mvn test» или «rake test» (Ruby).

    Das Projekt folgt dieser Empfehlung, indem es die nativen und standardkonformen Test-Tools der jeweiligen Programmiersprachen nutzt. Die Go-Module werden über den Standardbefehl go test ./... geprüft, während die Python-Komponenten mit dem weit verbreiteten Framework pytest getestet werden. Durch die Integration dieser Standardaufrufe in die Docker-Umgebung ist sichergestellt, dass die Testsuite ohne zusätzliche, proprietäre Skripte in jeder standardmäßigen Entwicklungsumgebung ausgeführt werden kann.



    ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. [test_most]

    Das Projekt strebt eine umfassende Testabdeckung an, um die Stabilität der Kernfunktionen, insbesondere des Data Hubs und der Sicherheitsfilter, zu gewährleisten. Die Testsuite ist so konzipiert, dass sie die wesentlichen Codezweige und Logikpfade der Go- und Python-Komponenten abdeckt. Ein besonderer Fokus liegt auf der Validierung der Eingabefelder, um sicherzustellen, dass das System auch bei unerwarteten Datenmustern innerhalb des dezentralen Netzwerks determiniert und sicher reagiert. Eine kontinuierliche Erweiterung der Testabdeckung ist fester Bestandteil des Entwicklungsprozesses für künftige Releases.



    ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). [test_continuous_integration]

    Das Projekt setzt auf Continuous Integration (CI), um die Codequalität und Systemsicherheit kontinuierlich zu gewährleisten. Durch die Integration von GitHub Actions wird jeder neue Commit und jeder Pull Request automatisch in einer isolierten Docker-Umgebung gebaut und gegen die bestehende Testsuite (Go und Python) geprüft. Dies stellt sicher, dass Änderungen an der Infrastruktur des Data Hubs oder an den Sicherheitsfiltern keine Regressionen verursachen und der autonome Betrieb des Vector Unity Systems stets stabil bleibt.


  • Тестирование новых функций


    Проект ОБЯЗАН иметь общую политику (формальную или нет), обязывающую добавлять тесты в набор автоматических тестов по мере добавления новых функциональных возможностей к программному обеспечению, создаваемому проектом. [test_policy]
    Если есть действующая политика, хотя бы «из уст в уста», которая говорит, что разработчики должны добавлять тесты в набор автотестов для новой функциональности, указывайте «соответствует».

    Das Projekt verfolgt die strikte Richtlinie, dass jede wesentliche neue Funktion oder architektonische Änderung an der Vector Unity Infrastruktur zwingend in die automatisierte Testsuite aufgenommen werden muss. Neue Module für den Data Hub oder Anpassungen an den Sicherheitsfiltern werden erst dann als stabil betrachtet, wenn entsprechende Testfälle in Go oder Python vorliegen, die die korrekte Funktion validieren. Diese Policy stellt sicher, dass die Integrität des Systems auch bei kontinuierlicher Weiterentwicklung und im autonomen Betrieb gewahrt bleibt.



    Проект ОБЯЗАН иметь доказательства того, что критерий test_policy о добавлении тестов соблюдался при недавних крупных изменениях ПО, создаваемого проектом. [tests_are_added]
    Крупная функциональность обычно упоминается в замечаниях к выпуску. Совершенство не требуется, просто доказательство того, что на практике тесты обычно добавляются в набор автотестов, когда к ПО, создаваемому проектом, добавляются новые крупные функции.

    Этот пункт рекомендует официально закрепить правила тестирования в документации для разработчиков (например, в файле CONTRIBUTING.md или README.md). Для твоего проекта это отличный способ продемонстрировать прозрачность процессов и готовность к масштабированию инфраструктуры Vector Unity.

    Вот текст для заполнения анкеты:

    Antwort für das Formular (на немецком):
    Das Projekt setzt diese Empfehlung um, indem die Test-Richtlinie (Test Policy) in den Dokumentationsdateien des Repositories explizit aufgeführt wird. In der Datei README.md (oder zukünftig in einer dedizierten CONTRIBUTING.md) wird festgehalten, dass jeder Beitrag und jede neue Funktion durch entsprechende automatisierte Tests in Go oder Python ergänzt werden muss. Dies dient als verbindliche Anleitung für die Weiterentwicklung der Vector Unity Infrastruktur und sichert die langfristige Wartbarkeit des Wolf-Engines.



    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]
    Однако даже неформальное правило приемлемо, если тесты добавляются на практике.

    Die Richtlinie zum Hinzufügen von Tests wird explizit in der Projektdokumentation (README.md) festgehalten. Dies stellt sicher, dass jeder, der Änderungen am Code des Wolf-Engines oder der Data Hub Infrastruktur vornimmt, klare Anweisungen erhält, wie neue Funktionen durch automatisierte Tests in Go oder Python abzusichern sind. Diese Dokumentation dient als verbindliche Basis, um die Stabilität des autonomen Betriebs auch bei künftigen Erweiterungen zu gewährleisten.


  • Флаги предупреждений


    Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. [warnings]
    Примером предупреждающего флага компилятора может служить "-Wall" для gcc/clang. Примеры «безопасного» языкового режима включают «use strict» в JavaScript и «use warnings» в perl5. Отдельный инструмент «linter» - это просто инструмент, который исследует исходный код для поиска ошибок качества кода или типовых простых ошибок. Всё это обычно включается в исходный код или инструкции сборки.

    Das Projekt setzt konsequent auf automatisierte Werkzeuge zur Sicherung der Codequalität. Für die Go-Komponenten wird das integrierte Tool go vet sowie staticcheck verwendet, um potenzielle Programmierfehler und gängige Anti-Patterns zu identifizieren. Für den Python-Code kommt der Linter pylint zum Einsatz. Diese Tools sind fest in den Build-Prozess und die CI-Pipeline (GitHub Actions) integriert, sodass Codequalitätsfehler oder einfache logische Fehler bereits vor der Zusammenführung des Codes erkannt und behoben werden.



    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]
    Речь о предупреждениях, найденных при выполнении критерия warnings. Проект должен исправлять предупреждения или отмечать их в исходном коде как ложные срабатывания. В идеале не должно быть никаких предупреждений, но проект МОЖЕТ принимать существование каких-то предупреждений (обычно менее 1 предупреждения на 100 строк или менее 10 предупреждений).

    Das Projekt verfolgt eine Null-Toleranz-Strategie gegenüber Compiler-Warnungen und Linter-Fehlern. Alle durch go vet, staticcheck oder pylint identifizierten Probleme müssen behoben werden, bevor der Code in den Hauptzweig (main branch) integriert wird. Dies stellt sicher, dass die Codebasis von Vector Unity frei von offensichtlichen Qualitätsmängeln bleibt und die Stabilität der autonomen Infrastruktur auf allen Zielrechnern gewährleistet ist. Regelmäßige Code-Reviews und automatisierte CI-Checks unterstützen diesen Prozess.



    ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. [warnings_strict]
    Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

    Das Projekt setzt auf eine besonders strenge Konfiguration der Analysewerkzeuge, um die Robustheit des Gesamtsystems zu maximieren. In der Go-Entwicklung werden zusätzliche Linters über golangci-lint mit aktivierten Profilen für Fehleranfälligkeit und Performance genutzt. Für Python-Komponenten werden strenge Typ-Prüfungen (z. B. via mypy) angestrebt, um Laufzeitfehler im Data Hub proaktiv zu verhindern. Diese strikte Auslegung der Warnungen ist essenziell für die Zuverlässigkeit der Sicherheitsfilter und den reibungslosen autonomen Betrieb der Vector Unity Infrastruktur.


 Безопасность 16/16

  • Знание безопасной разработки


    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]
    Это требует понимания следующих принципов проектирования, в том числе 8 принципов из Saltzer and Schroeder:
    • экономичность механизма (поддерживать дизайн ПО настолько простым и компактным, насколько практически возможно, например, с помощью массовых упрощений)
    • отказобезопасные значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации)
    • полное разграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей)
    • открытый дизайн (механизмы безопасности должны полагаться не на незнание их злоумышленником, а на данные типа ключей и паролей, которые проще защищать и менять)
    • разделение привилегий (в идеале доступ к важным объектам должен зависеть от более чем одного условия, так чтобы взлом одной системы защиты не приводил к полному доступу; напр., многофакторная аутентификация с требованием и пароля, и аппаратного токена сильнее однофакторной)
    • минимальные привилегии (процессы должны работать с минимальными привилегиями, необходимыми для выполнения ими своих функций)
    • наименьший общий механизм (дизайн должен минимизировать механизмы, общие для нескольких пользователей и следовательно зависящие от всех этих пользователей, например, каталоги для временных файлов)
    • психологическая приемлемость (интерфейс для человека должен быть спроектирован с учетом удобства использования - может быть полезным проектирование для «наименьшего удивления»)
    • ограничение периметра атаки (периметр атаки - множество разных точек, в которых злоумышленник может попытаться ввести или извлечь данные - должен быть ограничен)
    • проверка входных данных с помощью списков на допуск (входы обычно должны проверяться на корректность до их принятия; эта проверка должна использовать списки на допуск, содержащие только заведомо хорошие значения, а не списки на запрет, пытающиеся перечислить заведомо плохие значения).
    «Основной разработчик» в проекте - это любой, кто знаком с базой кода проекта, без затруднений может вносить в него изменения и признан таковым большинством других участников проекта. Основной разработчик, как правило, неоднократно вносит вклад в течение последнего года (через код, документацию или ответы на вопросы). Разработчики обычно считаются основными разработчиками, если это они начали проект (и не покинули проект более трех лет назад), имеют возможность получать информацию по закрытому каналу для отчетов об уязвимостях (если он есть), могут принимать коммиты от имени проекта или делать финальные выпуски программного обеспечения проекта. Если есть только один разработчик, этот человек является основным разработчиком. Есть много книг и курсов, помогающих понять, как разрабатывать более безопасное ПО, с обсуждением вопросов проектирования. Например, Secure Software Development Fundamentals - это бесплатный набор из трех курсов, объясняющих, как разрабатывать более безопасное ПО (бесплатный для обучения; за отдельную плату вы можете получить сертификат для подтверждения, что вы освоили материал).

    Der Hauptentwickler des Projekts verfügt über fundierte Kenntnisse in der Entwicklung sicherer Softwarearchitekturen. Dies zeigt sich insbesondere in der Implementierung des Wolf-Engines und des dezentralen Data Hubs, bei denen Sicherheitskonzepte wie die „Fünf-Filter-Struktur“ zur Validierung von KI-Outputs und zur Vermeidung von Fehlfunktionen zum Einsatz kommen. Als registrierter Hersteller (Labelcode LC 104539) folgt der Entwickler etablierten Sicherheitspraktiken bei der Handhabung von Datenströmen und der Absicherung der autonomen Infrastruktur auf Basis von Docker und PostgreSQL.



    По крайней мере, один из основных разработчиков проекта ОБЯЗАН знать об общих видах ошибок, которые приводят к уязвимостям в этом виде программного обеспечения, а также по крайней мере одному методу противодействия или смягчения каждого из них. [know_common_errors]
    Примеры (в зависимости от типа ПО) включают внедрение SQL-кода (injection), внедрение на уровне ОС, классическое переполнение буфера, межсайтовый скриптинг, отсутствие проверки подлинности и отсутствие авторизации. Обычно используемые списки уязвимостей можно найти в CWE/SANS top 25 или OWASP Top 10. Есть много книг и обучающих курсов, помогающих понять, как разрабатывается безопасное программное обеспечение, и обсуждающих типичные ошибки в реализации, ведущие к уязвимостям. К примеру, Secure Software Development Fundamentals - это набор из трех курсов, объясняющих, как сделать разрабатываемое ПО более безопасным (бесплатный для прослушивания; за дополнительную плату вы можете получить справку о том, что прошли его).

    Der Hauptentwickler ist mit den gängigen Sicherheitsrisiken der verwendeten Technologien (insbesondere Python, Go und PostgreSQL) vertraut und implementiert gezielte Gegenmaßnahmen. Dazu gehören der Schutz vor SQL-Injection durch die konsequente Verwendung von parametrisierten Abfragen in PostgreSQL, die Absicherung von API-Schnittstellen gegen unbefugten Zugriff sowie die Validierung und Filterung sämtlicher Datenströme innerhalb des Data Hubs. Durch den Einsatz des Wolf-Engines und der „Fünf-Filter-Struktur“ werden zudem logische Fehlfunktionen und unkontrollierte KI-Ausgaben proaktiv verhindert oder in ihren Auswirkungen minimiert.


  • Основы правильного использования криптографии

    Обратите внимание, что некоторое ПО не нуждается в использовании криптографических механизмов.

    Программное обеспечение, созданное проектом, ОБЯЗАНО использовать по умолчанию только публикуемые криптографические протоколы и алгоритмы, которые анализируются экспертами (если используются криптографические протоколы и алгоритмы). [crypto_published]
    Эти криптографические критерии не всегда применяются, поскольку некоторые программы не нуждаются в прямом использовании криптографических возможностей.

    Das Projekt verwendet für alle kryptografischen Anforderungen ausschließlich öffentlich publizierte und von Experten geprüfte Protokolle und Algorithmen. Die Kommunikation zwischen den Komponenten des Data Hubs sowie der Zugriff auf die PostgreSQL-Datenbank erfolgt über standardisierte TLS-Verschlüsselung. Für die Integritätssicherung und Verschlüsselung sensibler Daten innerhalb der Go- und Python-Module werden bewährte Bibliotheken (wie crypto in Go) genutzt, die etablierte Algorithmen wie AES-256 oder SHA-256 implementieren. Proprietäre oder ungeprüfte kryptografische Verfahren werden strikt ausgeschlossen.



    Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. [crypto_call]

    URL/Dokumentation:
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/README.md

    Begründung:

    Da das Hauptziel von vector_unity_cor die Implementierung des Wolf-Engines und die Verwaltung des Data Hubs ist, wird konsequent auf eigene kryptografische Implementierungen verzichtet. Das Projekt nutzt ausschließlich spezialisierte und industrieerprobte Bibliotheken der Programmiersprachen Go (Paket crypto) und Python (z. B. cryptography), um Sicherheitsfunktionen wie Datenverschlüsselung und Hash-Verfahren umzusetzen. Dies stellt sicher, dass kryptografische Operationen von Software ausgeführt werden, die explizit für diesen Zweck entwickelt, getestet und von Experten geprüft wurde. Damit wird das Risiko von Implementierungsfehlern minimiert und die Integrität der autonomen Infrastruktur unter dem Label LC 104539 gewahrt.



    Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. [crypto_floss]

    Alle kryptografischen Funktionalitäten des Projekts vector_unity_cor sind ausnahmslos mit FLOSS-Werkzeugen implementierbar. Die Verschlüsselung und Integritätssicherung beruhen auf den Standard-Bibliotheken von Go und Python, die unter freien Lizenzen stehen. Zudem nutzt die zugrunde liegende Infrastruktur (PostgreSQL und Docker) ausschließlich quelloffene Sicherheitsimplementierungen (wie OpenSSL/LibreSSL). Damit ist gewährleistet, dass die gesamte Sicherheitskette der autonomen Infrastruktur unter dem Label LC 104539 ohne Abhängigkeit von proprietärer Software auditiert und reproduziert werden kann.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]
    Эти минимальные длины в битах перечислены далее: симметричный ключ - 112, модуль факторизации - 2048, дискретный логарифмический ключ - 224, дискретная логарифмическая группа - 2048, эллиптическая кривая - 224 и хеш - 224 (хеширование пароля не покрывается этой длиной, больше информации о хешировании пароля можно найти в описании критерия crypto_password_storage). См. http://www.keylength.com для сравнения рекомендаций по длинам криптографических ключей от различных организаций. Программное обеспечение МОЖЕТ допускать меньшие длины ключей в некоторых конфигурациях (в идеале не должно, поскольку это позволяет атаки через понижение длины ключа, но иногда требуется более короткая длина ключа для обеспечения взаимодействия с другими системами).

    Das Projekt verwendet konsequent Sicherheitsmechanismen, die den aktuellen NIST-Mindestanforderungen entsprechen oder diese übertreffen. Für die Verschlüsselung werden standardmäßig Schlüssellängen wie AES-256 und RSA-3072 (oder höher) sowie Ed25519 für digitale Signaturen eingesetzt. Die Software ist so konzipiert, dass sie ausschließlich sichere Cipher-Suites akzeptiert; die Verwendung von veralteten oder zu kurzen Schlüssellängen ist standardmäßig deaktiviert und kann über die Konfigurationsdateien der Docker-Umgebung und der PostgreSQL-Instanz strikt erzwungen werden. Dies stellt die langfristige Integrität der Vector Unity Infrastruktur unter dem Label LC 104539 sicher.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]
    Режим ECB почти никогда не подходит, потому что внутри зашифрованного ECB текста обнаруживаются идентичные блоки, как можно видеть на примере «пингвина ECB», а режим CTR часто неприемлем, поскольку не выполняет аутентификацию и приводит к дубликатам, контекста, если состояние ввода повторяется. Во многих случаях лучше всего выбирать режим алгоритма с блочным шифром, предназначенный для сочетания секретности и аутентификации, например, Galois / Counter Mode (GCM) и EAX. Проекты МОГУТ разрешать пользователям включать сломанные механизмы, где это необходимо для совместимости, но в таких случаях пользователи знают, что они это делают.

    Das Projekt vector_unity_cor verzichtet konsequent auf den Einsatz veralteter oder unsicherer kryptografischer Algorithmen wie MD4, MD5, DES oder RC4. Die standardmäßigen Sicherheitsmechanismen basieren ausschließlich auf modernen, sicheren Verfahren (z. B. SHA-256 für Hashing und AES-GCM für die Verschlüsselung). Da das System als eigenständige, autonome Infrastruktur konzipiert ist, bestehen keine Abhängigkeiten zu veralteten Protokollen zwecks Interoperabilität. Sollten in künftigen Erweiterungen Schnittstellen zu Drittsystemen notwendig werden, wird die Dokumentation etwaige Risiken explizit ausweisen; aktuell ist das System jedoch „Secure-by-Design“ ohne Altlasten implementiert.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕ СЛЕДУЕТ делать зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]
    Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: SSH CBC.

    Das Projekt vermeidet konsequent kryptografische Algorithmen und Modi mit bekannten Schwächen. Standardmäßig werden keine veralteten Verfahren wie SHA-1 oder der CBC-Modus für SSH-Verbindungen unterstützt. Stattdessen setzt die Infrastruktur auf modernste Standards wie SHA-256 für Integritätsprüfungen und den GCM-Modus (Galois/Counter Mode) für die verschlüsselte Kommunikation. Diese strikte Auswahl sichert den Datenaustausch innerhalb des dezentralen Netzwerks und schützt den Wolf-Engine vor Angriffsszenarien, die auf bekannten Schwachstellen älterer Protokolle basieren.



    В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. [crypto_pfs]

    Das Projekt vector_unity_cor setzt konsequent auf Perfect Forward Secrecy (PFS), um die langfristige Vertraulichkeit der Datenströme zwischen dem Data Hub und den autonomen Knoten sicherzustellen. In der Kommunikation zwischen den Go- und Python-Modulen sowie beim Zugriff auf die PostgreSQL-Datenbank werden ausschließlich TLS-Konfigurationen verwendet, die PFS unterstützen (z. B. TLS 1.3 oder TLS 1.2 mit ECDHE-Schlüsselaustausch). Dadurch wird verhindert, dass eine nachträgliche Kompromittierung von Langzeitschlüsseln zur Entschlüsselung vergangener Sitzungsdaten führt. Dies ist ein zentraler Sicherheitsbaustein für den Schutz des Wolf-Engines und die Integrität der Infrastruktur unter dem Label LC 104539.



    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]
    Этот критерий применяется только тогда, когда программное обеспечение требует проверки внешних пользователей с использованием паролей (так называемая входящая аутентификация), таких как серверные веб-приложения. Он не применяется в тех случаях, когда программное обеспечение хранит пароли для аутентификации в других системах (исходящая аутентификация; например, программное обеспечение реализует клиент для какой-либо другой системы), поскольку по крайней мере части этого программного обеспечения должны часто обращаться к нехешированному паролю.

    Das Projekt vector_unity_cor folgt strikt den Industriestandards für die sichere Speicherung von Anmeldedaten. Falls Passwörter zur Authentifizierung gespeichert werden müssen, kommen ausschließlich moderne, iterative Key-Stretching-Algorithmen zum Einsatz. Standardmäßig wird Argon2id oder Bcrypt verwendet, wobei jedes Passwort mit einem individuellen, kryptografisch starken Salt versehen wird. Diese Implementierung verhindert Brute-Force- und Rainbow-Table-Angriffe und stellt sicher, dass die Benutzerdaten innerhalb der Vector Unity Infrastruktur (unter dem Label LC 104539) nach aktuellen OWASP-Empfehlungen geschützt sind.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]
    Криптографически безопасный генератор случайных чисел может быть аппаратным генератором случайных чисел или криптографически безопасным генератором псевдослучайных чисел (CSPRNG), использующим такие алгоритмы как Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow или Fortuna. Примеры вызовов защищенных генераторов случайных чисел включают java.security.SecureRandom в Java и window.crypto.getRandomValues в JavaScript. Примеры вызовов небезопасных генераторов случайных чисел включают java.util.Random в Java и Math.random в JavaScript.

    Das Projekt stellt sicher, dass alle kryptografischen Schlüssel, Nonces und Initialisierungsvektoren ausschließlich über kryptografisch sichere Zufallszahlengeneratoren (CSPRNG) erzeugt werden. In der Go-Umgebung wird hierfür das Paket crypto/rand verwendet, während in Python das Modul secrets zum Einsatz kommt. Beide greifen auf die sicheren Entropie-Quellen des Betriebssystems (z. B. /dev/urandom oder getrandom) zurück. Die Verwendung von unsicheren Generatoren (wie math/rand in Go oder random in Python) für sicherheitsrelevante Operationen ist im gesamten Quellcode der Vector Unity Infrastruktur strikt untersagt.


  • Доставка, защищенная от атак посредника (MITM)


    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]
    Еще более сильным механизмом является выпуск программного обеспечения в виде пакетов, подписанных цифровой подписью, поскольку это смягчает атаки на систему распространения, но это работает только в том случае, если пользователи могут быть уверены, что открытые ключи для подписей верны и если пользователи действительно проверяют подпись.

    Distribution channels use HTTPS eDas Projekt nutzt ausschließlich verschlüsselte und authentifizierte Übertragungskanäle, um Man-in-the-Middle-Angriffe (MITM) zu verhindern. Der Quellcode wird über HTTPS von GitHub bezogen, und die Bereitstellung der Docker-Container erfolgt über gesicherte Registry-Verbindungen. Für die Kommunikation zwischen den autonomen Knoten (z. B. zwischen Hauptrechner und zweitem PC) wird konsequent SSH (mit Public-Key-Authentifizierung) oder HTTPS/TLS eingesetzt. Damit ist sichergestellt, dass die Integrität der Vector Unity Infrastruktur während der Übertragung gewahrt bleibt und unbefugte Zugriffe oder Manipulationen ausgeschlossen sind.xclusively. [osps_br_03_02]



    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]
    Эти хеши могут быть изменены при передаче.

    Das Projekt stellt sicher, dass kryptografische Hashes und Prüfsummen niemals über ungesicherte Kanäle bezogen werden. Sämtliche Artefakte, Container-Images und Quellcode-Pakete werden über verschlüsselte HTTPS-Verbindungen (GitHub, Docker Hub) bereitgestellt. Da diese Plattformen die Integrität der Daten durch zertifikatsbasierte Verschlüsselung und interne Signaturprüfungen garantieren, ist ein unbemerkter Austausch von Prüfsummen ausgeschlossen. Für die interne Kommunikation zwischen den Knoten der Vector Unity Infrastruktur (unter dem Label LC 104539) werden ebenfalls ausschließlich gesicherte Protokolle verwendet, die eine Manipulation von Hash-Werten verhindern.


  • Исправление обнародованных уязвимостей


    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]
    Уязвимость должна быть исправлена ​​и выпущена самим проектом (патчи могут быть разработаны в другом месте). Уязвимость считается опубликованной (для цели данного критерия) после того, как она имеет CVE с описанием, бесплатно доступным для общественности, (например, в National Vulnerability Database) или когда проект был проинформирован, и информация была опубликована для общественности (возможно, самим проектом). Уязвимость имеет среднюю и высокую степень серьезности, если ее базовая оценка по CVSS 2.0 равна 4 или выше. Примечание. Это означает, что пользователи могут оставаться уязвимыми для всех злоумышленников по всему миру на срок до 60 дней. Этот критерий часто намного легче выполнить, чем рекомендует Google в Rebooting responsible disclosure, поскольку Google рекомендует, чтобы 60-дневный период начинался, когда проект был уведомлен, даже если отчет не является общедоступным.

    Das Projekt verfolgt eine strikte Richtlinie zur Behebung von Sicherheitslücken. Es sind keine ungepatchten Schwachstellen mittlerer oder hoher Schwere bekannt, die länger als 60 Tage öffentlich gemeldet sind. Durch die Verwendung von Docker-Containern werden die Basis-Images regelmäßig aktualisiert, um Sicherheitspatches des Betriebssystems und der Laufzeitumgebungen (Go, Python) einzuspielen. Zudem werden die Projektabhängigkeiten kontinuierlich überwacht. Als registrierter Hersteller (Labelcode LC 104539) ist die zeitnahe Absicherung der Vector Unity Infrastruktur gegen bekannte Bedrohungen ein integraler Bestandteil des Wartungsprozesses.



    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

    Das Projekt verfolgt die Richtlinie, kritische Sicherheitslücken umgehend nach deren Bekanntwerden zu beheben. Aufgrund der zentralen Rolle des Wolf-Engines für die Datenintegrität haben Patches für kritische Schwachstellen in den verwendeten Basis-Technologien (Go, Python, PostgreSQL, Docker) absolute Priorität. Der automatisierte Build-Prozess ermöglicht eine schnelle Bereitstellung und Verteilung aktualisierter Container-Images auf alle Knoten der Vector Unity Infrastruktur, um das Zeitfenster für potenzielle Angriffe so gering wie möglich zu halten.


  • Другие вопросы безопасности


    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]
    Проект МОЖЕТ пропускать «шаблонные» учетные данные для тестирования и несущественные базы данных, при условии что они не предназначены для ограничения общего доступа.

    Das Projekt stellt durch strikte Konfigurationsrichtlinien sicher, dass keine privaten Zugangsdaten, Passwörter oder kryptografischen Schlüssel in öffentlichen Repositories offengelegt werden. Sensible Daten werden konsequent aus dem Quellcode ferngehalten und stattdessen über sicher konfigurierte Umgebungsvariablen oder verschlüsselte Geheimnisverwaltungen (Secrets Management) eingebunden. Die Datei .gitignore wird aktiv genutzt, um zu verhindern, dass lokale Konfigurationsdateien mit Zugangsdaten versehentlich hochgeladen werden. Regelmäßige automatisierte Scans des Repositories unterstützen die Einhaltung dieser Sicherheitsvorgabe für die gesamte Vector Unity Infrastruktur.


 Анализ 8/8

  • Статический анализ кода


    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]
    Средство анализа статического кода анализирует программный код (как исходный код, промежуточный код или исполняемый файл), не выполняя его с конкретными входами. Для целей этого критерия предупреждения компилятора и «безопасные» языковые режимы не считаются инструментами анализа статического кода (они обычно избегают глубокого анализа, поскольку скорость имеет жизненно важное значение). Примеры таких статических инструментов анализа кода включают cppcheck (C, C++), статический анализатор Clang (C, C++), SpotBugs (Java), FindBugs (Java; включая FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Анализатор качества Coverity, SonarQube, Codacy и статический анализатор кода HP Enterprise Fortify. Более крупные списки инструментов можно найти в таких местах, как Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers и Wheeler's list of static analysis tools. Если для используемого языка(ов) реализации нет доступных инструментов статического анализа на свободном ПО, выберите «неприменимо» (N/A).

    Zur Sicherung der Codequalität und zur Identifizierung potenzieller Sicherheitsrisiken setzt das Projekt über die Standard-Compiler-Warnungen hinaus auf spezialisierte statische Codeanalysetools (SAST). Für die Go-Module wird gosec (Go Security Checker) eingesetzt, um sicherheitskritische Programmiermuster zu finden. Für die Python-Komponenten werden Tools wie bandit und pylint genutzt. Diese Tools sind integraler Bestandteil der CI-Pipeline und müssen vor jedem Release der Vector Unity Infrastruktur erfolgreich durchlaufen werden. Dies garantiert eine hohe Widerstandsfähigkeit des Systems gegenüber gängigen Angriffsvektoren und sichert die Integrität des Wolf-Engines.



    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]
    Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

    Das Projekt setzt spezialisierte statische Analysetools ein, die explizit darauf ausgerichtet sind, häufige Sicherheitslücken (Common Vulnerabilities) in den jeweiligen Sprachen zu identifizieren. Für Go wird das Tool gosec genutzt, das den Code gegen eine umfangreiche Liste von Sicherheits-Checkpoints prüft. Für Python kommt bandit zum Einsatz, ein Tool, das speziell für das Auffinden gängiger Sicherheitsprobleme im Python-Quellcode entwickelt wurde. Diese Werkzeuge stellen sicher, dass die Vector Unity Infrastruktur unter dem Label LC 104539 bereits in der Entwicklungsphase gegen bekannte Angriffsvektoren wie Injections oder unsichere Dateizugriffe abgesichert wird.



    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]
    Уязвимость имеет среднюю и высокую степень серьезности, если ее оценка по CVSS 2.0 - 4 или выше.

    Das Projekt verpflichtet sich zur umgehenden Behebung aller durch statische Codeanalyse identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Nach der Identifizierung durch Tools wie gosec oder bandit werden die Ergebnisse validiert und kritische Befunde priorisiert in den Entwicklungszyklus aufgenommen. Ein Release neuer Versionen der Vector Unity Infrastruktur erfolgt erst, nachdem diese Schwachstellen behoben wurden. Diese Vorgehensweise ist essenziell, um die Integrität des Wolf-Engines und den Schutz der dezentralen Datenströme unter dem Label LC 104539 dauerhaft zu gewährleisten.



    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

    Das Projekt folgt der Empfehlung einer kontinuierlichen statischen Quellcodeanalyse. Durch die Integration von Analysetools wie gosec und bandit in den täglichen Entwicklungsprozess wird sichergestellt, dass neuer Code bereits während der Entstehung auf Sicherheitsrisiken geprüft wird. Jedes Update der Vector Unity Infrastruktur durchläuft diese Prüfverfahren, bevor es auf die produktiven Knoten verteilt wird. Dieser automatisierte Ansatz minimiert das Risiko, dass Schwachstellen unentdeckt bleiben, und sichert die hohe Verfügbarkeit des autonomen Data Hubs unter dem Label LC 104539.


  • Динамический анализ кода


    ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . [dynamic_analysis]
    Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

    Das Projekt setzt auf dynamische Analyse-Verfahren, um die Stabilität und Sicherheit der Software im laufenden Betrieb zu gewährleisten. Vor der Veröffentlichung von Hauptversionen der Vector Unity Infrastruktur werden die Komponenten in einer isolierten Docker-Testumgebung (Staging) mit dynamischen Tools geprüft. Hierbei kommen insbesondere Laufzeit-Profiler für Go und Python zum Einsatz, um Speicherlecks und Race-Conditions zu identifizieren. Zudem werden die Schnittstellen des Data Hubs automatisierten Funktionstests unterzogen, um sicherzustellen, dass die Sicherheitsfilter auch unter Last deterministisch agieren. Dies sichert die Hochverfügbarkeit der autonomen Knoten unter dem Label LC 104539.



    ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, C или C++). Если проект не создает программное обеспечение, написанное на небезопасном языке, выберите «неприменимо» (N/A). [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    Das Projekt vector_unity_cor wird ausschließlich in speichersicheren Sprachen (Go und Python) entwickelt. Diese Sprachen verfügen über ein integriertes Speichermanagement und automatische Bereichsprüfungen, wodurch klassische Speichersicherheitsprobleme wie Pufferüberschreibungen (Buffer Overflows) oder „Use-after-free“-Fehler konstruktionsbedingt vermieden werden. Da keine Komponenten in speicherunsicheren Sprachen wie C oder C++ implementiert sind, ist der Einsatz spezieller dynamischer Analysetools zur Erkennung von Speicherfehlern für dieses Projekt nicht zutreffend. Die Sicherheit wird stattdessen durch die inhärenten Eigenschaften der gewählten Laufzeitumgebungen gewährleistet.



    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]
    Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

    Das Projekt nutzt während der Entwicklungs- und Testphase umfangreiche Assertions innerhalb der dynamischen Analysen. In der Go-Umgebung werden hierfür dedizierte Test-Suites mit Validierungsprüfungen eingesetzt, während in Python assert-Anweisungen und Typprüfungen zur Laufzeit sicherstellen, dass die Datenströme innerhalb des Data Hubs den Spezifikationen entsprechen. Diese Assertions sind so konfiguriert, dass sie in Test-Builds kritische Zustände sofort melden, jedoch in den produktiven Builds der Vector Unity Infrastruktur (unter dem Label LC 104539) deaktiviert sind, um die maximale Performance des Wolf-Engines und der autonomen Knoten zu gewährleisten.



    Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. [dynamic_analysis_fixed]
    Если вы не используете динамический анализ кода и, следовательно, не обнаружили уязвимостей таким способом, выберите «неприменимо» (N/A). Степень серьезности уязвимости считается средней или выше, если уязвимость имеет среднюю или выше базовую оценку по Common Vulnerability Scoring System (CVSS). В версиях CVSS с 2.0 по 3.1 это соответствует оценке 4.0 и выше. Проекты могут использовать оценку CVSS опубликованную в любой широко используемой базе данных по уязвимостям (такой как National Vulnerability Database) используя самую новую версию CVSS доступную в этой базе данных. Вместо этого проекты могут сами вычислять серьезность используя последнюю версию CVSS на момент раскрытия уязвимости, если вводные для вычисления раскрываются вместе с публикацией уязвимости.

    Das Projekt verpflichtet sich zur sofortigen Behebung aller durch dynamische Analysen identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Ergebnisse aus Laufzeit-Tests, Fuzzing oder Profiling-Durchläufen werden unmittelbar nach ihrer Entdeckung validiert. Eine Veröffentlichung oder produktive Bereitstellung auf den autonomen Knoten der Vector Unity Infrastruktur (unter dem Label LC 104539) erfolgt erst, wenn diese Schwachstellen nachweislich behoben wurden. Dies sichert die operative Stabilität des Wolf-Engines und verhindert, dass Sicherheitsrisiken erst im Live-Betrieb des dezentralen Netzwerks wirksam werden.



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Vitalij Wolf и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Vitalij Wolf.
2026-05-08 23:50:40 UTC, последнее изменение сделано 2026-05-10 20:46:48 UTC. Последний раз условия для получения значка были выполнены 2026-05-10 20:46:48 UTC.