NetCoreApplicationTemplate

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

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

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


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

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

        

 Основы 13/13 ●

  • Общая

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

    Reusable ASP.NET Core application template for secure, maintainable, production-ready .NET applications.

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

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


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

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

    The project README succinctly describes NetCoreApplicationTemplate as a reusable, production-oriented ASP.NET Core application template and identifies the security, authentication and authorization, observability, data access, health-check, error-handling, and CI capabilities that it provides.

    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#net-core-application-template


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

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

    The project provides source-cloning, build, Docker, NuGet installation, and dotnet new usage instructions in the README. SUPPORT.md directs users to GitHub Issues for bugs, documentation problems, packaging issues, and enhancement requests, and directs private vulnerability reports to SECURITY.md. CONTRIBUTING.md documents the issue, branch, pull-request, validation, and contribution process.

    Obtain:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#quick-start-from-source
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#install-and-use-the-template-package

    Feedback:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SUPPORT.md#support-channels
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Contribute:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md


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

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

    CONTRIBUTING.md documents the contribution process, including issue workflow, branch naming, commit messages, pull-request expectations, validation requirements, documentation expectations, security considerations, and maintainer review.

    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md


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

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

    CONTRIBUTING.md defines the requirements for acceptable contributions, including focused scope, secure-by-default behavior, maintainable configuration, test coverage, documentation updates, successful build and test validation, and formatting verification with dotnet format --verify-no-changes. The repository .editorconfig defines the applicable formatting, naming, code-quality, reliability, security, performance, and usage analyzer rules.

    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md#validation-expectations
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.editorconfig


  • Свободная лицензия


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

    ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. [floss_license]
    Свободное ПО (далее СПО) - это программное обеспечение, которое соответствует Определению Открытого ПО (официальный текст на англ.) или Определению Свободного Программного Обеспечения. Примеры таких лицензий включают CC0, MIT, BSD 2-Clause, BSD 3-Clause, Apache 2.0, Меньшая стандартная общественная лицензия GNU (LGPL) и Стандартная общественная лицензия GNU (GPL). Для наших целей это означает, что лицензия ОБЯЗАНА быть: ПО МОЖЕТ одновременно лицензироваться на других условиях (например, приемлема комбинация «GPLv2 или закрытая лицензия»).

    NetCoreApplicationTemplate is released under the MIT License, which grants permission to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software.

    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/LICENSE.txt


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

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

    NetCoreApplicationTemplate uses the MIT License, an Open Source Initiative-approved license.

    Project license:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/LICENSE.txt

    OSI license information:
    https://opensource.org/license/mit


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

    Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. (Требуется URL) [license_location]
    Например, в качестве файла верхнего уровня с именем LICENSE или COPYING. Имена файлов лицензии МОГУТ сопровождаться расширением, таким как «.txt» или «.md». Другим соглашением может быть наличие каталога с именем LICENSES, содержащего файлы лицензий; имена этих файлов обычно соответствуют SPDX-идентификатору лицензии, за которым следует соответствующее расширение файла, как описано в спецификации REUSE . Обратите внимание, что этот критерий является обязательным только для репозитория с исходным кодом. Вам НЕ нужно включать файл лицензии при генерации чего-либо из исходного кода (например, исполняемого файла, пакета или контейнера). Например, при создании пакета R для Comprehensive R Archive Network (CRAN) рекомендуется следовать стандартной практике CRAN: если лицензия является стандартной, используйте стандартную короткую спецификацию лицензии (чтобы избежать установки еще одной копии текста) и добавьте файл LICENSE в списке исключений, например .Rbuildignore. Аналогично, при создании пакета Debian вы можете поместить в файл copyright ссылку на текст лицензии в /usr/share/common-licenses и исключить файл лицензии из созданного пакета (например, удаляя файл после вызова dh_auto_install). Мы рекомендуем включать машиночитаемую информацию о лицензии в сгенерированных форматах, где это возможно.

    The complete MIT License is stored in LICENSE.txt at the root of the source repository, a standard license-file location.

    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/LICENSE.txt


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


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

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

    The project provides a README with installation, build, testing, Docker, package installation, template-generation, configuration, security, and usage guidance. It also publishes a structured DocFX documentation site covering setup, deployment, middleware, authentication, authorization, data access, API versioning, observability, health checks, and template packaging.

    README:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md

    Published documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/


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

    Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. [documentation_interface]
    Документация внешнего интерфейса объясняет конечному пользователю или разработчику, как его использовать. Это может включать в себя интерфейс прикладного программирования (API), если программное обеспечение его имеет. Если это библиотека, документируйте основные классы/типы и методы/функции, которые можно вызвать. Если это веб-приложение, определите его URL-интерфейс (часто его интерфейс REST). Если это интерфейс командной строки, документируйте параметры и настройки, которые он поддерживает. Во многих случаях лучше всего, если большая часть этой документации будет автоматически сгенерирована, чтобы эта документация была синхронизирована с программным обеспечением по мере его изменения, но это не требуется. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Документация МОЖЕТ быть автоматически сгенерирована (там, где это применимо, это часто наилучший способ создания документации). Документация интерфейса REST может быть сгенерирована с использованием Swagger/OpenAPI. Документация по интерфейсу кода МОЖЕТ быть сгенерирована с использованием таких инструментов, как JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) и Doxygen (многие языки). Просто иметь комментарии в коде реализации недостаточно для выполнения этого критерия; должен быть простой способ увидеть информацию без чтения всего исходного кода. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

    The project publishes generated DocFX API reference documentation for its public .NET types and members, including parameters, return types, and XML documentation. It also documents the consumer-facing template options, configuration sections, generated artifacts, routes, endpoint conventions, request versioning inputs, and response-version behavior.

    API reference:
    https://cdcavell.github.io/NetCoreApplicationTemplate/api/

    Public compatibility surface:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/public-surface-v1.html

    API versioning and request interface:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/api-versioning.html


  • Другое


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

    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]
    Для выполнения этого критерия требуется, чтобы URL домашней страницы проекта начинался с "https:", а не "http:". Вы можете получить бесплатные сертификаты от проекта Let's Encrypt. Проекты МОГУТ выполнить этот критерий, используя (например) GitHub Pages, GitLab Pages или проектные страницы SourceForge. Если вы поддерживаете HTTP, мы настоятельно рекомендуем перенаправить HTTP-трафик на HTTPS.

    The project repository, published documentation, package distribution, release artifacts, and issue-tracking URLs are all provided over HTTPS.

    Repository:
    https://github.com/cdcavell/NetCoreApplicationTemplate

    Documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/

    NuGet:
    https://www.nuget.org/packages/NetCoreApplicationTemplate

    Releases:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases


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

    Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. [discussion]
    Примерами приемлемых механизмов являются архивируемые списки рассылки, обсуждения в GitHub issues и pull requests, Bugzilla, Mantis и Trac. Асинхронные механизмы обсуждения (например, IRC) приемлемы, если они отвечают этим критериям; убедитесь, что есть механизм архивирования URL-адресов. Разрешено, хотя и не рекомендуется, использовать проприетарный JavaScript.

    The project uses GitHub Issues and Pull Requests for searchable, URL-addressable public discussion of defects, enhancements, proposed changes, and code contributions. New participants may open issues, submit pull requests, and comment through GitHub's web interface.

    Issues:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Pull requests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/pulls

    Support policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SUPPORT.md


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

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

    The project README, published documentation, contribution guide, support policy, security policy, source comments, issue templates, and pull-request workflow are written in English. The project accepts bug reports, feature requests, pull requests, and code-review comments in English through GitHub.

    Documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/

    Contributing:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md

    Support:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SUPPORT.md


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

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

    Если известно, что проект больше не будет поддерживаться, следует установить для этого критерия значение «Не соответствует» и использовать подходящие механизмы, чтобы указать другим, что он не поддерживается. Например, используйте “DEPRECATED” («УСТАРЕЛ») в качестве первого заголовка в файле README, добавьте “DEPRECATED” в начале его домашней страницы, добавьте “DEPRECATED” в начало описания проекта репозитория кода, добавьте значок об отсутствии поддержки в README проекта и/или домашнюю страницу, пометьте его как устаревший в любых репозиториях пакетов (напр., npm deprecate ) и/или используйте механизм, предоставленный репозиторием кода для его архивирования (например, параметр "archive" у GitHub или пометка "archive" у GitLab, статус «только для чтения» у Gerrit или статус «брошенного» проекта у SourceForge). Дополнительное обсуждение можно найти здесь .

    NetCoreApplicationTemplate is actively maintained. The repository receives ongoing code, security, testing, documentation, workflow, and dependency updates. It has a current stable release, automated CI and security analysis, documented support expectations, and an active issue and pull-request workflow.

    Repository activity:
    https://github.com/cdcavell/NetCoreApplicationTemplate/commits/main/

    Releases:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases

    Support policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SUPPORT.md


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

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


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

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

    The complete project source is maintained in a publicly readable GitHub repository using Git version control.

    Repository:
    https://github.com/cdcavell/NetCoreApplicationTemplate


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

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

    The project uses Git and GitHub. Its public commit history records each change, the contributor who authored or committed it, and the date and time it was made.

    Commit history:
    https://github.com/cdcavell/NetCoreApplicationTemplate/commits/main/


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

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

    The public repository contains ongoing development commits, branches, and pull requests between formal releases. These interim versions are available for review and are not limited to final release snapshots.

    Commit history:
    https://github.com/cdcavell/NetCoreApplicationTemplate/commits/main/

    Pull requests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/pulls

    Releases:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases


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

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

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


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


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

    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]
    Это МОЖНО выполнить различными способами, включая идентификаторы коммита (например, идентификатор коммита git или идентификатор набора изменений mercurial) или номер версии (включая номера версий, которые используют семантическое версионирование или схемы на основе даты, такие как YYYYMMDD).

    Each user-facing release has a unique version identifier. Version metadata is managed centrally for assemblies, NuGet packages, template packages, documentation, and GitHub releases.

    Current release:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases/tag/v2.3.1

    Release history:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases


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

    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]
    МОЖНО использовать в качестве номеров версий другие схемы нумерации версий, такие как идентификаторы коммитов (например, идентификатор коммита в git или идентификатор набора изменений в mercurial) или схемы на основе даты, такие как YYYYMMDD, поскольку они уникальны. Некоторые альтернативы могут вызвать трудности, поскольку пользователи могут быть не в состоянии легко определить, используют ли они последнюю версию. SemVer может оказаться менее полезным для идентификации версий программного обеспечения, если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-сервиса, который постоянно обновляется с помощью непрерывной доставки).

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

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

    Each GitHub release is identified in the Git repository using a version tag following the v<major>.<minor>.<patch> convention. For example, release 2.3.1 is identified by tag v2.3.1.

    Current tagged release:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases/tag/v2.3.1

    Repository tags:
    https://github.com/cdcavell/NetCoreApplicationTemplate/tags


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


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

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

    Each release includes human-readable release notes in CHANGELOG.md describing added, changed, fixed, and breaking behavior, along with upgrade or migration guidance and release-impact notes where applicable. GitHub Releases also provide version-specific release records.

    Changelog:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CHANGELOG.md

    GitHub Releases:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases


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

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

    No NCAT release has yet fixed a publicly known vulnerability in the project’s own runtime code that had a CVE or similar public vulnerability identifier when the release was created. Therefore, there are currently no project vulnerability identifiers to list in the release notes.

    If a future release fixes such a vulnerability, its release notes will identify the CVE or equivalent public identifier and summarize the affected versions and remediation.


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

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


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

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

    General bugs, documentation problems, packaging issues, and other reproducible defects may be reported through the project's public GitHub Issues tracker. Suspected security vulnerabilities use the separate private reporting process documented in SECURITY.md.

    Bug-reporting process:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SUPPORT.md#support-channels

    Issue tracker:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Security reports:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md


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

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

    The project uses GitHub Issues to track individual bugs, enhancements, documentation changes, packaging work, security-adjacent concerns, and other project tasks. Each issue has its own URL, status, history, assignees, comments, and related pull-request references.

    Issue tracker:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Documented issue workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md#issue-workflow


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

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

    At the time of this application, the project has acknowledged and completed the applicable issue reports submitted during the 2-to-12-month review window. The public tracker records assignment, status changes, closure, comments, and related implementation work.

    Applicable review-period issues:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues?q=is%3Aissue+created%3A2025-07-17..2026-05-17

    Open issues from that period:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues?q=is%3Aissue+is%3Aopen+created%3A2025-07-17..2026-05-17


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

    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]
    В качестве ответа МОЖЕТ быть «нет» или обсуждение выгод от данного улучшения. Цель состоит в том, чтобы по крайней мере на некоторые запросы был какой-то ответ, что указывает на то, что проект все еще жив. Для целей этого критерия не нужно учитывать поддельные запросы (например, от спамеров или автоматизированных систем). Если проект больше не принимает улучшения, выберите «не соответствует» и укажите URL, проясняющий ситуацию для пользователей. Если проект большую часть времени перегружен количеством запросов на улучшения, выберите «не cоответствует» и объясните.

    The project responds to and tracks enhancement requests through GitHub Issues. Applicable enhancement requests in the review period were implemented, closed as completed, superseded by later tracked work, or otherwise given a documented disposition.

    Issue archive:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Example enhancement response:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues/20


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

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

    GitHub Issues provides a publicly available, searchable archive of project reports and responses. Users can search and filter open and closed issues and review issue descriptions, comments, assignees, status changes, and linked pull requests.

    Public issue archive:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues

    Closed issue archive:
    https://github.com/cdcavell/NetCoreApplicationTemplate/issues?q=is%3Aissue+is%3Aclosed


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


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

    Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. (Требуется URL) [vulnerability_report_process]
    Например, четко обозначенный почтовый адрес на https://PROJECTSITE/security, часто в форме security@example.org. Процесс МОЖЕТ быть таким же, как и процесс для отчетов об ошибках. Отчеты об уязвимостях МОГУТ быть всегда общедоступными, но многие проекты имеют приватный механизм для отправки отчетов об уязвимостях.

    The project publishes a security policy describing how to report suspected vulnerabilities, what information to include, the supported release lines, disclosure expectations, and the security areas within project scope.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md


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

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

    The project supports confidential vulnerability reports through GitHub Private Vulnerability Reporting. Reporters are instructed not to open a public issue for suspected vulnerabilities.

    Private reporting form:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/advisories/new

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md#reporting-a-vulnerability


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

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

    No vulnerability reports were received by the project during the preceding six months, so there are no applicable initial response times to evaluate.


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

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


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

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

    The project provides a working .NET SDK/MSBuild build system that automatically restores dependencies and rebuilds the solution from source. The README documents the required commands, and the CI workflow performs locked dependency restore, Release build, formatting validation, automated tests, package creation, and generated-template smoke tests.

    Build instructions:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#quick-start-from-source

    CI build workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]
    Например, Maven, Ant, cmake, autotools, make, rake или devtools (R).

    The project uses the standard cross-platform .NET SDK command-line build tools: dotnet restore, dotnet build, dotnet test, dotnet pack, and MSBuild. The required SDK version is declared in global.json so developers and CI can use a consistent, widely supported toolchain.

    SDK configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/global.json

    Build workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

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

    NCAT can be rebuilt using only open-source tools. A local Linux or macOS build requires the .NET SDK and its included CLI/MSBuild toolchain; both the .NET SDK source and MSBuild are MIT-licensed. No proprietary IDE, Visual Studio installation, or proprietary build service is required.

    Build instructions:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#quick-start-from-source

    SDK configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/global.json


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


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

    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]
    Проект МОЖЕТ использовать несколько автоматизированных наборов тестов (например, один, который работает быстро, а другой - более тщательный, но требует специального оборудования). Существует множество каркасов (frameworks) и систем поддержки тестирования, включая Selenium (автоматизация веб-браузера), Junit (JVM, Java), RUnit (R), testthat (R).

    The project includes a publicly available automated test suite in the same MIT-licensed source repository. The README and contribution documentation explain how to restore, build, and run the tests, and the CI workflow runs them automatically.

    Test source:
    https://github.com/cdcavell/NetCoreApplicationTemplate/tree/main/tests

    Build and test instructions:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/README.md#quick-start-from-source

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]
    Например, «make check», «mvn test» или «rake test» (Ruby).

    The automated test suite is invoked using the standard .NET command:

    dotnet test --configuration Release

    This command is documented for contributors and is also used by the CI and release-validation workflows.

    Validation documentation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md#validation-expectations

    Build-quality documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/build-quality.html


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

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

    The project enforces a 75% global line-coverage threshold and additional file-level line and branch coverage thresholds for security-critical components. The suite includes unit tests, integration tests, generated-template smoke tests, cross-platform scaffold build tests, and property-based tests for varied input values.

    Coverage policy:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/build-quality.html#coverage-policy

    Published coverage report:
    https://cdcavell.github.io/NetCoreApplicationTemplate/coverage/

    Security-critical coverage configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/eng/security-critical-coverage.json


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

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

    The project uses GitHub Actions continuous integration. CI runs for pull requests targeting main, pushes to main, version tags, and manual dispatches. It restores dependencies, builds the solution, verifies formatting, runs automated tests, generates and enforces coverage, packages the template, and validates generated projects across Linux, Windows, and macOS.

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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


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

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

    The project’s contribution policy requires strong validation and automated test coverage for runtime behavior. Pull requests that add or materially change functionality are expected to include appropriate tests, document their validation, and pass the repository’s automated CI and coverage gates before merge.

    Contribution policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md

    Build and coverage policy:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/build-quality.html


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

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

    Recent significant functionality changes have included corresponding automated tests. Examples include the configurable unknown-client rate-limit fallback behavior, the EF Core save-processing pipeline and interceptor architecture, authentication and audit-storage extensions, and property-based persistence-normalization testing.

    Changelog:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CHANGELOG.md

    Automated tests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/tree/main/tests

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

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

    The testing policy is documented in the contribution and pull-request instructions. Pull requests must include a validation or testing section, required checks must pass before merge, and runtime code changes are expected to run the documented restore, build, and test commands.

    Contribution instructions:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/CONTRIBUTING.md#pull-request-expectations

    GitHub workflow:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/github-workflow.html#pull-request-expectations


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


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

    Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. [warnings]
    Примером предупреждающего флага компилятора может служить "-Wall" для gcc/clang. Примеры «безопасного» языкового режима включают «use strict» в JavaScript и «use warnings» в perl5. Отдельный инструмент «linter» - это просто инструмент, который исследует исходный код для поиска ошибок качества кода или типовых простых ошибок. Всё это обычно включается в исходный код или инструкции сборки.

    The project enables the .NET analyzers at the latest recommended analysis level, nullable reference-type analysis, code-style enforcement during builds, and repository-wide analyzer severity rules for reliability, security, performance, usage, code quality, and style. CI also runs dotnet format with --verify-no-changes.

    Build configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/Directory.Build.props

    Analyzer configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.editorconfig

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]
    Речь о предупреждениях, найденных при выполнении критерия warnings. Проект должен исправлять предупреждения или отмечать их в исходном коде как ложные срабатывания. В идеале не должно быть никаких предупреждений, но проект МОЖЕТ принимать существование каких-то предупреждений (обычно менее 1 предупреждения на 100 строк или менее 10 предупреждений).

    Compiler, analyzer, packaging, workflow, and formatting warnings are treated as actionable maintenance findings. The project fixes warnings in source or configuration and uses narrowly documented severity exceptions only where a rule would create disproportionate noise or conflict with an intentional framework pattern.

    Analyzer configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.editorconfig

    Commit history:
    https://github.com/cdcavell/NetCoreApplicationTemplate/commits/main/

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

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

    The project uses a production-oriented warning configuration that is strict where practical for a reusable ASP.NET Core template. It enables latest-recommended .NET analyzers, nullable analysis, build-time code-style enforcement, warning severity across the major analyzer categories, dotnet format verification, CodeQL analysis, and additional security-focused quality gates.

    The project intentionally does not globally set TreatWarningsAsErrors because compiler and analyzer changes across SDK servicing releases could otherwise create unnecessary downstream build failures for generated consumer applications. Actionable warnings are still reviewed and corrected.

    Build-quality policy:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/build-quality.html

    Build configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/Directory.Build.props

    Analyzer configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.editorconfig


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

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


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

    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]
    Это требует понимания следующих принципов проектирования, в том числе 8 принципов из Saltzer and Schroeder:
    • экономичность механизма (поддерживать дизайн ПО настолько простым и компактным, насколько практически возможно, например, с помощью массовых упрощений)
    • отказобезопасные значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации)
    • полное разграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей)
    • открытый дизайн (механизмы безопасности должны полагаться не на незнание их злоумышленником, а на данные типа ключей и паролей, которые проще защищать и менять)
    • разделение привилегий (в идеале доступ к важным объектам должен зависеть от более чем одного условия, так чтобы взлом одной системы защиты не приводил к полному доступу; напр., многофакторная аутентификация с требованием и пароля, и аппаратного токена сильнее однофакторной)
    • минимальные привилегии (процессы должны работать с минимальными привилегиями, необходимыми для выполнения ими своих функций)
    • наименьший общий механизм (дизайн должен минимизировать механизмы, общие для нескольких пользователей и следовательно зависящие от всех этих пользователей, например, каталоги для временных файлов)
    • психологическая приемлемость (интерфейс для человека должен быть спроектирован с учетом удобства использования - может быть полезным проектирование для «наименьшего удивления»)
    • ограничение периметра атаки (периметр атаки - множество разных точек, в которых злоумышленник может попытаться ввести или извлечь данные - должен быть ограничен)
    • проверка входных данных с помощью списков на допуск (входы обычно должны проверяться на корректность до их принятия; эта проверка должна использовать списки на допуск, содержащие только заведомо хорошие значения, а не списки на запрет, пытающиеся перечислить заведомо плохие значения).
    «Основной разработчик» в проекте - это любой, кто знаком с базой кода проекта, без затруднений может вносить в него изменения и признан таковым большинством других участников проекта. Основной разработчик, как правило, неоднократно вносит вклад в течение последнего года (через код, документацию или ответы на вопросы). Разработчики обычно считаются основными разработчиками, если это они начали проект (и не покинули проект более трех лет назад), имеют возможность получать информацию по закрытому каналу для отчетов об уязвимостях (если он есть), могут принимать коммиты от имени проекта или делать финальные выпуски программного обеспечения проекта. Если есть только один разработчик, этот человек является основным разработчиком. Есть много книг и курсов, помогающих понять, как разрабатывать более безопасное ПО, с обсуждением вопросов проектирования. Например, Secure Software Development Fundamentals - это бесплатный набор из трех курсов, объясняющих, как разрабатывать более безопасное ПО (бесплатный для обучения; за отдельную плату вы можете получить сертификат для подтверждения, что вы освоили материал).

    The project's primary developer and maintainer understands and applies secure software design principles, including economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability, limited attack surface, and allowlist-based input validation.

    These principles inform the project's secure-by-default configuration, middleware ordering, authorization architecture, narrowly scoped workflow permissions, production-safe error handling, security documentation, and review practices.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Security documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/authentication-hardening.html
    https://cdcavell.github.io/NetCoreApplicationTemplate/articles/production-deployment-checklist.html


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

    По крайней мере, один из основных разработчиков проекта ОБЯЗАН знать об общих видах ошибок, которые приводят к уязвимостям в этом виде программного обеспечения, а также по крайней мере одному методу противодействия или смягчения каждого из них. [know_common_errors]
    Примеры (в зависимости от типа ПО) включают внедрение SQL-кода (injection), внедрение на уровне ОС, классическое переполнение буфера, межсайтовый скриптинг, отсутствие проверки подлинности и отсутствие авторизации. Обычно используемые списки уязвимостей можно найти в CWE/SANS top 25 или OWASP Top 10. Есть много книг и обучающих курсов, помогающих понять, как разрабатывается безопасное программное обеспечение, и обсуждающих типичные ошибки в реализации, ведущие к уязвимостям. К примеру, Secure Software Development Fundamentals - это набор из трех курсов, объясняющих, как сделать разрабатываемое ПО более безопасным (бесплатный для прослушивания; за дополнительную плату вы можете получить справку о том, что прошли его).

    The project's primary developer understands common vulnerability classes relevant to ASP.NET Core applications and appropriate countermeasures, including:

    • SQL and command injection: parameterized data access, avoiding command construction from untrusted input, and input validation.
    • Cross-site scripting: contextual output encoding, safe templating, Content Security Policy, and security headers.
    • Cross-site request forgery: antiforgery protections, secure cookie settings, and appropriate SameSite policies.
    • Missing or broken authentication and authorization: deny-by-default policies, complete authorization checks, least privilege, and secure session handling.
    • Sensitive-data and secret exposure: external secret storage, restricted permissions, rotation, scanning, and production-safe logging.
    • Proxy and forwarded-header spoofing: explicitly trusted proxies and networks with correct middleware ordering.
    • Denial of service and abusive requests: rate limiting, concurrency controls, request-size limits, and bounded processing.
    • Information leakage through errors: centralized exception handling and production-safe Problem Details responses.
    • Vulnerable dependencies and build pipelines: dependency review, lock files, automated scanning, pinned workflow actions, and maintainer review.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Project documentation:
    https://cdcavell.github.io/NetCoreApplicationTemplate/


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

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

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

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

    The default scaffold uses established cryptographic mechanisms supplied by ASP.NET Core and .NET rather than private or project-specific algorithms. Cookie authentication is protected by ASP.NET Core Data Protection, whose default algorithms are AES-256-CBC for confidentiality and HMAC-SHA-256 for authentication. Optional external authentication is implemented through established cookie, OpenID Connect, SAML2, Microsoft, Google, and GitHub authentication handlers.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs

    Authentication hardening guidance:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/docs/articles/authentication-hardening.md


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

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

    NetCoreApplicationTemplate does not implement its own cryptographic primitives. It delegates authentication-cookie protection, protocol handling, token validation, certificate validation, and related cryptographic operations to ASP.NET Core, .NET, and the registered authentication-provider libraries.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs


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

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

    All cryptographic functionality required by the project can be implemented using the open-source .NET runtime and ASP.NET Core framework. The project does not require a proprietary cryptographic library or proprietary development environment.

    ASP.NET Core source:
    https://github.com/dotnet/aspnetcore

    .NET runtime source:
    https://github.com/dotnet/runtime


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

    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]
    Эти минимальные длины в битах перечислены далее: симметричный ключ - 112, модуль факторизации - 2048, дискретный логарифмический ключ - 224, дискретная логарифмическая группа - 2048, эллиптическая кривая - 224 и хеш - 224 (хеширование пароля не покрывается этой длиной, больше информации о хешировании пароля можно найти в описании критерия crypto_password_storage). См. http://www.keylength.com для сравнения рекомендаций по длинам криптографических ключей от различных организаций. Программное обеспечение МОЖЕТ допускать меньшие длины ключей в некоторых конфигурациях (в идеале не должно, поскольку это позволяет атаки через понижение длины ключа, но иногда требуется более короткая длина ключа для обеспечения взаимодействия с другими системами).

    The built-in authentication-cookie protection mechanism uses ASP.NET Core Data Protection. Its defaults use AES-256-CBC, HMAC-SHA-256, and a rotating 512-bit master key, exceeding the applicable NIST minimum key-length requirements.

    NCAT does not expose an application setting that downgrades these cryptographic key lengths. Consuming applications can explicitly lock Data Protection to the approved built-in algorithms, and production TLS protocols and cipher policy can be restricted through Kestrel, the reverse proxy, or operating-system security policy.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs

    Authentication hardening:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/docs/articles/authentication-hardening.md


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

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

    NetCoreApplicationTemplate does not implement or depend by default on broken cryptographic algorithms such as MD4, MD5, single DES, RC4, or Dual_EC_DRBG.

    Cryptographic operations used for authentication cookies and related framework security features are delegated to ASP.NET Core and .NET. ASP.NET Core Data Protection uses AES-256-CBC with HMAC-SHA-256 authentication by default rather than project-defined cryptography.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs

    Authentication hardening guidance:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/docs/articles/authentication-hardening.md


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

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

    The project's default security mechanisms do not depend on SHA-1, MD5, DES, RC4, unauthenticated encryption, CBC-mode SSH, or other cryptographic mechanisms with known serious weaknesses.

    ASP.NET Core Data Protection uses AES-256-CBC together with HMAC-SHA-256 authentication. It generates a per-operation key modifier and initialization vector, and the complete protected payload is authenticated by the HMAC. This is not the unauthenticated or SSH-specific CBC usage addressed by this criterion.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs


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

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

    NetCoreApplicationTemplate does not implement or directly configure a cryptographic key-agreement protocol. HTTPS/TLS key agreement is supplied by the hosting platform, Kestrel, web server, ingress controller, or reverse proxy selected by the consuming deployment.

    ASP.NET Core Data Protection protects application payloads and authentication cookies but is not a session key-agreement protocol. Therefore, perfect forward secrecy is not directly applicable to the project-owned cryptographic functionality.

    Production deployment guidance:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/docs/articles/authentication-hardening.md


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

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

    NetCoreApplicationTemplate does not implement external-user password registration, a password credential database, or password-based identity verification.

    The default Cookies scheme manages an authenticated session; it does not store or verify a user's password. Optional OpenID Connect, SAML2, Microsoft, Google, and GitHub providers delegate user authentication to external identity providers.

    Authentication documentation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/docs/articles/authentication.md


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

    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]
    Криптографически безопасный генератор случайных чисел может быть аппаратным генератором случайных чисел или криптографически безопасным генератором псевдослучайных чисел (CSPRNG), использующим такие алгоритмы как Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow или Fortuna. Примеры вызовов защищенных генераторов случайных чисел включают java.security.SecureRandom в Java и window.crypto.getRandomValues в JavaScript. Примеры вызовов небезопасных генераторов случайных чисел включают java.util.Random в Java и Math.random в JavaScript.

    NetCoreApplicationTemplate does not generate cryptographic keys, salts, initialization vectors, or nonces using application-defined random-number code. These operations are delegated to the cryptographic implementations in ASP.NET Core and .NET.

    ASP.NET Core Data Protection automatically generates and rotates its master keys and uses random per-operation key modifiers and initialization vectors or nonces for authenticated payload protection. No project-owned cryptographic operation uses System.Random or another non-cryptographic random generator.

    Authentication implementation:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/src/ProjectTemplate.Web/Authentication/Extensions/AuthenticationServiceExtensions.cs


  • Доставка, защищенная от атак посредника (MITM)


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

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

    Project source, releases, documentation, NuGet packages, container images, and dependency feeds are delivered through HTTPS-protected services.

    Repository and releases:
    https://github.com/cdcavell/NetCoreApplicationTemplate
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases

    NuGet package:
    https://www.nuget.org/packages/NetCoreApplicationTemplate

    Container registry:
    https://github.com/cdcavell/NetCoreApplicationTemplate/pkgs/container/netcoreapplicationtemplate


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

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

    The project does not retrieve cryptographic hashes over plaintext HTTP for use as software-delivery verification.

    Source code, packages, dependencies, release artifacts, and container images are obtained from HTTPS-protected GitHub, NuGet, and GitHub Container Registry endpoints. No repository-owned installation or publishing process uses an HTTP-delivered checksum as a substitute for authenticated transport or signature verification.

    NuGet source configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/nuget.config

    Release channels:
    https://github.com/cdcavell/NetCoreApplicationTemplate/releases


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


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

    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]
    Уязвимость должна быть исправлена ​​и выпущена самим проектом (патчи могут быть разработаны в другом месте). Уязвимость считается опубликованной (для цели данного критерия) после того, как она имеет CVE с описанием, бесплатно доступным для общественности, (например, в National Vulnerability Database) или когда проект был проинформирован, и информация была опубликована для общественности (возможно, самим проектом). Уязвимость имеет среднюю и высокую степень серьезности, если ее базовая оценка по CVSS 2.0 равна 4 или выше. Примечание. Это означает, что пользователи могут оставаться уязвимыми для всех злоумышленников по всему миру на срок до 60 дней. Этот критерий часто намного легче выполнить, чем рекомендует Google в Rebooting responsible disclosure, поскольку Google рекомендует, чтобы 60-дневный период начинался, когда проект был уведомлен, даже если отчет не является общедоступным.

    At the time of this assessment, NetCoreApplicationTemplate has no known unpatched vulnerability of medium or higher severity that has been publicly known for more than 60 days.

    The project monitors dependencies and source changes through Dependabot, dependency review, CodeQL analysis, locked dependency restoration, and maintainer review. Security fixes are applied to the current stable release line.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Security overview:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security

    Dependabot alerts:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/dependabot


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

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

    No critical vulnerabilities are currently known to remain unpatched in NetCoreApplicationTemplate.

    Critical vulnerability reports are prioritized for immediate private triage, remediation, validation, and release through the project's documented security-reporting and release processes.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Private vulnerability reporting:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/advisories/new


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


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

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

    The public repository does not contain any known valid password, token, private key, certificate, or other credential intended to restrict public access.

    Real credentials are prohibited from repository files, workflow files, examples, documentation, screenshots, and committed logs. Secrets used by deployments or workflows must be stored through GitHub Actions secrets, environment variables, user secrets, or an appropriate external secret store.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Secret scanning:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/secret-scanning


 Анализ 8/8 ●

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


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

    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]
    Средство анализа статического кода анализирует программный код (как исходный код, промежуточный код или исполняемый файл), не выполняя его с конкретными входами. Для целей этого критерия предупреждения компилятора и «безопасные» языковые режимы не считаются инструментами анализа статического кода (они обычно избегают глубокого анализа, поскольку скорость имеет жизненно важное значение). Примеры таких статических инструментов анализа кода включают cppcheck (C, C++), статический анализатор Clang (C, C++), SpotBugs (Java), FindBugs (Java; включая FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Анализатор качества Coverity, SonarQube, Codacy и статический анализатор кода HP Enterprise Fortify. Более крупные списки инструментов можно найти в таких местах, как Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers и Wheeler's list of static analysis tools. Если для используемого языка(ов) реализации нет доступных инструментов статического анализа на свободном ПО, выберите «неприменимо» (N/A).

    The project applies GitHub CodeQL static analysis to C# and GitHub Actions code before production releases. CodeQL runs through the CI workflow for pull requests targeting main, pushes to main, version tags matching v*.., and manual validation runs.

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml

    Code scanning results:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/code-scanning


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

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

    The project uses GitHub CodeQL security queries for C# and GitHub Actions. CodeQL analyzes data flow, control flow, untrusted input, injection paths, authentication and authorization mistakes, information exposure, workflow-security weaknesses, and other common vulnerability patterns.

    CodeQL configuration:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml

    Code scanning results:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/code-scanning


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

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

    At the time of this assessment, the project has no confirmed exploitable medium-or-higher severity CodeQL vulnerability that remains unresolved.

    Static-analysis findings are reviewed for applicability and severity. Confirmed exploitable findings of medium or higher severity are prioritized for remediation, testing, and release through the normal security and CI process.

    Code scanning results:
    https://github.com/cdcavell/NetCoreApplicationTemplate/security/code-scanning

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md


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

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

    CodeQL static analysis runs automatically for pull requests targeting main, including subsequent commits pushed to those pull requests, for pushes to main, and for version-tagged releases. This ensures proposed production changes are analyzed before merge and release.

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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


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

    ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . [dynamic_analysis]
    Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

    The project applies property-based dynamic analysis using FsCheck. The property tests execute project code with generated and varied string inputs, including empty values, whitespace, Unicode content, encoded characters, and unusual combinations.

    These tests run through the standard xUnit test suite in CI for pull requests targeting main, pushes to main, and version-tagged releases. This ensures proposed production releases are dynamically tested before release.

    Property-based tests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/tests/ProjectTemplate.Web.Tests/PersistenceStringPropertyTests.cs

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

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

    NetCoreApplicationTemplate's project-owned application and test code is written in managed C# targeting .NET. It does not include project-owned C, C++, or another memory-unsafe implementation language requiring AddressSanitizer, Valgrind, or similar buffer-overwrite detection.

    Therefore, the memory-unsafe-language dynamic-analysis criterion is not applicable.


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

    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]
    Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

    The automated test configuration executes extensive xUnit assertions and FsCheck property assertions during dynamic testing.

    The property-based tests use QuickCheckThrowOnFailure so a violated invariant immediately fails the test run. The broader unit, integration, middleware, authentication, authorization, persistence, configuration, and generated-template tests likewise use test assertions and fail CI when expected behavior is not satisfied.

    Property-based tests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/tests/ProjectTemplate.Web.Tests/PersistenceStringPropertyTests.cs

    Automated tests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/tree/main/tests

    CI workflow:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/.github/workflows/ci.yml


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

    Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. [dynamic_analysis_fixed]
    Если вы не используете динамический анализ кода и, следовательно, не обнаружили уязвимостей таким способом, выберите «неприменимо» (N/A). Степень серьезности уязвимости считается средней или выше, если уязвимость имеет среднюю или выше базовую оценку по Common Vulnerability Scoring System (CVSS). В версиях CVSS с 2.0 по 3.1 это соответствует оценке 4.0 и выше. Проекты могут использовать оценку CVSS опубликованную в любой широко используемой базе данных по уязвимостям (такой как National Vulnerability Database) используя самую новую версию CVSS доступную в этой базе данных. Вместо этого проекты могут сами вычислять серьезность используя последнюю версию CVSS на момент раскрытия уязвимости, если вводные для вычисления раскрываются вместе с публикацией уязвимости.

    At the time of this assessment, no confirmed exploitable medium-or-higher severity vulnerability discovered through the project's automated tests or property-based dynamic analysis remains unresolved.

    Any confirmed exploitable dynamic-analysis finding of medium or higher severity is treated as a security defect and is prioritized for remediation, regression testing, and release through the documented security and CI process.

    Security policy:
    https://github.com/cdcavell/NetCoreApplicationTemplate/blob/main/SECURITY.md

    Automated tests:
    https://github.com/cdcavell/NetCoreApplicationTemplate/tree/main/tests



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

Владелец анкеты на значок проекта: Christopher D. Cavell.
2026-07-17 16:50:56 UTC, последнее изменение сделано 2026-07-17 17:40:24 UTC. Последний раз условия для получения значка были выполнены 2026-07-17 17:40:24 UTC.