Kea

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

Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 98 - passing Вот как вставить его:

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

        

 Основы 15/17 ●

  • Идентификация

    KEA is an open source DHCPv4/DHCPv6 server being developed and maintained by ​Internet Systems Consortium. The objective of this project is to provide a very high-performance, extensible DHCP server engine for use by enterprises and service providers, either as is or with extensions and modifications.

  • Предварительные требования


    Достаточно для значка!

    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

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


    Достаточно для значка!

    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

    Contributor guidelines are here: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md. Coding standards are covered there, including this excerpt: "Placed in the root of the repository are files that formally describe the coding guidelines above as close as possible. They are .clang-format and .uncrustify.cfg used by clang-format and uncrustify respectively. If you want to format code automatically, you will need to have at least one of these tools installed. Since by default, these tools look for the closest style file located in one of the parent directories or, otherwise, in a default location, there are a a couple of helpful scripts i.e. ./tools/clang-format.sh and ./tools/uncrustify.sh to assure you that the Kea-owned file is used. They accept any number of customized parameters that would be passed to the underlying tool followed by any number of files and/or directories. Passing directories will have all non-generated C++ files under it formatted."


  • Надзор за проектом


    Достаточно для значка!

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]

    DCO is included in the Contributing.md document in the top of the tree: https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md?ref_type=heads.


    Не хватает обязательной информации, недостаточно для значка.

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

    Достаточно для значка!

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]

    We do have Code of Conduct. It's a slightly modified Django CoC: https://gitlab.isc.org/isc-projects/kea/-/blob/master/code_of_conduct.md


    Не хватает обязательной информации, недостаточно для значка.

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

    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    There are several users who have admin rights for the gitlab Kea repository. They live in different regions (US, Czechia, Poland, UK). See Senior management tab on https://www.isc.org/team/


    Достаточно для значка!

    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]

    Our bus factor is somewhere around 5. Here's a section about it: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html#bus-factor


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


    Достаточно для значка!

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

    Kea operates on milestones. For the next couple (2-4) months, we have very detailed milestones with specific tasks for each monthly release. We have milestones for major releases (e.g. 2.x). List of milestones: https://gitlab.isc.org/isc-projects/kea/-/milestones


    Достаточно для значка!

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

    We do have Kea Developer's guide that discusses each Kea component, its architecture, major design choices and much more. Although this is generated with oxygen, we have a lot of text there explaining the big picture. https://jenkins.isc.org/job/Kea_doc/doxygen/


    Достаточно для значка!

    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [documentation_security]

    See Section 23: Kea Security: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html


    Достаточно для значка!

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

    We do have Quick Start section in the Kea ARM: https://kea.readthedocs.io/en/kea-1.8.2/arm/quickstart.html


    Достаточно для значка!

    Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. [documentation_current]

    We maintain multiple doc versions, one per release. See https://kea.readthedocs.io/en/kea-1.8.2/index.html (click on version in the lower left corner to switch between doc versions). We have mark tickets that address doc problems or require doc problems with a dedicated label. As of time of writing, there were 201 closed doc tickets, with 68 still open. Up to date list: https://gitlab.isc.org/isc-projects/kea/-/boards/18?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=doc


    Достаточно для значка!

    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]

    We show several badges, including CII: https://gitlab.isc.org/isc-projects/kea


  • Общедоступность и интернационализация


    Достаточно для значка!

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

    Kea is a command-line tool, so in principle is accessibility friendly. Our website and documentation use basic technologies that should be screen reader friendly. We use industry standards (github, gitlab, mailman mailing list) for providing a variety of access methods.


    Достаточно для значка!

    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]

    Kea software uses .mes files that list all possible messages Kea can print. Those files can be translated, including the descriptive paragraphs for each message. However, due to massive complexity of the software, so far we are not aware of any translation attempts. Details here: https://kea.readthedocs.io/en/kea-1.8.2/kea-messages.html


  • Другое


    Достаточно для значка!

    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]

    We use github and gitlab.


  • Предыдущие версии


    Достаточно для значка!

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

    We do have 3 stable branches. As of time writing, this was stable 1.6, stable 1.8 and development 1.9. All versions are available as sources on our FTP site (http://ftp.isc.org/isc/kea/) and native packages (cloudsmith.io/~isc/repos/). The general upgrade procedure is well documented in the Kea ARM, especially the kea-admin tool section that involves database upgrades (https://kea.readthedocs.io/en/kea-1.8.2/arm/admin.html). We recently started adding section in the release notes to warn about potential pitfalls and incompatible changes (https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.4#incompatible-changes). Our changelog lists incompatible changes with an asterisk. For ancient (pre 1.6 versions), we do have a migration document: https://gitlab.isc.org/isc-projects/kea/-/wikis/migrating-to-kea-1.6


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


    Достаточно для значка!

    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    https://gitlab.isc.org/isc-projects/kea/-/issues


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


    Достаточно для значка!

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

    Kea enjoys very thorough, massive testing process (6000 unit-tests, 1500 system tests) and multiple automated tools (coverity scan, cppcheck, valgrind, thread sanitizer, shellcheck, danger, etc), fuzzing (afl) and stability tests (perfdhcp). We haven't had a security incident in well over a year.


    Достаточно для значка!

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

    We do have it: https://kb.isc.org/docs/aa-00861 and https://www.isc.org/reportbug/. Also, our gitlab has a note how to report vulnerability reports, see the bug template: https://gitlab.isc.org/isc-projects/kea/-/blob/master/.gitlab/issue_templates/bug_report.md We do have similar note for github.


  • Стандарты кодирования


    Достаточно для значка!

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

    Sure we do. I can't imagine having a large project without coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines


    Недостаточно для значка.

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

    We don't enforce it yet, because of large amounts of legacy code and lots of merge requests being constantly in progress.


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


    Достаточно для значка!

    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]

    We're using autotools (autoconf, automake and friends) and do our best to play by the rules. Details here: https://kea.readthedocs.io/en/kea-1.8.2/arm/install.html#configure-before-the-build


    Достаточно для значка!

    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]

    We try to provide flexible environment. The user can specify whatever debugging options for g++ he/she wishes. We also have --enable-debug that conveniently enables -O0 -g and couple other things. It's by no means mandatory and user can specify or tweak flags as desired.


    Не хватает обязательной информации, недостаточно для значка.

    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]

    Достаточно для значка!

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

    running make distcheck is part of our build process and it's verified after each commit that's merged on master.


  • Система установки


    Достаточно для значка!

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

    User who like to compile can do the usual make install, make uninstall. We also provide native (DEB, RPM, APK) packages for many distros that make the installation and removal easy. The nature of this project (DHCP server) implies that some manual configuration is necessary.


    Достаточно для значка!

    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    Yes, we're using normal autoconf/automake regime. --prefix and more detailed switches (--bindir, --sbindir, --libexecdir, --runstatedir and more) are available.


    Достаточно для значка!

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

    We do have a Developer's guide that explains how to set up the test environment to run unit-tests. Also have a dedicated tool named hammer that can automate installing Kea on bare metal or spin up VMs with requested mandatory and optional dependencies. For details, see https://gitlab.isc.org/isc-projects/kea/-/blob/master/hammer.py.


  • Компоненты, поддерживаемые извне


    Достаточно для значка!

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

    Kea can be compiled using GNU autotools (with using automated configure script) or installed using native (DEB, RPM or APK) packages. The autotools automatically detect presence or absence of external dependencies. The packages have listed external dependencies, so they're installed automatically. Details in the package scripts: https://gitlab.isc.org/isc-projects/kea-packaging


    Не хватает обязательной информации, недостаточно для значка.

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

    Достаточно для значка!

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

    Kea has a -W option that lists external dependencies used during compilation, including their versions. The configure script (typical GNU autotools) provide an option to use alternative components (such as patched dependency in non-standard location). The dependencies are well documented in the Kea ARM document (see https://kea.readthedocs.io/en/kea-1.8.2/arm/intro.html#required-software-at-run-time).


    Достаточно для значка!

    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    We try to not use deprecated or obsolete functions and APIs. When possible, we print out a warning that a dependency (e.g. openssl) is too old and we disable TLS support in Kea. For some cases, e.g. CentOS 7, which still is popular, we attempt to provide alternatives, e.g. you need to install newer openssl. all the technology stack is open source (mostly gcc, but also flex, bison, and other smaller open source tools).


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


    Достаточно для значка!

    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]

    We do have a massive (6000+ unit-tests, 1500 system tests) test farm. It is run after each check-in.


    Достаточно для значка!

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

    We try to live by the TDD (test driven development) philosophy. Except some rare corner cases, each fix or new functionality has new unit tests. For non-trivial features or bugfixes system tests are frequently developed by an independent QA. Often the system tests are ready before the functionality is ready.


    Достаточно для значка!

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]

    We have developed a generic DHCP/DNS testing suite called ISC Forge. It's published under ISC license. See https://github.com/isc-projects/forge


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


    Достаточно для значка!

    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    Yes, it's part of out coding guidelines: https://gitlab.isc.org/isc-projects/kea/-/wikis/Processes/coding-guidelines and https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md


    Достаточно для значка!

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

    https://gitlab.isc.org/isc-projects/kea/-/blob/master/CONTRIBUTING.md


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


    Достаточно для значка!

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

    By default, our configure script enables the following extra switches in g++: -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Wno-missing-field-initializers -fPIC. Note the -Wall and -Wextra. Many of our builds are run with -Werror. We do experiments with -Wpedantic sometimes, but we're not fully committed to that idea yet.


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


    Не хватает обязательной информации, недостаточно для значка.

    Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. [implement_secure_design]

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

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

    Достаточно для значка!

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

    We use security for TSIG, but there is no default algorithm, it must be positively specified.


    Достаточно для значка!

    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    We support HMAC-MD5 (for backward compatibility), HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512 in our TSIG implementation.


    Не хватает обязательной информации, недостаточно для значка.

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

    Достаточно для значка!

    В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    As of April 2021, we have implemented TLS support in Kea.


    Достаточно для значка!

    Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    We support TLS 1.3. Details: https://kea.readthedocs.io/en/kea-1.9.7/arm/security.html#tls-https-support


    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]

    Достаточно для значка!

    В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_verification_private]

  • Безопасный выпуск


    Достаточно для значка!

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

    All releases are signed and each release notes document has a note about how to check them. See example here: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.5#download and a general instructions how to check the signatures: https://www.isc.org/pgpkey/


    Достаточно для значка!

    ЖЕЛАТЕЛЬНО, чтобы в системе контроля версий каждый важный тег версии (тег, который является частью основного выпуска, минорной версии или исправляет общедоступные уязвимости) подписывался криптографической подписью и поддавался проверке, как описано в критерииsigned_releases. [version_tags_signed]

    We use the standard capabilities of GITLAB. See details here: https://gitlab.isc.org/isc-projects/kea/-/releases


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


    Достаточно для значка!

    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]

    DHCP often being the first packets exchanged with an unknown new device entering the network, we pay strict attention to data sanitization, including truncated, malformed, oversized fields, options and packets etc. The requests received over Kea management API undergo sanity checks before they're processed. We have substantial amount of system and unit tests that check for broken input. We also do fuzz testing for incoming packets and configuration files.


    Не хватает обязательной информации, недостаточно для значка.

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

    Не хватает обязательной информации, недостаточно для значка.

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]

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


    Достаточно для значка!

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

    Coverity Scan, cppcheck, danger, clang static analyzer, shellcheck


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


    Достаточно для значка!

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

    We run valgrind tests under Jenkins, use cppcheck, and thread sanitizer from clang.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Vicky Risk and the OpenSSF Best Practices badge contributors.

Владелец анкеты на значок проекта: Vicky Risk.
2016-05-03 15:46:35 UTC, последнее изменение сделано 2025-02-06 12:43:24 UTC. Последний раз условия для получения значка были выполнены 2021-03-22 15:34:49 UTC.

Назад