BIND 9

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

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

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

        

 Основы 13/13 ●

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

    BIND is open source software that implements the Domain Name System (DNS) protocols for the Internet.

    Какие языки программирования используются для реализации проекта?

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


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

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

    https://www.isc.org/downloads/bind/


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

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

    We have an issue tracker integrated with our primary repo. https://gitlab.isc.org/isc-projects/bind9/issues


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

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

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


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

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

    We have published coding standards. https://gitlab.isc.org/isc-projects/bind9/blob/master/doc/dev/dev.md


  • Свободная лицензия

    Под какой/какими лицензией/ями выпускается проект?


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

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

    The main license agreement for BIND was the ISC license. Recently we announced we were changing to the MPL 2.0 license with version 9.11.0 and later versions. We do have a number of contributions covered by other FLOSS licenses (mostly Apache). The MPL-2.0 license is approved by the Open Source Initiative (OSI).


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

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

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


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

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

    https://gitlab.isc.org/isc-projects/bind9/blob/master/LICENSE https://www.isc.org/downloads/software-support-policy/isc-license/ License(s) are also in the source code in the file LICENSE.


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


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

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

    https://bind9.readthedocs.io/en/stable/ The Administrators Reference Manual (ARM) is published on ReadtheDocs, and the source is included with the source code wherever that is published. We publish additional supplemental material at kb.isc.org, under Software Products, BIND.


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

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

    https://bind9.readthedocs.io/en/stable/ BIND implements many IETF standards for DNS. These documents are also an important aspect of the interface documentation.


  • Другое


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

    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]

    Given only https: URLs.


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

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

    https://lists.isc.org/pipermail/bind-users/ BIND-users is quite an active user mailing list focused on advice for operating BIND. We also have a list for developers, BIND-workers, that is much less active, which is focused on topics of interest to OS packagers and BIND developers. https://gitlab.isc.org/isc-projects/bind9/issues We use the gitlab issue tracker for specific technical discussions related to changes or change requrests.


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

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

    https://bind9.readthedocs.io/en/stable/ Everything is in English.


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

    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]


(Дополнительно) Какие другие пользователи имеют дополнительные права на редактирование этой записи значка? В настоящее время: [2337]



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


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

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

    https://gitlab.isc.org/isc-projects/bind9 and at https://github.com/isc-projects/bind9.


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

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

    We use git, which tracks changes. We record changes in a changes log which is included in the source distribution.


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

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

    We have both a development branch and stable branches, and publish regular maintenance releases on both. Users can also download and build interim releases from our repos.


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

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

    We use a privately hosted instance of the open source Gitlab.


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


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

    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]

    https://www.isc.org/downloads/software-support-policy/version-numbering/


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

    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]

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

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

    We use git tags.


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


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

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

    Release notes are posted alongside every major and minor release, on our ftp server and the web site, and also are included in the ReadTheDocs documentation site for BIND. example: https://bind9.readthedocs.io/en/stable/notes.html#notes-for-bind-9-18-13


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

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

    Met. In addition, we have several other sources for vulnerability documentation. We publish all vulnerability notices on our web site and https://www.isc.org/downloads/software-support-policy/security-advisory/. We publish a matrix showing which vulnerabilities apply to which versions here: https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html


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


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

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

    Anyone can create an issue to report a bug in our public issue-tracker: https://gitlab.isc.org/isc-projects/bind9 As the issue is updated, updates are automatically emailed to the reporter and/or the reporter can reply back to a message from the issue tracker to add more information or request an update.


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

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

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


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

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

    The bounceback message is of course immediate and provides a way for the reporter to followup or add more information to the original report. We do triage new bug reports rapidly, normally within a few days. We respond back to the bug reports that are triaged as critical or severe (Severity=0 or Severity=1 on a 3 point system) within a few days, and often fix them within a few days.
    Bug reports that are triaged as normal (Severity = 2 or Severity = 3) or low are not always responded to. We get a large volume of requests for configuration assistance and spam, also emailed to our bug tracker. Bug reports to security-officer@isc.org are reviewed immediately on a 7x 24 basis and are responded to within a few hours at most.


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

    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]

    https://gitlab.isc.org is our current bug tracker, and it is open to the public


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

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

    https://gitlab.isc.org is our current bug tracker, and it is open to the public


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


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

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

    We have a fairly well-evolved system for handling vulnerability reports. We ask that anyone reporting a bug that they think could be a security vulnerability not discuss that on an open mailing list, and instead contact us directly at bind-security@isc.org. This will create a confidential issue in our bug tracker. One of the core maintainers is assigned each week to triage incoming new issues, so we will spot this and analyze it promptly. https://www.isc.org/downloads/software-support-policy/security-advisory/


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

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

    https://www.isc.org/downloads/software-support-policy/security-advisory/ We normally ask for pgp-encrypted email to security-officer@isc.org, and recently we have added bind-security@isc.org, which will open a confidential issue in our otherwise public Gitlab repo.


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

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

    We monitor gitlab.isc.org 7x 24.


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


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

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

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

    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]

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

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

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


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

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

    There are hundreds of (atf) automated tests included in the source code.


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

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

    https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev/dev.md#testing Our tests can be executed using "make check".


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

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

    We certainly strive for this. Our code coverage, in particular, is not as good as we would like, but we do run code coverage reports internally and look at them and we are aware of the gaps.


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

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

    We use continuous integration running in our Gitlab instance. https://gitlab.isc.org/isc-projects/bind9/-/pipelines


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


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

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

    https://gitlab.isc.org/isc-projects/bind9/-/tree/main#contrib


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

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

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

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

    https://gitlab.isc.org/isc-projects/bind9/-/tree/main#contrib


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


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

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

    yes, especially when we compile with —enable-developer


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

    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]

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

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

    ISC use -Wall -Werror during the development.

    On Mac OS X, "-Wno-deprecated-declarations" is needed though.


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


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

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

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

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

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

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

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

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

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

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

    We rely on OpenSSL for cryptography.


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

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

    We rely on OpenSSL for cryptography.


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

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

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

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

    Sorry, it is not obvious how to apply this to BIND. "met" if we're thinking of tsig-keygen or dnssec-keygen... "not met" if we're thinking of rndc-confgen.


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

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

    Sorry, it is not obvious how to apply this to BIND. " "met" if we're thinking of tsig-keygen or dnssec-keygen... "not met" if we're thinking of rndc-confgen.


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

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

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

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

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

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

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


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

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

    We sign our tar balls with public keys. No idea if most users check the signatures, but occasionally we get questions about it, so we know that some do.


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

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

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


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

    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]

    We normally provide a patch at the time we publish the vulnerability notice. Obviously this is not possible in the case of a vulnerability that we first hear of when it is published.
    Note that we consider a vulnerability to be significant enough to require a patch if the CVSS score is 5 or above. Our vulnerability disclosure process is described here: https://kb.isc.org/article/AA-00861/0


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

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

    We have a long history of doing this.


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


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

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

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


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

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

    we use the Coverity analyzer as frequently as possible. we also use other tools such as Clang. People test new analyzers on BIND.


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

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

    https://scan.coverity.com/projects/15


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

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

    https://scan.coverity.com/projects/15


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

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

    we do static analysis continuously on our internal build system


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


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

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

    we have implemented AFL fuzzing


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

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

    we use valgrind we also use the APL fuzzer


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

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

    It is often suggested that we have TOO MANY run-time asssertions....


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

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

    https://www.isc.org/blogs/days-disclosure-bind9-cves/



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-08-15 17:41:15 UTC, последнее изменение сделано 2025-02-12 17:43:44 UTC. Значок последний раз потерян 2023-07-11 15:31:20 UTC. Последний раз условия для получения значка были выполнены 2023-07-11 15:34:03 UTC.

Назад