Astetik

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

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

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


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

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

        

 Основы 14/17 ●

  • Общая

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

    Astetik compiles scientific figures, numerical output, and verifiable provenance from declared plot specifications and a centralized design manifest.

    Используйте формат выражения лицензии 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) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

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


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

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

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


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

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

    CONTRIBUTING links canonical constitution and developer setup; the constitution defines acceptable code, testing, documentation and gate requirements. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CONTRIBUTING.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CLAUDE.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/CONTRIBUTING.md


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


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

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

    GitHub Terms of Service D.6 licenses content contributed to a licensed repository under that license and requires contributors to have the right to do so. PR81 CONTRIBUTING identifies this existing legal mechanism and requires equivalent explicit rights assertions for nontrivial contributions received outside GitHub. Do not claim historical signed DCOs. Keep the explicit project policy pending until adopted. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CONTRIBUTING.md https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/CONTRIBUTING.md


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

    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]
    Требуется устоявшийся задокументированный способ принятия решений и разрешения споров. В небольших проектах это может быть просто вплоть до «владелец и лидер проекта принимает все окончательные решения». Существуют различные модели управления, включая благосклонное диктаторство и формальную меритократию; более подробно см. Governance models. В проектах успешно используются как централизованные подходы (например, с одним ведущим), так и децентрализованные (например, с групповыми ведущими). Не нужно указывать в сведениях об управлении возможность форка проекта, поскольку это всегда возможно для проектов СПО.

    GOVERNANCE and CLAUDE define maintainer decision authority, contribution acceptance, protected checks, independent review and change procedures. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/GOVERNANCE.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CLAUDE.md


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

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    Standard root CODE_OF_CONDUCT.md defines behavior, proportionate enforcement and private maintainer reporting. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CODE_OF_CONDUCT.md


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

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

    MAINTAINERS names Mikko Kotila and assigns scope, issue, security, release and merge responsibilities. It identifies mikkokotila and EnergyGuy3 as administrator/code owners. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/MAINTAINERS.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/GOVERNANCE.md


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

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

    On 2026-10-02 the user explicitly confirmed EnergyGuy3 can recover Astetik release/PyPI access within one week. Independently audited GitHub permissions show mikkokotila and EnergyGuy3 are administrators. These establish attested operational continuity, separately from a recovery drill or proof of equal technical expertise. PR81 publishes the dated path. Evidence: https://api.github.com/repos/autonomio/astetik/collaborators https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/MAINTAINERS.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SETUP.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/MAINTAINERS.md


    Едва достаточно для значка.

    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    Deep compiler knowledge is currently concentrated in the primary maintainer; administrator rights and a backup capable of restoring access do not demonstrate two project experts. The present small maintainer team uses published source, canonical developer documentation, retained regression evidence and a named operational continuation path to reduce interruption. This justified unmet SHOULD transparently preserves that actual staffing boundary. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/MAINTAINERS.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/MAINTAINERS.md


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


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

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

    PR81 adds a dated roadmap covering 2026-10-02 through 2027-10-02, with researcher-focused priorities and explicit exclusions. It is publicly reviewable but is not yet adopted on the protected branch. Change to Met only after adoption. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Overview/Boundary.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/docs/Overview/Roadmap.md


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

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

    The package page defines the compiler responsibility, component ownership, canonical public flow and dependencies. Boundary and evidence/specification references describe their relationships. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/README.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Overview/Boundary.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Evidence-Result.md


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

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

    SECURITY and assurance case identify local library security boundaries, supported source, integrity versus authenticity, dependencies and unproven release/host claims. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SECURITY.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Developer/Security-Assurance-Case.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Evidence-Result.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/SECURITY.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/docs/Developer/Security-Assurance-Case.md


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

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

    The First Figure guide and bundled executable example are exercised by documentation tests; source and installed workflows provide first render, verification, write and replay. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Guides/First-Figure.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/docs/first_figure.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/tests/test_documentation.py


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

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

    Documentation freshness, canonical ownership, links, routes and executable examples are routinely audited. The actual master documentation job passed. Historical usage is separated in Migration. Evidence: https://github.com/autonomio/astetik/actions/runs/36969583737 https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Developer/Documentation-System.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Migration.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/governance/tests/test_installed_documentation.py


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

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

    Astetik achieved the actual OpenSSF Best Practices Passing badge on 2026-10-02 at 09:07:57.546Z. PR81 README links the live project 15154 badge and project page, but its protected-branch adoption is still pending. The repository front page must identify and hyperlink achievements within 48 hours of recognition; keep this criterion pending until the reviewed badge link is adopted. Evidence: https://www.bestpractices.dev/projects/15154.json https://www.bestpractices.dev/projects/15154/badge https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/README.md


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


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

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    Master documentation browser/accessibility job passed. Product figures provide readable table/caption/evidence companions and semantic labels; manifests enforce practical contrast. This is bounded evidence, not universal WCAG certification. Evidence: https://github.com/autonomio/astetik/actions/runs/36969583737 https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Guides/Paper-Figure.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Manifest.md https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs-site/tests/docs.spec.js https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_colors.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs-site/tests/surfaces.spec.js https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/tests/test_design.py


    Едва достаточно для значка.

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

    The current scientific Python and agent audience receives stable machine-readable error codes, while researchers control their own Unicode labels. Human diagnostics and project documentation remain English and there is no locale/message catalogue. Full message localization is explicitly deferred from the one-year scope so effort can improve scientific validation, paper output and provenance. This is a justified unmet SHOULD, not a claim that Unicode alone supplies localization. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/astetik/_errors.py https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/CLI.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/docs/Overview/Roadmap.md https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/docs/Reference/CLI.md


  • Другое


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

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

    Astetik has no owned authentication service storing external-user passwords. Repository and publication accounts belong to GitHub/PyPI rather than a project password database. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SECURITY.md


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

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


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

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

    Migration describes retained argument mappings, breaking behavior, explicit preparation, result/export changes and preserving historical environments. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Migration.md


 Отчеты о проблемах 2/3 ●

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


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

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

    Live GitHub repository metadata has has_issues=true; issues are the documented bug and contribution tracker. Evidence: https://api.github.com/repos/autonomio/astetik https://github.com/autonomio/astetik/issues https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SUPPORT.md


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


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

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

    On 2026-10-02 the user confirmed there were no private vulnerability reports in the preceding 12 months. The repository security advisory API returned an empty list. There are therefore no resolved reported vulnerabilities in that period requiring reporter credit. The public advisory result alone would not establish the private history; this answer relies explicitly on the human confirmation. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SECURITY.md https://api.github.com/repos/autonomio/astetik/security-advisories https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/SECURITY.md


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

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

    PR81 SECURITY documents intake, acknowledgment within 14 calendar days, scope and severity triage, immediate priority for critical reports, repair of known medium-or-higher vulnerabilities within 60 calendar days, regression protection and coordinated disclosure/credit. This is a prospective response policy awaiting protected-branch adoption and does not demonstrate historical response performance. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/SECURITY.md https://github.com/autonomio/astetik/security/advisories/new https://github.com/autonomio/astetik/blob/a296fbd7a09e55ca9f002caa4b6499defc74b638/SECURITY.md


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

 Безопасность 11/13 ●

 Анализ 2/2 ●

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


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

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

    Actual merged-master Python CodeQL run succeeded; its queries analyze security weakness classes. Required PR CodeQL is independently configured with no retained new findings. Evidence: https://github.com/autonomio/astetik/actions/runs/36969583672 https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/.github/workflows/pr_checks_codeql.yml https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CLAUDE.md


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


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

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

    This project owns Python/JavaScript source and does not produce memory-unsafe C/C++ modules. Third-party native scientific dependencies are separately maintained; no project-native sanitizer/fuzzer claim follows. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/pyproject.toml https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Developer/Security-Assurance-Case.md



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/15154/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Mikko Kotila и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Mikko Kotila.
2026-10-02 06:55:56 UTC, последнее изменение сделано 2026-10-02 09:51:47 UTC. Последний раз условия для получения значка были выполнены 2026-10-02 09:07:57 UTC.