tpm2-tss

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

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

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

        

 Основы 13/13

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

    This repository hosts source code implementing the Trusted Computing Group's (TCG) TPM2 Software Stack (TSS). This stack consists of the following layers from top to bottom:

    • Feature API (FAPI) as described in the TCG Feature API (FAPI) Specification along with TCG TSS 2.0 JSON Data Types and Policy Language Specification This API is designed to be very high-level API, intended to make programming with the TPM as simple as possible. The API functions are exposed through a single library: libtss2-fapi.
    • Enhanced System API (ESAPI) as described in the TCG TSS 2.0 Enhanced System API (ESAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. In addition to SAPI, the ESAPI performs tracking of meta data for TPM object and automatic calculation of session based authorization and encryption values. Both the synchronous and asynchronous API are exposed through a single library: libtss2-esys.
    • System API (SAPI) as described in the TCG TSS 2.0 System Level API (SAPI) Specification This API is a 1-to-1 mapping of the TPM2 commands documented in Part 3 of the TPM2 specification. Additionally there are asynchronous versions of each command. These asynchronous variants may be useful for integration into event-driven programming environments. Both the synchronous and asynchronous API are exposed through a single library: libtss2-sys.
    • Marshaling/Unmarshaling (MU) as described in the TCG TSS 2.0 Marshaling/Unmarshaling API Specification This API provides a set of marshaling and unmarshaling functions for all data types define by the TPM library specification. The Marshaling/Unmarshaling API is exposed through a library called libtss2-mu.
    • TPM Command Transmission Interface (TCTI) as described in the TCG TSS 2.0 TPM Command Transmission Interface (TCTI) API Specification. This API provides a standard interface to transmit / receive TPM command / response buffers. It is expected that any number of libraries implementing the TCTI API will be implemented as a way to abstract various platform specific IPC mechanisms. Currently this repository provides several TCTI implementations: libtss2-tcti-device, libtss2-tcti-tbs (for Windows), libtss2-tcti-swtpm and libtss2-tcti-mssim. The former should be used for direct access to the TPM through the Linux kernel driver. The latter implements the protocol exposed by the Microsoft software TPM2 simulator.
    • The TCG TSS 2.0 Overview and Common Structures Specification forms the basis for all implementations in this project. NOTE: We deviate from this specification by increasing the value of TPM2_NUM_PCR_BANKS from 3 to 16 to ensure compatibility with TPM2 implementations that have enabled a larger than typical number of PCR banks. This larger value for TPM2_NUM_PCR_BANKS is expected to be included in a future revision of the specification.
    Какие языки программирования используются для реализации проекта?
  • Основная информация на веб-сайте проекта


    Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). [description_good]

    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]

    Non-trivial contribution file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md.



    В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]
  • Свободная лицензия

    Под какой/какими лицензией/ями выпускается проект?



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

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).



    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]

    The BSD-2-Clause license is approved by the Open Source Initiative (OSI).



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

    Non-trivial license location file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/LICENSE.


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


    Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. [documentation_basics]

    https://github.com/tpm2-software/tpm2-tss/blob/master/README.md - for General Overview https://github.com/tpm2-software/tpm2-tss/tree/master/doc - for General Documentation https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/



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

    https://github.com/tpm2-software/tpm2-tss/tree/master/man - man pages for the some of the components

    Full Doxygen Documentation for ESAPI/FAPI layer - https://tpm2-tss.readthedocs.io/en/latest/


  • Другое


    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]

    Given only https: URLs - feature by Github



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

    GitHub supports discussions on issues and pull requests. Also a searchable Mailing List https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/



    Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. [english]

    All documentation and communication is done in English. https://github.com/tpm2-software/tpm2-tss/blob/master/README.md



    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]


(Дополнительно) Какие другие пользователи имеют дополнительные права на редактирование этой записи значка? В настоящее время: []



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


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

    Repository on GitHub, which provides public git repositories with URLs.



    Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. [repo_interim]

    The complete development is done on github - every interim version, every change, every commit can be found on the repository.



    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • Уникальная нумерация версий


    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md



    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]

    Semantic versioning scheme is used and the release process is documented in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md



    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]

    Every release is tagged with a signed tag. Even release candidates are marked with a signed tag. https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md


  • Примечания к выпуску


    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]

    Non-trivial release notes file in repository: https://github.com/tpm2-software/tpm2-tss/blob/master/CHANGELOG.md. They are also included on the Release Page https://github.com/tpm2-software/tpm2-tss/releases



    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]

    Currently there are no known CVE entries - nevertheless, security relevant fixes are marked as such.


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


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

    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls



    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls



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

    Yes - Issues: 27 open, 656 fixed/closed - https://github.com/tpm2-software/tpm2-tss/issues / Pull Requests: 1 open, 1239 closed - https://github.com/tpm2-software/tpm2-tss/pulls Public Mailing List Archive: https://lists.01.org/hyperkitty/list/tpm2@lists.01.org/


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


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

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md - although brief, it is stated how to report security bugs.



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

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

    Yes - handled via Intel's Security Response Team, fixed and coordinated


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


    Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. [build]

    Each commit is automatically compiled using travis CI and AppVeyor. Each pull request is also automatically compiled travis CI and AppVeyor. https://travis-ci.org/tpm2-software/tpm2-tss and https://ci.appveyor.com/project/tpm2-software/tpm2-tss



    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]

    The build step of the software is based on the ubiquitous 'autotools' - known as "./configure && make && sudo make install" The software can also be built via a dockerfile.



    Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. [build_floss_tools]

    It relies on autotools for building. Other software/libraries are also covered by floss licenses.


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


    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]

    The tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss



    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]

    invocation via simple standard 'make check'



    ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. [test_most]

    Code Coverage by automated testsuite (via travis-ci) is automatically reported to coveralls and is at about 85+% https://coveralls.io/github/tpm2-software/tpm2-tss?branch=master



    ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). [test_continuous_integration]

    The tests are checked in under https://github.com/tpm2-software/tpm2-tss/tree/master/test and are perfomed on each commit using travis-ci. https://travis-ci.org/tpm2-software/tpm2-tss


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


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

    https://github.com/tpm2-software/tpm2-tss/blob/master/CONTRIBUTING.md This is also part of the review cycle and has been enforced multple times. But could be made clearer - TODO



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

    General Code Coverage is always improved and must be kept above 80%. New tests are also mentioned in the release notes.



    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]

    Part of the review cycle - but could be made clearer - TODO.


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


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

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).



    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]

    All compiler warnings are treated as errors ("-Werror"). https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L196

    Static Code Analyzer Warnings are adressed / reviewed on a regular basis https://scan.coverity.com/projects/tpm2-tss



    ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. [warnings_strict]

    A lot of the most common secure compile flags are enabled in configure per default. https://github.com/tpm2-software/tpm2-tss/blob/master/configure.ac#L192

    Also the code is compiled using gcc and clang to enable more warning coverage. In addition to that static code analysis is done via coverity and scan-build (via clang).


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


    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.



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

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The maintainers have several years of experience in developing secure software.


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

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

    Программное обеспечение, созданное проектом, ОБЯЗАНО использовать по умолчанию только публикуемые криптографические протоколы и алгоритмы, которые анализируются экспертами (если используются криптографические протоколы и алгоритмы). [crypto_published]

    The design of the specification of the software is performed within a Working Group within the Trusted Computing Group. Software development in the context of the TCG is always related to security and secure software. The cryptography depends on public cryptographic protocols and algorithms like TLS, sha, aes, rsa....



    Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. [crypto_call]

    It uses openssl or mbedtls as crypto-backends. It does not implement its own crypto.



    Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. [crypto_floss]

    It uses openssl or mbedtls as crypto-backends - both are FLOSS.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]

    The TPM specification currently still allows the usage of these algorithms/keysizes even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]

    tpm2-tss does not support any of these. Only SM3 may be an issue in the future here. Re-assessment will be done regularly - TODO.



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

    The TPM specification currently still allows the usage of these algorithms, even if better algorithms are available, so we must support them.

    However a new configure flag --disable-weakcrypto was introduced which prevents the usage of these algorithms as much as possible.



    В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. [crypto_pfs]

    tpm2-tss does not establish cryptographic sessions that qualify for perfect forward secrecy. The Auth-Sessions to the TPM would be prone to this issue, but those are bound to the hardware specification and the private keys are held inside SmartCards-like ICs aka TPMs. Nothing we can do here.



    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]

    tpm2-tss does not store passwords.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]
  • Доставка, защищенная от атак посредника (MITM)


    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Apart from that the software can also be downloaded via https or via the git protocol.



    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]

    Each release is performed with signed tags as described in https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md The signature verification is performed by github on the release page and the signature of the release packages can be retrieved via https.


  • Исправление обнародованных уязвимостей


    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]

    No publicly known vulnerabilities open.



    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

    No publicly known vulnerabilities open.


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


    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]

    No leaks.


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


    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]

    Coverity Scan and scan-build from clang/llvm.



    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]

    Covered by coverity.



    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]

    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

    Coverity is run before a release - https://github.com/tpm2-software/tpm2-tss/blob/master/RELEASE.md Scan-build is run on a per commit basis.


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


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

    Currently not implemented - code coverage is above 80% using the automatic testsuite.



    ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, C или C++). Если проект не создает программное обеспечение, написанное на небезопасном языке, выберите «неприменимо» (N/A). [dynamic_analysis_unsafe]

    Currently not implemented - code coverage is above 80% using the automatic testsuite including some boundary checks.

    Valgrind can be easily used with make check-valgrind



    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]

    Currently not implemented - code coverage is above 80% using the automatic testsuite



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

    Currently not implemented



Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 или более поздней (CC-BY-3.0+). Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "Peter Huewe and the OpenSSF Best Practices badge contributors".

Владелец анкеты на значок проекта: Peter Huewe.
2018-11-08 16:22:22 UTC, последнее изменение сделано 2020-11-24 13:31:51 UTC. Последний раз условия для получения значка были выполнены 2019-04-01 19:29:20 UTC.

Назад