Kedro

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

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

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.

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

Уровень значка для проекта 6711 - passing

Вот как вставить его:

Вы можете показать свой статус значка, вставив его в файл с разметкой Markdown:

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/6711/badge)](https://www.bestpractices.dev/projects/6711)

- или HTML:
<a href="https://www.bestpractices.dev/projects/6711"><img src="https://www.bestpractices.dev/projects/6711/badge"></a>

Это критерии уровня

. Вы также можете просмотреть критерии уровня

или

Основы 2/5 ●

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

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

Каково краткое описание проекта?

Kedro is an open-source Python framework for creating reproducible, maintainable and modular data science code. It borrows concepts from software engineering and applies them to machine-learning code; applied concepts include modularity, separation of concerns and versioning.

Какой URL у проекта (целиком)?
https://kedro.org

Какой URL у хранилища с управлением версиями (он может быть таким же, как URL проекта)?
https://github.com/kedro-org/kedro
Предварительные требования

Criterion [achieve_silver]
Соответствует

Не соответствует

Проект ОБЯЗАН получить серебряный значок. ^{[achieve_silver]}
Надзор за проектом
Criterion [bus_factor]
Соответствует

Не соответствует

?

Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. (Требуется URL) ^[bus_factor]
«Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.
output of Truck-Factor is TF=6
```
TF = 6 (coverage = 49.67%)
TF authors (Developer;Files;Percentage):
tsanikgr;121;19.90
Jo Stichbury;120;19.74
Lorena Balan;77;12.66
Merel Theisen;62;10.20
Dmitrii Deriabin;35;5.76
Lim H;30;4.93
```
https://github.com/kedro-org/kedro/issues/3597#issuecomment-2497086034
Criterion [contributors_unassociated]
Соответствует

Не соответствует

?

Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) ^{[contributors_unassociated]}
Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.
- Yolan Honoré-Rougé contributed kedro-mlflow, kedro-boot, and many other extensions, see https://github.com/Galileo-Galilei/kedro-mlflow
- Marcin Zabłocki contributed to kedro-azureml and many other extensions, see https://github.com/getindata/kedro-azureml
- Simon Brugman contributed to kedro-airflow, see https://github.com/kedro-org/kedro-plugins/tree/main/kedro-airflow
- Deepyaman Datta contributed to kedro and kedro-datasets, see https://github.com/kedro-org/kedro-plugins/tree/main/kedro-datasets
Другое

Criterion [copyright_per_file]
Соответствует

Не соответствует

?

Проект ОБЯЗАН включать заявление об авторских правах в каждом исходном файле, указывая по крайней мере один соответствующий год и одного обладателя авторских прав. ^{[copyright_per_file]}
Это МОЖНО сделать, включив следующее в комментарий рядом с началом каждого файла: «Copyright [год создания этого проекта или контента] - [последний год изменений], [основатель проекта] and the [название проекта] contributors.»

Copyright statement is not yet included in every source file.

Criterion [license_per_file]
Соответствует

Не соответствует

?

Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. ^{[license_per_file]}
Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

License statement is not yet included in every source file.

Анализ 2/2 ●

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

Criterion [dynamic_analysis]
Соответствует

Не соответствует

Неприменимо

?

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

The software uses MyPy, bandit, and other dynamic analysis tools that run on its Continuous Integration

Criterion [dynamic_analysis_enable_assertions]
Соответствует

Не соответствует

Неприменимо

?

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

Assertions are included (albeit sparingly, given that they can be disabled in certain modes of execution, e.g. python -O)

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 Yetunde Dada and the OpenSSF Best Practices badge contributors.

Владелец анкеты на значок проекта: Yetunde Dada.
2022-11-17 11:48:49 UTC, последнее изменение сделано 2024-11-25 07:34:04 UTC. Последний раз условия для получения значка были выполнены 2022-11-17 12:46:29 UTC.

Kedro

Основы 2/5 ●

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

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

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

Другое

Управление изменениями 2/4 ●

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

Качество 7/7 ●

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

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

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

Безопасность 3/5 ●

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

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

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

Анализ 2/2 ●

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