ai-architect-mcp-codebase

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

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

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


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

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

        

 Основы 17/17

  • Общая

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

    Codebase intelligence MCP for AI agents — tree-sitter AST → LadybugDB property graph, import/call resolution with evidence-graded confidence, Leiden communities, hybrid BM25+TF-IDF+RRF search, impact analysis, PRD-hallucination + security gates. Rust · 24 tools (core-8 agent profile) · 503 tests.

    Используйте формат выражения лицензии 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/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#coding-standards-excerpt states the required standard (rustfmt plus the zetetic coding standards, with the project-specific rules spelled out), and https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#testing-policy-mandatory states the acceptance requirements for tests.


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


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

    There is no DCO sign-off requirement and no CLA today. All non-trivial code to date is the sole maintainer's own, contributed under the project's MIT licence. The position, and the intent to adopt a DCO (git commit -s) rather than a CLA if outside contributors begin submitting non-trivial changes, is stated at https://github.com/cdeust/automatised-pipeline/blob/main/GOVERNANCE.md#contribution-licensing



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

    https://github.com/cdeust/automatised-pipeline/blob/main/GOVERNANCE.md — who decides, how a decision is made, how disagreement is resolved, how a change gets in, and how someone becomes a maintainer.



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

    https://github.com/cdeust/automatised-pipeline/blob/main/CODE_OF_CONDUCT.md, in the standard top-level location, and linked from CONTRIBUTING.md.



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

    https://github.com/cdeust/automatised-pipeline/blob/main/GOVERNANCE.md#roles-and-responsibilities — maintainer, contributor and security reporter, what each is responsible for, and who holds the maintainer role. It states plainly that there is currently one person in it.



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

    https://github.com/cdeust/automatised-pipeline/blob/main/GOVERNANCE.md#continuity-of-access — what survives the maintainer becoming unavailable (public MIT source, complete history in every clone, tagged releases, a compiler and dependency graph pinned so a fork can rebuild the exact artifact), and what is genuinely single-owner. The single point of failure is named rather than papered over.



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

    The bus factor is 1: one maintainer. This is stated rather than hidden, together with what survives their loss and how a fork continues, at https://github.com/cdeust/automatised-pipeline/blob/main/GOVERNANCE.md#continuity-of-access. Adding a second maintainer is item 5 on https://github.com/cdeust/automatised-pipeline/blob/main/docs/ROADMAP.md and is the single change that would most improve this project's resilience.


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


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

    https://github.com/cdeust/automatised-pipeline/blob/main/docs/ROADMAP.md states what the project intends to do over the next year (graph fidelity, the file-size split epic, making the supply-chain assurance real on a published release, holding coverage as a gate, and the badge levels) and has an explicit section on what it will not do — no code writing, no PRD generation, no network at index time, no model runtime.



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

    https://github.com/cdeust/automatised-pipeline#architecture documents the high-level design: the transport-to-handler-to-core layering, every core module and its responsibility, the graph-per-finding storage model and why it was chosen, and the address-space configuration with its measured derivation. The trust boundaries between those components are enumerated in https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md



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

    https://github.com/cdeust/automatised-pipeline/blob/main/SECURITY.md states what a user can and cannot expect: exactly what the tool reads, what assurance is offered over the artifact, and the limits stated rather than implied. The argument that those requirements are met, with its trust boundaries and residual risks, is at https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md



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

    https://github.com/cdeust/automatised-pipeline#getting-started — prerequisites, clone and build, register the MCP server, and a first run that exercises the handshake over stdio, with a copy-pasteable JSON-RPC call.



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

    Documentation is corrected in the same pull request as the change, and version pins are machine-checked rather than hand-maintained (https://github.com/cdeust/automatised-pipeline/blob/main/scripts/check_marketplace_pins.py runs in CI and fails on a stale pin). Numeric claims are no longer hand-maintained either: https://github.com/cdeust/automatised-pipeline/blob/main/scripts/check_doc_claims.py runs in the required cargo test job and fails when the README's advertised tool count, tool names, language count, test count or coverage percentage disagrees with the tool registry, the Language enum, the suite's own tally or the coverage job, and when the repository-layout tree names a path that does not exist. It was written after drift was found by hand (an advertised 434 tests against a 947-test suite) and it immediately caught four more: 24 advertised tools against 26 registered, 10 languages against 11, 16 hidden tools against 18, and two registered tools that no section documented. All were fixed and the scale table was re-measured on the lbug version actually depended on, closing https://github.com/cdeust/automatised-pipeline/issues/161.



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

    The repository front page identifies and hyperlinks its achievements as badges: the OpenSSF Best Practices badge for this project (https://www.bestpractices.dev/projects/13845, live in the README badge row and linked back to the project page), alongside licence, test count, measured coverage, tool count and language count. https://github.com/cdeust/automatised-pipeline#readme. Release-by-release achievements are recorded in https://github.com/cdeust/automatised-pipeline/blob/main/CHANGELOG.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). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    The project results have no graphical user interface: the software is an MCP server speaking stdio, and its output is JSON and Markdown that the consuming host renders, so the host's own accessibility settings apply. The project site is GitHub, and the documentation is Markdown with text alternatives on its images (the README banner carries an alt attribute).



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

    The software's user-facing strings — tool descriptions, error messages, diagnostics — are English literals and are not externalized for localization. The code it indexes is unaffected (identifiers and paths are passed through unchanged in whatever language the user writes, and ten source languages are supported), but the software itself has not been internationalized and is reported as such rather than claimed.


  • Другое


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

    The project operates no site of its own that authenticates external users. The repository, the issue tracker and the release downloads are hosted on GitHub, and the software stores no passwords for inbound authentication.


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

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


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

    The support policy is stated at https://github.com/cdeust/automatised-pipeline/blob/main/SECURITY.md — the latest minor release on main receives security patches. The upgrade path is a reinstall (cargo install ai-architect-mcp, a new release tarball, or the plugin pin moving), and there is no user-authored persisted state to migrate: graph artifacts are derived data, regenerated by re-indexing. Breaking changes are recorded per release in https://github.com/cdeust/automatised-pipeline/blob/main/CHANGELOG.md


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

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


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

    GitHub Issues, with structured templates for bug reports, enhancement requests and audit findings: https://github.com/cdeust/automatised-pipeline/issues


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


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

    No vulnerability has been reported and resolved in the last 12 months, so there is no reporter to credit. The standing commitment to credit reporters in the release notes for the patched version, unless they request anonymity, is at https://github.com/cdeust/automatised-pipeline/blob/main/SECURITY.md#recognition



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

    https://github.com/cdeust/automatised-pipeline/blob/main/SECURITY.md#response-sla documents the response process: a per-severity first-response and patch SLA, and a five-step coordinated-disclosure timeline from private report to public advisory, including the default 30-day disclosure window and reporter credit.


 Качество 19/19

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


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

    The primary language is Rust; the standard is rustfmt plus the project-specific rules named at https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#coding-standards-excerpt, which cites the full zetetic coding standards it derives from (no warnings, no unjustified unwrap/expect, no unsafe without a safety comment, sourced constants, file and function size caps, Result over panics at API boundaries).



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

    Automatically enforced by two FLOSS tools as required status checks on every push and pull request: cargo fmt --all --check for formatting and cargo clippy --workspace --all-targets -- -D warnings for the lint rules (https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/ci.yml). Exceptions must be a single #[allow(...)] with an inline justification, per CONTRIBUTING.md.


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


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

    Native binaries are produced, and the standard variables are honoured rather than replaced. Cargo passes RUSTFLAGS through to rustc, and the C/C++ dependencies (the tree-sitter runtime, zstd, the LadybugDB core) build through the cc crate, which reads CC, CFLAGS, CXX and CXXFLAGS. Nothing in https://github.com/cdeust/automatised-pipeline/blob/main/.cargo/config.toml or the workflows overrides them — the release job only adds ZSTD_SYS_USE_PKG_CONFIG, which extends the build environment rather than replacing a user-provided value.



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

    Debugging information is controlled by the Cargo profile and honoured by cargo build and cargo install, which is how a developer or packager builds this project; nothing in the build system discards it. Disclosure: the release workflow runs a best-effort strip on the packaged tarball binary for download size (https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/release.yml), so the prebuilt artifact is stripped. A user who needs symbols builds from source with the toolchain pinned in rust-toolchain.toml and gets an identical binary — see build_repeatable.



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

    One Cargo workspace with a single, accurate dependency graph across all six members (https://github.com/cdeust/automatised-pipeline/blob/main/Cargo.toml). Cargo resolves cross-member dependencies itself; there is no recursive make and no per-subdirectory independent build.



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

    Measured, not assumed. The compiler is pinned in https://github.com/cdeust/automatised-pipeline/blob/main/rust-toolchain.toml (1.95.0) and the dependency graph in Cargo.lock. On 2026-07-27 (macOS aarch64, rustc 1.95.0), cargo build --release --bin automatised-pipeline produced sha256 5b3dcc46f4dc2fcbd0969fa1b27ff75ce576b75ce2e833a9aee8977246df8650; the target directory was then deleted and the build repeated from scratch, producing the identical digest. Stated limit: the target path is embedded, so a build into a different CARGO_TARGET_DIR differs (389394362d5e...); bit-identity across different paths would additionally require --remap-path-prefix, which is not configured today.


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


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

    Three commonly-used conventions, all documented at https://github.com/cdeust/automatised-pipeline#getting-started: the language package manager (cargo install ai-architect-mcp, uninstall with cargo uninstall), a prebuilt platform tarball from the GitHub release, and the .mcpb bundle / plugin marketplace entry that MCP hosts install and remove through their own UI.



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

    Installation goes through cargo, which honours the standard conventions for install location: --root and CARGO_INSTALL_ROOT select the destination, CARGO_HOME relocates the default. No bespoke prefix handling is introduced.



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

    git clone then cargo build and cargo test installs every dependency, the test fixtures and the test environment in one commonly-used command each — cargo resolves the whole graph from the committed Cargo.lock. Documented at https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#dev-setup


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


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

    Declared in a computer-processable form and version-locked: https://github.com/cdeust/automatised-pipeline/blob/main/Cargo.toml with the rationale for each direct crate, and Cargo.lock pinning the full transitive graph. A CycloneDX SBOM of that graph is generated at release time by https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/release.yml



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

    Two independent mechanisms. cargo audit and cargo deny run daily against the RUSTSEC database and block on any advisory that is not explicitly accepted with a written reason (https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/supply-chain-audit.yml, https://github.com/cdeust/automatised-pipeline/blob/main/deny.toml). Dependabot opens weekly grouped update PRs for both cargo and github-actions (https://github.com/cdeust/automatised-pipeline/blob/main/.github/dependabot.yml). The one advisory currently in the tree is analysed as unexploitable here and blocked upstream, with the evidence written into deny.toml. GitHub's own Dependabot alerts and security updates were enabled on 2026-07-28, so a newly published advisory raises an alert and an upgrade PR without waiting for the next scheduled audit run. Verify: gh api repos/cdeust/automatised-pipeline --jq '.security_and_analysis.dependabot_security_updates.status' returns enabled, and gh api repos/cdeust/automatised-pipeline/vulnerability-alerts returns HTTP 204.



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

    No vendored, forked or convenience-copied component. Every external component is a normal versioned crate resolved by cargo from crates.io (https://github.com/cdeust/automatised-pipeline/blob/main/deny.toml denies unknown registries and unknown git sources), so updating one is a version bump in Cargo.toml or an automated Dependabot PR.



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

    The stack is current: the pinned toolchain is Rust 1.95.0, and the load-bearing dependencies are on their current majors (tantivy 0.26.1, lbug 0.18.3, tree-sitter 0.25 with ABI-15 grammars). No deprecated or obsolete API is relied on. The single frozen transitive pin (cxx 1.0.138, held by lbug's exact requirement) is documented with the upstream evidence in https://github.com/cdeust/automatised-pipeline/blob/main/deny.toml rather than left as unexplained drift.


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


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

    Every push to main and every pull request runs the full suite plus the structural graph-accuracy gate, and both are required status checks that report pass or fail on the PR: https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/ci.yml. The per-stage tests/*_integration.rs suites drive the pipeline end to end against fixture data, and several spawn a real process and exercise the stdio wire protocol.



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

    Well above 50%: 34 test files in https://github.com/cdeust/automatised-pipeline/tree/main/tests carry the issue number of the defect they regress-test in their header, covering the bugs fixed over the last six months (for example #16 Cypher injection, #57 coverage honesty, #92 type-usage edges, #148 fuzz OOM, #143 disk-full diagnostics). The rule that a bug fix ships with a test that fails on the pre-fix code is written at https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#testing-policy-mandatory



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

    Enforced, not merely measured: the cargo llvm-cov (80% line floor) job in https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/ci.yml runs cargo llvm-cov --workspace on every pull request and every push to main and fails the build below --fail-under-lines 80. It is a required status check on main, so a change that drops coverage under the threshold cannot merge. Latest measurement from that job: 87.73% line coverage on the Linux CI runner, the figure the badge answers to (the same workspace measures 86.83% on macOS aarch64 — see the note on platform variance in the #160 entry) — up from 81.56% after issue #169 covered the five MCP handler modules that had 0% (verification_ops, verification_core, prd_handlers, symbol_handlers) or 43.83% (search_context_handlers). The README badge is machine-checked against the same job by https://github.com/cdeust/automatised-pipeline/blob/main/scripts/check_doc_claims.py, which fails the build if the advertised figure overstates the measured one — so this answer cannot silently become false the way it could when the number came from a hand-run command.


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


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

    The formal written policy is at https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#testing-policy-mandatory: new functionality MUST ship with tests in the same pull request, every bug fix MUST ship a regression test that fails on the pre-fix code, a defence that only a reviewer enforces MUST be replaced by a mechanical guard, and coverage MUST NOT regress below 80%. The consequence is stated — a PR that adds behaviour and no test is not ready for review.



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


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

    Maximally strict and enforced, not merely enabled: cargo clippy --workspace --all-targets -- -D warnings plus cargo fmt --all --check run as a required status check on every push and pull request (https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/ci.yml, the clippy job). Allow-attributes require an inline justification per https://github.com/cdeust/automatised-pipeline/blob/main/CONTRIBUTING.md#coding-standards-excerpt


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

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


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

    https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md Claim 4 maps each principle to code: fail-safe defaults and allowlisting (validate_safe_id accepts only [A-Za-z0-9._-] and rejects empty, over-long, leading-dot and .. ids; require_absolute rejects relative paths and any parent-dir component), complete mediation (validation sits at the single boundary every tool call crosses, so a new tool cannot forget it), economy of mechanism (one escaping function, one size-config resolver, one response budget, each with its own tests), and least privilege (every workflow declares contents: read and elevates only where it must, which is why Scorecard's Token-Permissions check scores 10).


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

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

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

    No security mechanism depends on cryptography, so there is no default algorithm choice whose weakening would matter. See the crypto_working justification for the two non-security hash uses.



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

    No security mechanism depends on a cryptographic algorithm, so there is no algorithm choice for a user to switch. The two hashes in the tree are used for a local integrity digest and for content addressing.



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

    The software processes no authentication credentials and no private cryptographic keys. It authenticates nothing and connects to nothing.



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

    The software performs no network communication. It speaks MCP over stdio and opens no socket; indexing is entirely local. Verified rather than assumed: cargo tree -e normal resolves 172 crates and none of them is reqwest, hyper, ureq, curl, tokio, async-std, rustls or openssl (checked 2026-07-27), and the exclusion of an HTTP client is a stated design decision in https://github.com/cdeust/automatised-pipeline#dependencies



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

    The software does not use TLS; it performs no network communication at all. See crypto_used_network.



    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата 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?" Майкла Катанзаро.

    The software does not use TLS, so there is no certificate verification to perform. See crypto_used_network.



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

    The software does not use TLS and sends no HTTP headers, private or otherwise. See crypto_used_network.


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


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

    Met as of v0.8.3, measured 2026-07-29. Every release asset carries a provenance attestation AND publishes the Sigstore bundle beside it: gh attestation verify <asset> --repo cdeust/automatised-pipeline succeeds for all three platform tarballs, the .mcpb and the CycloneDX SBOM, and the release page carries a sibling <asset>.sigstore.json for each. Publishing the bundle is what makes the signature visible at all to an offline consumer and to Scorecard, whose Signed-Releases check scores on the presence of such an asset rather than on the attestation API (ossf/scorecard docs/checks.md). Release run 30402899199. The windows-x86_64 asset is absent from v0.8.3 — its build failed on an MSVC link error, tracked as issue #176 — so this criterion is answered for the assets that shipped, not for a platform that did not.



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

    Release tags are annotated but not cryptographically signed (git tag -v v0.8.4 reports no signature). Release ARTIFACTS are covered instead, which is where the tampering risk actually lands: each carries a SHA-256 companion, a Sigstore build-provenance attestation verified by gh attestation verify, and the attestation bundle published beside it as <asset>.sigstore.json. This matches the posture of the sibling project cdeust/prd-spec-generator, whose v0.6.1 tag is likewise annotated-and-unsigned with artifact-level coverage answering the criterion. See https://github.com/cdeust/automatised-pipeline/blob/main/SECURITY.md


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


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

    All input from potentially untrusted sources is checked against an allowlist at the boundary it crosses. Tool arguments: validate_safe_id accepts only [A-Za-z0-9._-]+ with a length cap and rejects empty, leading-dot and .. ids; require_absolute rejects relative paths and any parent-dir component; each tool rejects a missing required field with a named error rather than a default. Repository content: symbol names and paths derived from indexed files pass through the single graph_store::cypher_str escaping choke point, whose reintroduction guard is https://github.com/cdeust/automatised-pipeline/blob/main/tests/no_naive_cypher_escape.rs, and parser input is size- and time-bounded. Responses are budgeted to a derived 100,000-character cap (https://github.com/cdeust/automatised-pipeline/blob/main/src/response_budget.rs). The full argument is Claims 1, 3 and 4 of https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md



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

    This criterion counts mechanisms such as HTTP response headers or compiler hardening flags, and explicitly excludes least privilege. No such flag is configured: the release profile uses Cargo's defaults, and the software serves no HTTP surface for a Content Security Policy to apply to. The protections it does have are of other kinds — memory safety by construction with exactly one audited unsafe block in src/, overflow-checks and debug-assertions enabled in the fuzz profile, bounded responses, bounded parse input and a bounded database reservation — and they are described where they belong, in https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md, rather than counted here as hardening they are not.



    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется 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.

    https://github.com/cdeust/automatised-pipeline/blob/main/docs/ASSURANCE-CASE.md — the threat model (what the tool reads, why its input is untrusted, what privileges it runs with), a table of the six trust boundaries and where each is mediated, five claims with the evidence and the stated limit of each, an explicit argument that secure design principles are applied, and a table mapping each common implementation weakness class to what counters it and what residual risk remains. It closes with what the case does not claim.


 Анализ 2/2

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


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

    CodeQL runs with queries: security-and-quality, which includes the common-vulnerability query packs, over the rust and actions languages: https://github.com/cdeust/automatised-pipeline/blob/main/.github/workflows/codeql.yml


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


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

    The fuzz targets run under AddressSanitizer: cargo-fuzz's --sanitizer option defaults to address (rust-fuzz/cargo-fuzz, src/options.rs) and the workflow does not override it. The fuzz profile also keeps debug-assertions and overflow-checks on (https://github.com/cdeust/automatised-pipeline/blob/main/fuzz/Cargo.toml), so a violated invariant becomes a crash the fuzzer can find. This matters here because the parser runtime underneath is C.



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/13845/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). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Clement и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Clement.
2026-07-27 22:30:28 UTC, последнее изменение сделано 2026-08-04 21:20:03 UTC. Последний раз условия для получения значка были выполнены 2026-08-02 23:40:22 UTC.