evidentia

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

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

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


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

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

        

 Основы 17/17 ●

  • Общая

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

    Open-source Python GRC tool: gap analysis, AI risk statements, OSCAL-first compliance automation. Enterprise-grade evidence integrity (Sigstore + GPG), CycloneDX SBOM, PyPI Trusted Publisher OIDC + PEP 740 attestations.

    Используйте формат выражения лицензии 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]

    https://github.com/allenfbyrd/evidentia/blob/main/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 для проекта меньше, чем их преимущества.

    Single-maintainer project. All commits to date are authored by the project owner (Allen Byrd) under copyright explicitly granted to the project under Apache-2.0. A formal DCO/CLA flow will be adopted at the point a second contributor is onboarded; for now, the legal-authority chain is degenerate (one author = one signer). Apache-2.0 LICENSE: https://github.com/allenfbyrd/evidentia/blob/main/LICENSE.


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

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

    Project governance is documented in GOVERNANCE.md: https://github.com/allenfbyrd/evidentia/blob/main/GOVERNANCE.md. Current model: BDFL (benevolent dictator for life) — Allen Byrd holds final decision authority. Roadmap is published in docs/ROADMAP.md and per-release plans (docs/v0.7.x-plan.md). Decisions on technical direction, scope, and breaking changes are made openly via GitHub Issues and PR discussion.


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

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется 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.

    Contributor Covenant v2.1 adopted at https://github.com/allenfbyrd/evidentia/blob/main/CODE_OF_CONDUCT.md. Reporting channel and enforcement guidelines documented inline.


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

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

    Roles and responsibilities documented in GOVERNANCE.md: https://github.com/allenfbyrd/evidentia/blob/main/GOVERNANCE.md. Current roles: Maintainer (Allen Byrd) — owns all merge authority, release authority, and security disclosure handling. As collaborators join, a "Triager" role (issue triage, PR review) and "Catalog Curator" role (Tier-A/B/C catalog updates) will be defined explicitly.


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

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

    Concrete continuity plan documented at https://github.com/allenfbyrd/evidentia/blob/main/docs/access-continuity.md. Key elements:

    • Operational SLA: project commits to resuming normal operations (create + close issues, accept proposed changes, release versions) within 7 calendar days of confirmation of loss of support.
    • Keyless signing infrastructure (Sigstore PEP 740 + Trusted Publisher OIDC + cosign keyless) means no offline private keys exist that could be lost with the maintainer. Any successor with repo write access can continue releases without any key transfer.
    • Step-by-step recovery procedure (Step 1 confirm loss; Step 2 GitHub repo + organization access via account-recovery OR fork-and-redirect fallback; Step 3 PyPI project-owner-role transfer; Step 4 GHCR access; Step 5 DNS / domain registrar — none currently held; Step 6 first release post-transfer).
    • Named successor + emergency contact maintained in the maintainer's encrypted password manager + emergency-access designation + will / estate documents. Public disclosure of the successor identity is intentionally avoided per the doc's privacy rationale (avoids social-engineering attempts to claim the project; preserves the maintainer's flexibility to update the designation as relationships change). The OpenSSF criterion text doesn't require public disclosure of the successor identity — it requires that the project MUST be able to continue, which the public doc + the private-side designation jointly accomplish. Auditors can verify the private-side designation exists by direct contact with the maintainer (see SECURITY.md disclosure channel).
    • Plan reviewed at every release per release-checklist.md Step 5 + on a quarterly cadence regardless of release activity.

    Companion governance framing at https://github.com/allenfbyrd/evidentia/blob/main/GOVERNANCE.md §"Continuity and bus factor".


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

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

    Current bus factor is 1 (single maintainer - Allen Byrd). Mitigation: keyless signing infrastructure (no offline keys to lose), Trusted Publisher OIDC bound to the repo (any maintainer with repo write can publish), all process documented in https://github.com/allenfbyrd/evidentia/blob/main/docs/release-checklist.md. Project is in early growth phase; second maintainer will be recruited as the contributor base develops.


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


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

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

    Roadmap is documented at https://github.com/allenfbyrd/evidentia/blob/main/docs/ROADMAP.md with detailed per-release plans for the v0.7.x line: docs/v0.7.5-plan.md through docs/v0.7.9-plan.md (8-10 week ship target each). v0.8.0 plan also published (https://github.com/allenfbyrd/evidentia/blob/main/docs/v0.8.0-plan.md). Combined horizon exceeds 1 year.


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

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

    Canonical architecture document is https://github.com/allenfbyrd/evidentia/blob/main/Evidentia-Architecture-and-Implementation-Plan.md covering the 6-package monorepo structure, OSCAL-first data model, AI integration patterns, collector + integration architecture, and security boundaries. Capability matrix (https://github.com/allenfbyrd/evidentia/blob/main/docs/capability-matrix.md) covers the public surface inventory across 5 surface tiers and 5 risk tiers.


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

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

    Security requirements and threat boundary documented in https://github.com/allenfbyrd/evidentia/blob/main/docs/threat-model.md (~58 surfaces across 5 tiers including the v0.7.9 TPRM + vendor-risk-collector additions; explicit in-scope/out-of-scope; assumed-trust assumptions). Per-release security review (most recent: https://github.com/allenfbyrd/evidentia/blob/main/docs/security-review-v0.7.9.md) gives a CVSS/CWE/EPSS-classified view of the active surface. SECURITY.md (https://github.com/allenfbyrd/evidentia/blob/main/SECURITY.md) defines disclosure SLAs and supported-version policy with the supported-versions table refreshed at every release.


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

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

    90-second quickstart at https://github.com/allenfbyrd/evidentia/blob/main/docs/quickstart.md. README also has a "Getting Started" section with a 4-step install + first-gap-analysis flow.


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

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

    Documentation is refreshed every release per docs/release-checklist.md Step 4 (DOC refresh). Version-pinned docs live alongside per-release plan files (docs/v0.7.x-plan.md through docs/v0.7.9-plan.md + docs/v0.8.0-plan.md). All v0.7.9-era staleness items were closed at v0.7.9 ship time: CHANGELOG [Unreleased] gaps for in-flight commits (commit 3315150), README collectors row (Vanta/Drata/BitSight/SSC + Databricks/Snowflake/SQL/Okta), ROADMAP NEXT/PLANNED → SHIPPED for v0.7.5/v0.7.6/v0.7.7, evidentia-collectors pyproject description + keywords. Two earlier-flagged stale strings (CONTRIBUTING.md test count, SECURITY.md supported-versions table) shipped in v0.7.9 P0.6 OpenSSF Silver-tier prep batch (commit 6f862eb).


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

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

    Project achievements (OpenSSF Best Practices badge, OpenSSF Scorecard) are surfaced in the badge cluster at the top of the README: https://github.com/allenfbyrd/evidentia/blob/main/README.md. Live badge embed: OpenSSF Best Practices.


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


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

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [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). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    Public surfaces: GitHub repo + GitHub Pages (none yet) + the evidentia-ui SPA (alpha.2). The evidentia-ui frontend uses standard semantic HTML (React + accessible component primitives), keyboard-navigable forms, and ARIA labels on interactive elements. CLI output is plain text (screen-reader friendly by definition; no animated/colored-only UX). Documentation is plain Markdown rendered by GitHub (which provides standard a11y rendering). A formal WCAG 2.1 AA audit of evidentia-ui is planned for v0.8.0+.


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

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

    Evidentia produces compliance artifacts (OSCAL JSON/XML, gap reports, risk statements) — its end-user output is structured data targeting US/EU regulatory frameworks (NIST 800-53, ISO 27001, SOC 2, FedRAMP, FFIEC, OCC 2011-12, FRB SR 11-7) which are themselves authored in English. The CLI's operator-facing strings (help text, errors) are in English and intended for technical operators. There is no localized end-user text generation path that would benefit from i18n. The 89 bundled catalogs ship in their authoritative source language (English).


  • Другое


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

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

    Project sites do not store user passwords. GitHub repo handles its own auth; bestpractices.dev account is on the OpenSSF service; PyPI publishing is via Trusted Publisher OIDC (no API tokens stored). Evidentia OSS edition does not provide a public auth surface that would require password storage.


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

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


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

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

    Upgrade path is documented in CHANGELOG.md (https://github.com/allenfbyrd/evidentia/blob/main/CHANGELOG.md) with per-release "Changed", "Fixed", "Removed" sections following Keep a Changelog 1.1.0. SemVer adherence (pre-1.0: minor bumps for new feature surface, patches for fixes) means breaking changes carry an explicit Deprecation notice in the prior release. Supported-versions matrix documented in SECURITY.md. Older versions remain installable from PyPI for the duration of their security-supported window.


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

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


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

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

    GitHub Issues is the project's issue tracker: https://github.com/allenfbyrd/evidentia/issues. Issue templates for bug reports and feature requests live at https://github.com/allenfbyrd/evidentia/tree/main/.github/ISSUE_TEMPLATE.


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


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

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

    No external vulnerability reports have been received in the last 12 months. Upstream-CVE remediations (e.g., PR #8 addressing litellm + python-multipart) credited the upstream advisory IDs (GHSA-r75f-5x8p-qvmc + 3 others) in the commit + CHANGELOG entry. A "Security Acknowledgments" section will be added to SECURITY.md the first time an external reporter is involved.


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

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

    Vulnerability response process is documented in https://github.com/allenfbyrd/evidentia/blob/main/SECURITY.md with: 3-business-day initial acknowledgement SLA, 10-business-day triage SLA, 90-day coordinated disclosure window (shortenable if upstream fixes exist, lengthenable by reporter agreement), in-scope and out-of-scope definitions, supported-versions matrix, and pointers to PEP 740 attestation + Sigstore/Rekor verification commands. Internal handling steps (triage → fix → CVE assignment → coordinated release → post-mortem) are documented in docs/release-checklist.md.


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

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


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

    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [coding_standards]
    В большинстве случаев это делается путем ссылки на некоторые существующие руководства по стилю, возможно, с перечислением различий. Эти руководства по стилю могут включать в себя способы повышения удобочитаемости и способы снижения вероятности дефектов (включая уязвимости). Многие языки программирования имеют один или несколько широко используемых руководств по стилю. Примеры руководств по стилю включают Руководство по стилю Google и Стандарты кодирования SEI CERT.

    Coding standards are documented in CONTRIBUTING.md (https://github.com/allenfbyrd/evidentia/blob/main/CONTRIBUTING.md) and ruff config (https://github.com/allenfbyrd/evidentia/blob/main/pyproject.toml): Python 3.12+ following PEP 8 (enforced by ruff E/W rules), PEP 257 docstrings, isort import ordering (ruff I), pyflakes hygiene (F), pyupgrade modernization (UP), flake8-bugbear common-bug rules (B), flake8-simplify simplifications (SIM). Type annotations are required everywhere (mypy strict). Pydantic v2 models for all external inputs (extra="forbid"). TypeScript frontend uses ESLint + Prettier (config in packages/evidentia-ui/).


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

    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]
    Это МОЖЕТ быть реализовано при помощи инструмента(ов) статического анализа и/или путем пропускания кода через средства переформатирования. Во многих случаях конфигурация инструмента включена в репозиторий проекта (так как разные проекты могут выбирать разные конфигурации). Проекты МОГУТ (и, как правило, будут) допускать исключения стиля; там, где происходят исключения, они ОБЯЗАНЫ быть редки и документированы в соответствующих местах кода, чтобы эти исключения можно было пересматривать и инструменты могли автоматически обрабатывать их в будущем. Примеры таких инструментов включают ESLint (JavaScript) и Rubocop (Ruby).

    ruff (Python) + mypy strict (Python types) + ESLint (TypeScript) + Prettier (TypeScript formatting) all enforced as required CI status checks on every push and PR via https://github.com/allenfbyrd/evidentia/blob/main/.github/workflows/test.yml. Pre-commit hooks (https://github.com/allenfbyrd/evidentia/blob/main/.pre-commit-config.yaml) catch issues before commit-time.


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


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

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

    Pure Python + TypeScript, no native binaries.


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

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

    Pure Python; debug info is implicit via traceback.


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

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

    uv workspace builds packages atomically; no recursive Make pattern.


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

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

    Builds are deterministic given uv.lock pinning. uv.lock (https://github.com/allenfbyrd/evidentia/blob/main/uv.lock) pins every transitive dependency by hash. Wheel building via hatchling is deterministic given fixed inputs. CI rebuilds on each commit produce reproducible artifacts (verifiable by re-running release.yml against a tag — same wheel hashes emerge).


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


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

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

    Standard Python install: pip install evidentia (or pip install "evidentia[gui]" for full extras). Uninstall: pip uninstall evidentia. Container alternative: docker pull ghcr.io/allenfbyrd/evidentia:latest. Documented in https://github.com/allenfbyrd/evidentia/blob/main/docs/quickstart.md.


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

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

    Python pip install respects standard --user / --prefix / virtualenv conventions; no autotools-style DESTDIR pattern applies.


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

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

    Dev bootstrap: git clone ..., then uv sync --all-packages installs all 6 packages + dev deps + tests in one command. Documented in CONTRIBUTING.md (https://github.com/allenfbyrd/evidentia/blob/main/CONTRIBUTING.md). devcontainer support also shipped (https://github.com/allenfbyrd/evidentia/blob/main/.devcontainer/) for one-click VS Code / GitHub Codespaces bring-up.


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


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

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

    External dependencies are declared in 7 pyproject.toml files (workspace root + 6 packages) and resolved/locked in https://github.com/allenfbyrd/evidentia/blob/main/uv.lock. CycloneDX SBOM (spec 1.6) is emitted on every release and attached to the GitHub Release for full computer-processable SBOM consumption.


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

    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для Ruby). Некоторые менеджеры пакетов включают в себя соответствующие механизмы. Допустимо оставлять уязвимость, если ее невозможно использовать, но такой анализ труден, и временами проще просто обновить или исправить эту часть кода.

    Dependabot scans weekly per https://github.com/allenfbyrd/evidentia/blob/main/.github/dependabot.yml (uv, npm, GitHub Actions, Docker — grouped + security-isolated). osv-scanner runs against the SBOM at every release per docs/release-checklist.md Step 5 (most recent: 0 CVEs at v0.7.8). GitHub Code Scanning + Secret Scanning + Dependency Graph all enabled at the repo level.


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

    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    All reused dependencies come through standard package managers (PyPI for Python, npm for the frontend, GHCR for container images). Updates flow through Dependabot grouped PRs (config: https://github.com/allenfbyrd/evidentia/blob/main/.github/dependabot.yml). No vendored convenience copies of upstream code.


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

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

    Codebase is on Python 3.12+ only (no legacy compat shims), Pydantic v2 (current major), latest LangChain/LiteLLM, FastAPI 0.110+, httpx (modern async-capable HTTP). ruff UP rule group continuously surfaces pyupgrade opportunities; backwards-compat hacks are rejected per project standard. Frontend is on Vite 8 + React 18 + TypeScript 5+ (current).


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


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

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

    test.yml runs pytest + ruff + mypy + frontend tests on every push to main and every pull request, with success/failure status reported as a required check. Workflow: https://github.com/allenfbyrd/evidentia/blob/main/.github/workflows/test.yml. Run history: https://github.com/allenfbyrd/evidentia/actions.


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

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

    Per docs/release-checklist.md Step 5 + the pre-release-review v4 process, every fix lands with a regression test. Recent examples: F-V08-DAST-1 / F-V08-DAST-3 (v0.7.8 schema-fidelity fixes) shipped with new pytest cases for the affected endpoints; F-007 (v0.7.7.1 Dockerfile pin) shipped with the docker-run smoke test elevation; F-V08-CR-MEDIUM Snowflake quoted-identifier (v0.7.9 carry-over) shipped with 4 new TestQuotedIdentifierEscape tests; F-V08-CR-MEDIUM Power BI 1MB guard (v0.7.9 carry-over) shipped with 4 new TestPushRowsByteCapBisection tests; v0.7.9 P0.4 Continuous-review HIGH findings (H-1/H-2/H-3/H-4/H-5 + F-V09-S1) shipped with stuck-cursor-guard tests + SIG BYO partial-match test + vendor_id=None ingest test. Test count growth across patch releases (965 → 977 → 1103 → 1259 → 1540) primarily reflects regression tests for fixed bugs + tests for new features.


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

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

    Met. Statement coverage measured by Codecov (independent FLOSS test-coverage service): 81.87% at v0.7.10 ship, exceeding the 80% threshold. Coverage is published on every push to main via .github/workflows/test.yml (codecov-action@v6.0.0 SHA-pinned). The codecov.yml config locks the project gate at 80% with a 1% per-PR drop threshold so regressions fail CI. Live badge: https://codecov.io/gh/allenfbyrd/evidentia. Coverage scope + omit rationale documented in pyproject.toml [tool.coverage.run]. Tooling: pytest-cov (FLOSS, MIT-licensed) + Codecov upload. https://codecov.io/gh/allenfbyrd/evidentia


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


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

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

    CONTRIBUTING.md PR checklist line: "New features include at least one test" — required, not optional. https://github.com/allenfbyrd/evidentia/blob/main/CONTRIBUTING.md. Reinforced by docs/release-checklist.md Step 5 which gates every tag on test additions for new feature surface (a tag cannot be cut if a release includes new public surface without paired tests).


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

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

    The test-addition policy is documented in the CONTRIBUTING.md PR checklist: https://github.com/allenfbyrd/evidentia/blob/main/CONTRIBUTING.md.


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


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

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

    mypy runs with strict = true (config in pyproject.toml) — implies disallow_untyped_defs, disallow_incomplete_defs, check_untyped_defs, disallow_untyped_decorators, no_implicit_optional, warn_redundant_casts, warn_unused_ignores, warn_return_any, no_implicit_reexport, and strict_equality. Pydantic v2 plugin is enabled for full schema validation in type-check. Ruff rule set is broad (8 rule groups). Type-checking covers all 138 source files at zero errors.


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

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


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

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

    Secure-design principles applied throughout the codebase per docs/threat-model.md and docs/security-review-v0.7.9.md:

    • Least privilege: GitHub Actions workflows default to read-only permissions with per-job elevation; collector API tokens are scoped to read-only (vendors:read for Vanta, vendor-inventory only for Drata, etc.).
    • Fail-safe defaults: Pydantic extra="forbid", offline mode is default-on for the AI module unless explicitly opted in, security-headers default OFF on localhost binds + auto-ON for non-loopback (--security-headers flag).
    • Complete mediation: every external input passes through validate_within() / Pydantic validation before reaching business logic; vendor inventory validates UUID-shape IDs at storage layer.
    • Separation of privilege: cosign keyless OIDC + Trusted Publisher OIDC (no long-lived secrets to compromise); vendor-risk-collector tokens never flow through CLI args or REST request bodies (env-var only).
    • Defense in depth: ruff + mypy + CodeQL + osv-scanner + Scorecard + manual /security-review per release. The v0.7.9 cycle ran THREE Continuous-variant pre-release-reviews mid-cycle (P0.1 close + P0.3+P0.2-first close + P0.4-quartet close) plus the final Pre-tag run at ship — surfacing 18 findings across the cycle (5 inline-fixed HIGH + 1 inline-fixed LOW security + 12 deferred MEDIUM/LOW).
    • Input validation as allowlist: Pydantic schemas enumerate accepted shapes; everything else rejected. CSV-injection defenses (CWE-1236) via _csv_safe in TPRM concentration-report + DD-questionnaire CSV/XLSX render paths.
    • Cross-host pagination guards: BitSight + Vanta + Drata pagination loops refuse to follow next URLs pointing off-host or to a TLS-downgraded HTTP scheme (CWE-319 defense, v0.7.9 P0.4 Continuous F-V09-S1).

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

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

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

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

    No SHA-1 (for security purposes), no CBC mode in SSH context, no deprecated TLS versions (relies on Python stdlib + httpx defaults which negotiate TLS 1.2+ with AEAD ciphers).


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

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

    Hash functions: hashlib supports the full SHA-2 (224/256/384/512) and SHA-3 family; Evidentia uses SHA-256 by default but the digest helper at packages/evidentia-core/src/evidentia_core/oscal/digest.py is parameterizable. Sigstore signing supports both ECDSA P-256 and RSA — the cosign CLI lets users pick. TLS cipher selection is delegated to httpx/urllib3 which negotiate from a wide modern AEAD ciphersuite list.


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

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

    Where Evidentia handles outbound credentials (LLM provider API keys, collector credentials for Postgres/MySQL/Snowflake/Databricks/Tableau/Power BI/Okta/ServiceNow + the v0.7.9 vendor-risk APIs Vanta/Drata/BitSight/SecurityScorecard), they are read from environment variables or external config files (never embedded in code, never accepted via CLI args or REST request bodies). Operator updates the env file; no code recompilation required. Documented in docs/quickstart.md and per-collector docs (sql-collectors.md, cloud-dw-collectors.md, bi-integrations.md, tprm.md).


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

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

    All outbound network communication is HTTPS / TLS 1.2+ via httpx (LLM provider calls, BI publish API calls) or HTTPS via the SDK clients (databricks-sdk, snowflake-connector-python, etc.). No legacy protocol support (FTP, telnet, plain HTTP for non-localhost) is implemented or exposed.


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

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

    All TLS connections go through Python's ssl module via httpx/urllib3 which negotiate TLS 1.2 or 1.3 by default against modern endpoints. Older TLS versions are not enabled.


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

    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    Default certificate verification is on for httpx (verify=True is the default), urllib3, and all collector SDKs (databricks-sdk, snowflake-connector-python, tableau-server-client, etc.). Certificate verification is never disabled in project code; only an operator-set env var would change this behavior.


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

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

    Same code path as crypto_certificate_verification — httpx and underlying urllib3/ssl perform the TLS handshake (with cert verification) before any application-layer request is sent. Headers including credentials are only emitted after the validated TLS session is established. No project code bypasses this ordering.


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


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

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

    Every PyPI release wheel + sdist is signed via Sigstore PEP 740 attestations (keyless OIDC, signed via the Sigstore public good instance and recorded in the Rekor transparency log). Container images are signed by cosign keyless OIDC against the image digest. SLSA L3 build provenance attestations are emitted for every release. Verification commands documented at https://github.com/allenfbyrd/evidentia/blob/main/docs/sigstore-quickstart.md. Private signing keys do not exist on the distribution side (keyless flow), satisfying the "private key not on distribution site" requirement by construction.


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

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

    Git tags are not currently GPG/SSH-signed at the tag-object level. Release artifacts are signed via Sigstore PEP 740 + cosign keyless OIDC + SLSA L3 provenance, which is a stronger and more verifiable provenance chain than git tag signing (the artifact's identity is bound to the GitHub Actions workflow + commit SHA in the OIDC token). Adding signed git tags is a planned addition in v0.8.0 (will use the same Sigstore identity).


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


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

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

    All external inputs are validated via Pydantic v2 with extra="forbid" (reject unknown fields). Specific patterns: validate_within() helper for path inputs (CWE-22 prevention); SQL collector queries are parameterized + LIMIT-bounded; Snowflake quoted-identifier escaping per Snowflake's documented double-up convention (v0.7.9 carry-over hardening); YAML loaded via yaml.safe_load (CWE-502 prevention); subprocess calls are shell=False (CWE-78 prevention); LLM provider calls validate the provider/model allowlist before dispatch. Catalog 22-character column-truncation, 17-endpoint schema-fidelity validation, offline-mode enforcement, BitSight/Vanta/Drata/SSC cross-host pagination guards (cross-host + TLS-scheme downgrade refusal per CWE-319), and CSV-injection defenses on TPRM concentration-report + DD-questionnaire user-content cells (CWE-1236 via _csv_safe OWASP single-quote prefix) all act as additional allowlist gates. The Power BI 1MB byte-cap guard (v0.7.9 carry-over) splits batches that exceed Power BI's documented 1MB request-body limit. Documented in docs/threat-model.md and docs/security-review-v0.7.9.md.


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

    В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    Hardening posture:

    • Container: distroless-style image (Dockerfile pins python by SHA digest); HEALTHCHECK present; non-root user where applicable.
    • HTTP API: FastAPI with Pydantic-validated request models; response headers include strict Content-Type; no stack-trace leakage in error responses (F-002, F-003 fixed in v0.7.7).
    • CI: workflow permissions default read-only with per-job elevation; SHA-pinned actions throughout (Scorecard Pinned-Dependencies signal green); CodeQL custom QL pack to suppress validate_within false positives.
    • Supply chain: PEP 740 + SLSA L3 + cosign signing closes the publish-side hardening loop.

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

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 25), и показывается, как противодействовать каждой из них. Полезным примером может служить обоснование для BadgeApp. Этот критерий связан с documentation_security, documentation_architecture и implement_secure_design.

    Assurance case is composed across three documents:

    1. Threat model: https://github.com/allenfbyrd/evidentia/blob/main/docs/threat-model.md — ~58 surfaces in 5 tiers (v0.7.9 ships TPRM module + 4 vendor-risk-collector additions to the surface inventory), explicit trust boundaries, in-scope/out-of-scope definitions.
    2. Security review (most recent release): https://github.com/allenfbyrd/evidentia/blob/main/docs/security-review-v0.7.9.md — applies CVSS/CWE/EPSS classification to the active surface and demonstrates that secure-design principles have been applied (least privilege, fail-safe defaults, complete mediation, separation of privilege, defense in depth) and common implementation weaknesses have been countered (CWE-22, CWE-78, CWE-89, CWE-502, CWE-209, CWE-319 cross-host TLS-downgrade, CWE-1236 CSV injection, CWE-693 protection-mechanism failure, etc.). The /pre-release-review v4 skill's mandatory /security-review invocations at Steps 3, 4, 6.C produce the input the document synthesizes.
    3. Accepted-findings registry: https://github.com/allenfbyrd/evidentia/blob/main/docs/enterprise-grade-accepted-findings.md — documents residual-risk acceptance with explicit rationale.

 Анализ 2/2 ●

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


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

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

    CodeQL ships with the default security-and-quality query packs which include rules for the OWASP Top 10 and CWE Top 25 (path traversal, SQL injection, XSS, command injection, deserialization vulns, hardcoded credentials, regex DoS, etc.). All these queries run on every push/PR.


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


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

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

    Evidentia is implemented in pure Python (memory-safe) for the backend and TypeScript (memory-safe) for the evidentia-ui frontend. No memory-unsafe language is used in project source.



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

Владелец анкеты на значок проекта: Allen Byrd.
2026-05-02 06:10:52 UTC, последнее изменение сделано 2026-05-16 02:28:02 UTC. Последний раз условия для получения значка были выполнены 2026-05-03 21:20:04 UTC.