sipnab

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

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

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


Это критерии Базового Уровня 2. Это критерии версии v2026.08.28.

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

        

 Основы

  • Общая

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

    sipnab is a SIP and RTP capture, analysis, and security tool for VoIP networks. It unifies sngrep (interactive TUI) and sipgrep (CLI) into a single Rust binary, adding first-class RTP quality monitoring (jitter, loss, MOS), VoIP diagnostic aliases, TLS/SRTP decryption, and security analysis (scanner, flood and fraud detection, STIR/SHAKEN). It also runs as an MCP server so an AI agent can drive it. Its only runtime dependency is libpcap.

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

    sipnab is under active development and not yet recommended for production use (the README states this). Despite the pre-1.0 status, it enforces a strict quality bar: more than 10,000 automated tests (10,468 at v0.5.196) run in CI on every push; Clippy and CodeQL gate every merge on a deny-on-warning basis; 19 fuzz targets cover every attacker-controlled parser and run daily under AddressSanitizer via ClusterFuzzLite, with ThreadSanitizer weekly over the threaded paths; releases ship with sigstore build provenance and CycloneDX SBOMs; and the tool is validated against a real-traffic pcap corpus. SECURITY.md documents the security model, including privilege drop, chroot and the scope of reportable issues.

    One note for reviewers of the crypto criteria: sipnab decrypts SIP and RTP that other systems encrypted, so it must interoperate with whatever algorithm a capture used. Vetted "weak" algorithms may therefore appear where reading an existing capture requires them — the project does not choose weak cryptography for its own protection.

 Элементы управления 19/19 ●

  • Элементы управления


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

    Когда задача CI/CD выполняется без указания прав доступа, система CI/CD ОБЯЗАНА по умолчанию назначать задаче минимальные права, предоставленные в конвейере. [OSPS-AC-04.01]
    Настройте параметры проекта для назначения минимальных доступных прав новым конвейерам по умолчанию, предоставляя дополнительные права только при необходимости для конкретных задач.

    https://github.com/NormB/sipnab/tree/main/.github/workflows

    ▎ The repository's Actions settings default the GITHUB_TOKEN to the lowest permission: default_workflow_permissions is read (read-only) and can_approve_pull_request_reviews is false, so any CI/CD task run with no permissions: specified receives read-only access. In addition, every workflow in .github/workflows/ declares an explicit least-privilege permissions: block — most are top-level contents: read; scorecard.yml uses permissions: {} (no permissions); and workflows that need more, such as pages.yml, grant only the specific scopes required (pages: write, id-token: write) rather than blanket write access. See https://github.com/NormB/sipnab/tree/main/.github/workflows .


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

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

    Unique crate version, currently 0.5.83. [version_unique]


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

    Когда создается официальный выпуск, этот выпуск ОБЯЗАН содержать описательный журнал функциональных изменений и изменений безопасности. [OSPS-BR-04.01]
    Убедитесь, что все выпуски содержат описательный журнал изменений. Рекомендуется обеспечить, чтобы журнал изменений был читаемым человеком и содержал более подробные сведения, чем сообщения коммитов, такие как описания влияния на безопасность или релевантность для различных сценариев использования. Для обеспечения машиночитаемости размещайте содержимое под заголовком markdown, таким как "## Changelog".

    Non-trivial release notes file in repository: https://github.com/NormB/sipnab/blob/main/CHANGELOG.md. [release_notes]


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

    Когда конвейер сборки и выпуска загружает зависимости, он ОБЯЗАН использовать стандартизированные инструменты, где они доступны. [OSPS-BR-05.01]
    Используйте общие инструменты для вашей экосистемы, такие как менеджеры пакетов или инструменты управления зависимостями для загрузки зависимостей во время сборки. Это может включать использование файла зависимостей, lock-файла или манифеста для указания требуемых зависимостей, которые затем подключаются системой сборки.

    Dependencies are ingested only through Cargo, Rust's standard tooling, from crates.io, resolved and pinned by the committed Cargo.lock. cargo-deny (deny.toml) enforces license, source and advisory policy, cargo-audit and OSV-Scanner check for advisories, and Dependabot proposes updates. CI actions are pinned to full commit SHAs.


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

    Когда создается официальный выпуск, этот выпуск ОБЯЗАН быть подписан или учтен в подписанном манифесте, включающем криптографические хеши каждого актива. [OSPS-BR-06.01]
    Подписывайте все выпущенные программные активы во время сборки с использованием криптографической подписи или аттестаций, таких как подпись GPG или PGP, подписи Sigstore, происхождение SLSA или SLSA VSA. Включите криптографические хеши каждого актива в подписанный манифест или файл метаданных.

    Every release artifact has a sigstore build-provenance attestation, generated in release.yml via GitHub artifact attestations (OIDC, keyless) and verifiable with gh attestation verify, plus SHA-256 checksums and CycloneDX SBOMs. crates.io publishing uses OIDC trusted publishing from the same tag-triggered workflow.


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

    Когда проект создал выпуск, документация проекта ОБЯЗАНА включать описание того, как проект выбирает, получает и отслеживает свои зависимости. [OSPS-DO-06.01]
    Рекомендуется публиковать эту информацию вместе с технической документацией и документацией по дизайну проекта в общедоступном ресурсе, таком как репозиторий исходного кода, веб-сайт проекта или другой канал.

    The Dependencies section of CONTRIBUTING.md explains how new crates are chosen (license allowlist, crates.io only, no open advisories) and how they are tracked: Cargo.lock, cargo-audit and cargo-deny in CI, OSV-Scanner and Dependabot: https://github.com/NormB/sipnab/blob/main/CONTRIBUTING.md#dependencies


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

    Документация проекта ДОЛЖНА включать инструкции по сборке программного обеспечения, включая необходимые библиотеки, фреймворки, SDK и зависимости. [OSPS-DO-07.01]
    Рекомендуется публиковать эту информацию вместе с документацией для участников проекта, например в файле CONTRIBUTING.md или другой документации по задачам разработчика. Это также может быть задокументировано с помощью целей Makefile или других сценариев автоматизации.

    Build instructions, including the Rust toolchain version, the libpcap dependency, feature flags and platform packages, are in CONTRIBUTING.md (Prerequisites, Build from Source: https://github.com/NormB/sipnab/blob/main/CONTRIBUTING.md) and the install guide (https://sipnab.com/docs/install/, Build it from source). The full CI/release build is documented at https://sipnab.com/docs/internals/build-ci-release/


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

    Документация проекта ОБЯЗАНА включать список участников проекта, имеющих доступ к чувствительным ресурсам. [OSPS-GV-01.01]
    Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта. Это может быть просто включение имен или учетных записей в список сопровождающих или более сложное в зависимости от управления проектом.

    MAINTAINERS.md (https://github.com/NormB/sipnab/blob/main/MAINTAINERS.md) lists the project's only member with access to sensitive resources: Norm Brandinger (@NormB), who owns the repository, its settings and secrets, the release pipeline, crates.io publishing, and the CLA Assistant configuration. .github/CODEOWNERS (* @NormB) records the same.


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

    Документация проекта ОБЯЗАНА включать описания ролей и обязанностей участников проекта. [OSPS-GV-01.02]
    Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта.

    MAINTAINERS.md (https://github.com/NormB/sipnab/blob/main/MAINTAINERS.md) describes the maintainer's role and responsibilities: reviewing and merging pull requests, owning the CLA flow, cutting releases, and supporting only the latest release. It also states the project has no other roles and no succession plan. CONTRIBUTING.md covers the contributor role.


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

    Документация проекта ОБЯЗАНА включать руководство для авторов кода, содержащее требования к приемлемым вкладам. [OSPS-GV-03.02]
    Расширьте содержимое CONTRIBUTING.md или CONTRIBUTING/ в документации проекта, чтобы изложить требования к приемлемым вкладам, включая стандарты кодирования, требования к тестированию и руководства по отправке для участников кода. Рекомендуется, чтобы это руководство было источником истины как для участников, так и для утверждающих.

    https://github.com/NormB/sipnab/blob/main/CONTRIBUTING.md#code-style

    CONTRIBUTING.md states the requirements for acceptable contributions: a Code Style section (Rust standard style enforced by cargo fmt, and Clippy on a deny-on-warning basis), a Running Tests section requiring the suite to pass and new functionality to ship with tests, a Git Hooks section describing the pre-commit/pre-push gates every contribution must clear, a Documentation section, a Commit Messages convention, and a Pull Request Process section. Contributions that don't meet these (formatting, lint, tests, docs) are blocked by CI. [contribution_requirements]


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

    Система управления версиями ОБЯЗАНА требовать от всех авторов кода подтверждения того, что они юридически уполномочены вносить соответствующие изменения, при каждом коммите. [OSPS-LE-01.01]
    Включите DCO в репозиторий проекта, требуя от участников кода утверждать, что они имеют законное право вносить соответствующий вклад в каждом коммите. Используйте проверку статуса, чтобы убедиться, что утверждение сделано. CLA также удовлетворяет этому требованию. Некоторые системы контроля версий, такие как GitHub, могут включать это в условия обслуживания платформы.

    Every contribution requires a signed Contributor License Agreement through CLA Assistant; license/cla is a required status check on main, so no pull request merges without the author's legal assertion. Only bot accounts are allowlisted: https://github.com/NormB/sipnab/blob/main/CLA.md


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

    При внесении коммита в основную ветку все автоматические проверки статуса для коммитов ДОЛЖНЫ пройти успешно или быть явно обойдены вручную. [OSPS-QA-03.01]
    Настройте систему контроля версий проекта таким образом, чтобы все автоматические проверки статуса должны были пройти успешно или требовать ручного подтверждения перед тем, как коммит может быть объединен с основной веткой. Рекомендуется НЕ настраивать необязательные проверки статуса как требование успешного прохождения или провала, которые утверждающие могут быть склонны обойти.

    GitHub Actions runs the suite on every push and pull request. [test_continuous_integration]


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

    Перед принятием коммита в проекте ДОЛЖЕН выполняться хотя бы один автоматизированный набор тестов в конвейере CI/CD для обеспечения соответствия изменений ожиданиям. [OSPS-QA-06.01]
    Автоматизированные тесты должны выполняться перед каждым объединением с основной веткой. Набор тестов должен выполняться в конвейере CI/CD, и результаты должны быть видны всем участникам. Набор тестов должен выполняться в согласованной среде и таким образом, чтобы участники могли выполнять тесты локально. Примеры наборов тестов включают модульные тесты, интеграционные тесты и сквозные тесты.

    GitHub Actions runs the suite on every push and pull request. [test_continuous_integration]


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать проектную документацию, демонстрирующую все действия и участников в системе. [OSPS-SA-01.01]
    Включите в документацию проекта проектные описания, объясняющие действия и участников. Участники включают любую подсистему или сущность, которая может повлиять на другой сегмент в системе. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    Design documentation covers the system's actions and actors: docs/architecture.md (https://github.com/NormB/sipnab/blob/main/docs/architecture.md) describes the run modes, the four answer surfaces (TUI, CLI, REST API, MCP), data flow from capture sources through parsing to outputs, the module map, threading and privilege model. Internals docs (https://sipnab.com/docs/internals/) and docs/design/ cover each subsystem.


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описания всех внешних программных интерфейсов выпущенных программных активов. [OSPS-SA-02.01]
    Документируйте все программные интерфейсы (API) выпущенных программных активов, объясняя, как пользователи могут взаимодействовать с программным обеспечением и какие данные ожидаются или производятся. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    sipnab exposes several external interfaces, each with reference documentation describing its inputs and outputs:
    • Command-line interface — every parameter and option is documented at https://sipnab.com/docs/cli/ (and via --help).
    • REST API — the URL/HTTP interface is documented at https://sipnab.com/docs/api/, with client examples at https://sipnab.com/docs/api-clients/.
    • MCP server — the tool surface (each tool's inputs and outputs) is documented at https://sipnab.com/docs/mcp/, with a step-by-step walkthrough at https://sipnab.com/docs/mcp-walkthrough/.
    These pages describe both inputs and outputs and are reachable from the documentation site's navigation, so the information is available without reading the source. A CI gate keeps the CLI reference and MCP tool docs synchronized with the code — every registered tool must have its own documented section, or the build fails. [documentation_interface]


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

    Когда проект выпустил релиз, проект ДОЛЖЕН провести оценку безопасности для понимания наиболее вероятных и значимых потенциальных проблем безопасности, которые могут возникнуть в программном обеспечении. [OSPS-SA-03.01]
    Проведение оценки безопасности информирует как членов проекта, так и конечных потребителей о том, что проект понимает, какие проблемы могут возникнуть в программном обеспечении. Понимание того, какие угрозы могут быть реализованы, помогает проекту управлять рисками и справляться с ними. Эта информация полезна для конечных потребителей для демонстрации компетентности в области безопасности и практик проекта. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    docs/threat-model.md is the project's security assessment: assets, trust boundaries, threats with the code that mitigates each, and residual risks: https://github.com/NormB/sipnab/blob/main/docs/threat-model.md


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

    Документация проекта ОБЯЗАНА включать политику скоординированного раскрытия информации об уязвимостях (CVD) с четко определенными сроками реагирования. [OSPS-VM-01.01]
    Создайте файл SECURITY.md в корневом каталоге, описывающий политику проекта для координированного раскрытия уязвимостей. Включите метод сообщения об уязвимостях. Установите ожидания относительно того, как проект будет реагировать и решать сообщенные проблемы.

    SECURITY.md describes how to report vulnerabilities.

    The GitHub issue tracker is a publicly available, permanently retained archive of reports and their responses, and it is full-text searchable via GitHub's issue search (is:issue, plus label/author/state filters). Every issue and every comment has a stable, individually-addressable URL. It already holds a searchable history — e.g. issues #226–229 with their triage and resolution comments — at https://github.com/NormB/sipnab/issues?q=is%3Aissue . [vulnerability_report_process]


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

    Документация проекта ОБЯЗАНА предоставлять способ конфиденциального сообщения об уязвимостях непосредственно контактам по вопросам безопасности в проекте. [OSPS-VM-03.01]
    Предоставьте средства для того, чтобы исследователи безопасности могли приватно сообщать об уязвимостях в проект. Это может быть специальный адрес электронной почты, веб-форма, специализированные инструменты системы контроля версий, адреса электронной почты контактов по безопасности или другие методы.

    https://github.com/NormB/sipnab/blob/main/SECURITY.md [vulnerability_report_private]


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

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

    The changelog flags security-relevant fixes in the entry that carries them. [release_notes_vulns]



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

Владелец анкеты на значок проекта: Norm Brandinger.
2026-08-02 14:39:34 UTC, последнее изменение сделано 2026-09-30 15:50:33 UTC. Последний раз условия для получения значка были выполнены 2026-08-06 13:59:14 UTC.