NetCoreApplicationTemplate

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia en la página de su proyecto. El estado de la insignia se ve así: El nivel de insignia para el proyecto 13645 es passing Aquí se explica cómo insertarla:
Puede mostrar el estado de su insignia insertando esto en su archivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13645/badge)](https://www.bestpractices.dev/projects/13645)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/13645"><img src="https://www.bestpractices.dev/projects/13645/badge"></a>


Estos son los criterios de nivel Básico. También puede ver los criterios de nivel Plata o Oro.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos 13/13 ●

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

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

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

  • Contenido básico del sitio web del proyecto


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE describir sucintamente qué hace el software (¿qué problema resuelve?). [description_good]
    Esto DEBE estar en un lenguaje que los usuarios potenciales puedan entender (por ejemplo, utiliza jerga mínima).

    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


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE proporcionar información sobre cómo: obtener, proporcionar comentarios (como informes de errores o mejoras), y contribuir al software. [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


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL requerida) [contribution]
    Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

    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


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBERÍA incluir los requisitos para las contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) [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


  • Licencia FLOSS


    ¡Suficiente para una insignia!

    El software producido por el proyecto DEBE ser publicado como FLOSS. [floss_license]
    FLOSS es software publicado de una manera que cumple con la Definición de Código Abierto o la Definición de Software Libre. Ejemplos de tales licencias incluyen CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Para nuestros propósitos, esto significa que la licencia DEBE ser: El software PUEDE también estar licenciado de otras maneras (por ejemplo, "GPLv2 o propietario" es aceptable).

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que cualquier licencia(s) requerida(s) para el software producido por el proyecto sea aprobada por la Open Source Initiative (OSI). [floss_license_osi]
    La OSI utiliza un proceso de aprobación riguroso para determinar qué licencias son OSS.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE publicar la(s) licencia(s) de sus resultados en una ubicación estándar en su repositorio de código fuente. (URL requerida) [license_location]
    Una convención es publicar la licencia como un archivo de nivel superior llamado LICENSE o COPYING, que PUEDE ser seguido por una extensión como ".txt" o ".md". Una convención alternativa es tener un directorio llamado LICENSES que contenga archivo(s) de licencia; estos archivos generalmente se nombran según su identificador de licencia SPDX seguido de una extensión de archivo apropiada, como se describe en la Especificación REUSE. Tenga en cuenta que este criterio es solo un requisito para el repositorio de código fuente. NO necesita incluir el archivo de licencia al generar algo desde el código fuente (como un ejecutable, paquete o contenedor). Por ejemplo, al generar un paquete R para el Comprehensive R Archive Network (CRAN), siga la práctica estándar de CRAN: si la licencia es una licencia estándar, use la especificación de licencia corta estándar (para evitar instalar otra copia del texto) y liste el archivo LICENSE en un archivo de exclusión como .Rbuildignore. De manera similar, al crear un paquete Debian, puede poner un enlace en el archivo de derechos de autor al texto de la licencia en /usr/share/common-licenses, y excluir el archivo de licencia del paquete creado (por ejemplo, eliminando el archivo después de llamar a dh_auto_install). Alentamos a incluir información de licencia legible por máquina en formatos generados cuando sea práctico.

    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


  • Documentación


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. [documentation_basics]
    Esta documentación debe estar en algún medio (como texto o video) que incluya: cómo instalarlo, cómo iniciarlo, cómo usarlo (posiblemente con un tutorial usando ejemplos), y cómo usarlo de manera segura (por ejemplo, qué hacer y qué no hacer) si eso es un tema apropiado para el software. La documentación de seguridad no necesita ser larga. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. Si el proyecto no produce software, elija "no aplicable" (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/


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación de referencia que describa la interfaz externa (tanto entrada como salida) del software producido por el proyecto. [documentation_interface]
    La documentación de una interfaz externa explica a un usuario final o desarrollador cómo usarla. Esto incluiría su interfaz de programación de aplicaciones (API) si el software tiene una. Si es una biblioteca, documente las clases/tipos principales y los métodos/funciones que se pueden llamar. Si es una aplicación web, defina su interfaz URL (a menudo su interfaz REST). Si es una interfaz de línea de comandos, documente los parámetros y opciones que admite. En muchos casos es mejor si la mayor parte de esta documentación se genera automáticamente, de modo que esta documentación permanezca sincronizada con el software a medida que cambia, pero esto no es obligatorio. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. La documentación PUEDE generarse automáticamente (donde sea práctico, esta es a menudo la mejor manera de hacerlo). La documentación de una interfaz REST puede generarse usando Swagger/OpenAPI. La documentación de la interfaz del código PUEDE generarse usando herramientas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), y Doxygen (muchos). Simplemente tener comentarios en el código de implementación no es suficiente para satisfacer este criterio; necesita haber una manera fácil de ver la información sin leer todo el código fuente. Si el proyecto no produce software, elija "no aplicable" (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


  • Otro


    ¡Suficiente para una insignia!

    Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. [sites_https]
    Esto requiere que la URL de la página de inicio del proyecto y la URL del repositorio de control de versiones comiencen con "https:", no "http:". Puede obtener certificados gratuitos de Let's Encrypt. Los proyectos PUEDEN implementar este criterio usando (por ejemplo) GitHub pages, GitLab pages, o SourceForge project pages. Si admite HTTP, le instamos a redirigir el tráfico HTTP a 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


    ¡Suficiente para una insignia!

    El proyecto DEBE tener uno o más mecanismos para la discusión (incluyendo cambios propuestos y problemas) que sean buscables, permitan que los mensajes y temas sean direccionables mediante URL, permitan que nuevas personas participen en algunas de las discusiones y no requieran la instalación del lado del cliente de software propietario. [discussion]
    Ejemplos de mecanismos aceptables incluyen listas de correo archivadas, discusiones de issues y pull requests de GitHub, Bugzilla, Mantis y Trac. Los mecanismos de discusión asíncrona (como IRC) son aceptables si cumplen con estos criterios; asegúrese de que haya un mecanismo de archivo direccionable por URL. JavaScript propietario, aunque desaconsejado, está permitido.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA proporcionar documentación en inglés y ser capaz de aceptar informes de errores y comentarios sobre el código en inglés. [english]
    El inglés es actualmente la lengua franca de la tecnología informática; el soporte del inglés aumenta el número de diferentes desarrolladores y revisores potenciales en todo el mundo. Un proyecto puede cumplir con este criterio incluso si el idioma principal de sus desarrolladores principales no es el inglés.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE ser mantenido. [maintained]
    Como mínimo, el proyecto debe intentar responder a informes de problemas y vulnerabilidades significativos. Un proyecto que está buscando activamente una insignia probablemente esté mantenido. Todos los proyectos y personas tienen recursos limitados, y los proyectos típicos deben rechazar algunos cambios propuestos, por lo que los recursos limitados y los rechazos de propuestas no indican por sí mismos un proyecto no mantenido.

    Cuando un proyecto sabe que ya no será mantenido, debe establecer este criterio como "No cumplido" y usar el o los mecanismos apropiados para indicar a otros que no está siendo mantenido. Por ejemplo, use "DEPRECATED" (OBSOLETO) como el primer encabezado de su README, agregue "DEPRECATED" cerca del comienzo de su página de inicio, agregue "DEPRECATED" al principio de la descripción del proyecto del repositorio de código, agregue una insignia no-maintenance-intended en su README y/o página de inicio, márquelo como obsoleto en cualquier repositorio de paquetes (por ejemplo, npm deprecate), y/o use el sistema de marcado del repositorio de código para archivarlo (por ejemplo, la configuración de "archive" de GitHub, el marcado "archived" de GitLab, el estado "readonly" de Gerrit, o el estado de proyecto "abandoned" de SourceForge). Se puede encontrar discusión adicional aquí.

    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


 Control de cambios 9/9 ●

  • Repositorio público para el control de versiones de código fuente


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un repositorio público para el control de versiones de código fuente que sea legible públicamente y tenga URL. [repo_public]
    La URL PUEDE ser la misma que la URL del proyecto. El proyecto PUEDE utilizar ramas privadas (no públicas) en casos específicos, mientras que el cambio no se divulga públicamente (por ejemplo, para corregir una vulnerabilidad antes de que se revele al público).

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

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


    ¡Suficiente para una insignia!

    El repositorio fuente del proyecto DEBE rastrear qué cambios se realizaron, quién realizó los cambios y cuándo se realizaron los cambios. [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/


    ¡Suficiente para una insignia!

    Para permitir la revisión colaborativa, el repositorio de código fuente del proyecto DEBE incluir versiones provisionales para revisión entre lanzamientos; NO DEBE incluir solo versiones finales. [repo_interim]
    Los proyectos PUEDEN optar por omitir versiones provisionales específicas de sus repositorios de código fuente públicos (por ejemplo, las que corrigen vulnerabilidades de seguridad específicas no públicas, pueden nunca ser lanzadas públicamente o incluyen material que no puede ser publicado legalmente y no están en el lanzamiento final).

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que se use software de control de versiones distribuido común (por ejemplo, git) para el repositorio de código fuente del proyecto. [repo_distributed]
    Git no se requiere específicamente y los proyectos pueden usar un software de control de versiones centralizado (como subversion) con justificación.

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


  • Numeración única de versión


    ¡Suficiente para una insignia!

    Los resultados del proyecto DEBEN tener un identificador de versión único para cada lanzamiento destinado a ser usado por los usuarios. [version_unique]
    Esto PUEDE cumplirse de diversas maneras, incluyendo IDs de commit (como el ID de commit de git o el ID de changeset de mercurial) o un número de versión (incluyendo números de versión que usan versionado semántico o esquemas basados en fechas como AAAAMMDD).

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que se use el formato de numeración de versiones Semantic Versioning (SemVer) o Calendar Versioning (CalVer) para los lanzamientos. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro. [version_semver]
    Los proyectos generalmente deberían preferir el formato que esperan sus usuarios, por ejemplo, porque es el formato normal usado por su ecosistema. Muchos ecosistemas prefieren SemVer, y SemVer es generalmente preferido para interfaces de programación de aplicaciones (APIs) y kits de desarrollo de software (SDKs). CalVer tiende a ser usado por proyectos que son grandes, tienen un número inusualmente grande de dependencias desarrolladas independientemente, tienen un alcance en constante cambio o son sensibles al tiempo. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro, porque incluir un nivel micro soporta ramas mantenidas simultáneamente cuando eso se vuelva necesario. Otros formatos de numeración de versiones pueden usarse como números de versión, incluyendo IDs de commit de git o IDs de changeset de mercurial, siempre que identifiquen versiones de manera única. Sin embargo, algunas alternativas (como los IDs de commit de git) pueden causar problemas como identificadores de lanzamiento, porque los usuarios pueden no ser capaces de determinar fácilmente si están actualizados. El formato de ID de versión puede no ser importante para identificar lanzamientos de software si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua).

    ¡Suficiente para una insignia!

    Se SUGIERE que los proyectos identifiquen cada lanzamiento dentro de su sistema de control de versiones. Por ejemplo, se SUGIERE que quienes usen git identifiquen cada lanzamiento usando etiquetas de 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


  • Notas de lanzamiento


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar, en cada lanzamiento, notas de lanzamiento que sean un resumen legible por humanos de los cambios principales en ese lanzamiento para ayudar a los usuarios a determinar si deben actualizar y cuál será el impacto de la actualización. Las notas de lanzamiento NO DEBEN ser la salida bruta de un registro de control de versiones (por ejemplo, los resultados del comando "git log" no son notas de lanzamiento). Los proyectos cuyos resultados no están destinados para su reutilización en múltiples ubicaciones (como el software para un solo sitio web o servicio) Y emplean entrega continua PUEDEN seleccionar "N/A". (URL requerida) [release_notes]
    Las notas de lanzamiento PUEDEN implementarse de diversas maneras. Muchos proyectos las proporcionan en un archivo llamado "NEWS", "CHANGELOG" o "ChangeLog", opcionalmente con extensiones como ".txt", ".md" o ".html". Históricamente el término "change log" significaba un registro de cada cambio, pero para cumplir con estos criterios lo que se necesita es un resumen legible por humanos. Las notas de lanzamiento PUEDEN proporcionarse mediante mecanismos del sistema de control de versiones como el flujo de trabajo 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


    ¡Suficiente para una insignia!

    Las notas de lanzamiento DEBEN identificar cada vulnerabilidad de tiempo de ejecución conocida públicamente que se corrigió en este lanzamiento y que ya tenía una asignación de CVE o similar cuando se creó el lanzamiento. Este criterio puede marcarse como no aplicable (N/A) si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica (por ejemplo, como suele ser cierto para las actualizaciones del kernel). Este criterio se aplica solo a los resultados del proyecto, no a sus dependencias. Si no hay notas de lanzamiento o no ha habido vulnerabilidades conocidas públicamente, elija N/A. [release_notes_vulns]
    Este criterio ayuda a los usuarios a determinar si una actualización dada corregirá una vulnerabilidad que es conocida públicamente, para ayudar a los usuarios a tomar una decisión informada sobre la actualización. Si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica en sus computadoras, pero en su lugar deben depender de uno o más intermediarios para realizar la actualización (como suele ser el caso de un kernel y software de bajo nivel que está entrelazado con un kernel), el proyecto puede elegir "no aplicable" (N/A) en su lugar, ya que esta información adicional no será útil para esos usuarios. De manera similar, un proyecto puede elegir N/A si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua). Este criterio solo se aplica a los resultados del proyecto, no a sus dependencias. Enumerar las vulnerabilidades de todas las dependencias transitivas de un proyecto se vuelve difícil de manejar a medida que aumentan y varían las dependencias, y es innecesario ya que las herramientas que examinan y rastrean dependencias pueden hacer esto de una manera más escalable.

    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.


 Informes 8/8 ●

  • Proceso de reporte de errores


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar un proceso para que los usuarios envíen informes de errores (por ejemplo, usando un rastreador de issues o una lista de correo). (URL requerida) [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


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA usar un rastreador de issues para rastrear problemas individuales. [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


    ¡Suficiente para una insignia!

    El proyecto DEBE reconocer la mayoría de los informes de errores enviados en los últimos 2-12 meses (inclusive); la respuesta no necesita incluir una solución. [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


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA responder a la mayoría (>50%) de las solicitudes de mejora en los últimos 2-12 meses (inclusive). [enhancement_responses]
    La respuesta PUEDE ser 'no' o una discusión sobre sus méritos. El objetivo es simplemente que haya alguna respuesta a algunas solicitudes, lo que indica que el proyecto todavía está activo. Para los propósitos de este criterio, los proyectos no necesitan contar solicitudes falsas (por ejemplo, de spammers o sistemas automatizados). Si un proyecto ya no está realizando mejoras, por favor seleccione "no cumplido" e incluya la URL que aclare esta situación a los usuarios. Si un proyecto tiende a estar abrumado por el número de solicitudes de mejora, por favor seleccione "no cumplido" y explique.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un archivo públicamente disponible para informes y respuestas para búsquedas posteriores. (URL requerida) [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


  • Proceso de informe de vulnerabilidad


    ¡Suficiente para una insignia!

    El proyecto DEBE publicar el proceso para informar vulnerabilidades en el sitio del proyecto. (URL requerida) [vulnerability_report_process]
    Los proyectos alojados en GitHub DEBERÍAN considerar habilitar el informe privado de una vulnerabilidad de seguridad. Los proyectos en GitLab DEBERÍAN considerar usar su capacidad para informar privadamente una vulnerabilidad. Los proyectos PUEDEN identificar una dirección de correo en https://PROJECTSITE/security, a menudo en la forma security@example.org. Este proceso de informe de vulnerabilidades PUEDE ser el mismo que su proceso de informe de errores. Los informes de vulnerabilidades PUEDEN ser siempre públicos, pero muchos proyectos tienen un mecanismo de informe de vulnerabilidades privado.

    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


    ¡Suficiente para una insignia!

    Si se admiten informes de vulnerabilidades privadas, el proyecto DEBE incluir cómo enviar la información de una manera que se mantenga privada. (URL requerida) [vulnerability_report_private]
    Los ejemplos incluyen un informe privado de defectos enviado en la web usando HTTPS (TLS) o un correo electrónico cifrado utilizando OpenPGP. Si los informes de vulnerabilidades son siempre públicos (por lo que nunca hay informes de vulnerabilidades privados), seleccione "no aplicable" (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


    ¡Suficiente para una insignia!

    El tiempo de respuesta inicial del proyecto para cualquier informe de vulnerabilidad recibido en los últimos 6 meses DEBE ser menor o igual a 14 días. [vulnerability_report_response]
    Si no ha habido vulnerabilidades reportadas en los últimos 6 meses, elija "no aplicable" (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.


 Calidad 13/13 ●

  • Sistema de construcción funcional


    ¡Suficiente para una insignia!

    Si el software generado por el proyecto requiere ser construido para su uso, el proyecto DEBE proporcionar un sistema de compilación que pueda satisfactoriamente reconstruir automáticamente el software a partir del código fuente. [build]
    Un sistema de construcción determina qué acciones deben ocurrir para reconstruir el software (y en qué orden), y luego realiza esos pasos. Por ejemplo, puede invocar un compilador para compilar el código fuente. Si se crea un ejecutable a partir del código fuente, debe ser posible modificar el código fuente del proyecto y luego generar un ejecutable actualizado con esas modificaciones. Si el software producido por el proyecto depende de bibliotecas externas, el sistema de construcción no necesita construir esas bibliotecas externas. Si no hay necesidad de construir nada para usar el software después de modificar su código fuente, seleccione "no aplicable" (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


    ¡Suficiente para una insignia!

    Se SUGIERE que se utilicen herramientas comunes para construir el software. [build_common_tools]
    Por ejemplo: Maven, Ant, cmake, autotools, make o rake.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA ser construible usando solo herramientas FLOSS. [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


  • Suite de pruebas automatizadas


    ¡Suficiente para una insignia!

    El proyecto DEBE usar al menos un conjunto de pruebas automatizado que se publique públicamente como FLOSS (este conjunto de pruebas puede mantenerse como un proyecto FLOSS separado). El proyecto DEBE mostrar claramente o documentar cómo ejecutar el conjunto(s) de pruebas (por ejemplo, a través de un script de integración continua (CI) o mediante documentación en archivos como BUILD.md, README.md, o CONTRIBUTING.md). [test]
    El proyecto PUEDE usar múltiples conjuntos de pruebas automatizadas (por ejemplo, uno que se ejecute rápidamente, versus otro que sea más exhaustivo pero requiera equipo especial). Hay muchos marcos de prueba y sistemas de soporte de pruebas disponibles, incluyendo Selenium (automatización de navegador web), 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


    ¡Suficiente para una insignia!

    Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. [test_invocation]
    Ejemplos: "make check", "mvn test" o "rake test".

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que el conjunto de pruebas cubra la mayoría (o idealmente todas) las ramas de código, campos de entrada y funcionalidad. [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


    ¡Suficiente para una insignia!

    Se SUGIERE que el proyecto implemente integración continua (donde el código nuevo o modificado se integra frecuentemente en un repositorio de código central y se ejecutan pruebas automatizadas sobre el resultado). [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


  • Pruebas de nueva funcionalidad


    ¡Suficiente para una insignia!

    El proyecto DEBE tener una política general (formal o no) de que a medida que se agrega nueva funcionalidad importante al software producido por el proyecto, se deben agregar pruebas de esa funcionalidad a un conjunto de pruebas automatizado. [test_policy]
    Siempre que exista una política, incluso de boca en boca, que diga que los desarrolladores deben agregar pruebas al conjunto de pruebas automatizado para la nueva funcionalidad importante, seleccione "Cumplido".

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE tener evidencia de que la test_policy para agregar pruebas se ha cumplido en los cambios más recientes importantes al software producido por el proyecto. [tests_are_added]
    La funcionalidad importante normalmente se mencionaría en las notas de lanzamiento. No se requiere perfección, simplemente evidencia de que las pruebas se están agregando típicamente en la práctica al conjunto de pruebas automatizado cuando se agrega nueva funcionalidad importante al software producido por el proyecto.

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que esta política sobre la adición de pruebas (vea test_policy) esté documentada en las instrucciones para propuestas de cambios. [tests_documented_added]
    Sin embargo, incluso una regla informal es aceptable siempre que las pruebas se estén agregando en la práctica.

    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


  • Banderas de advertencia


    ¡Suficiente para una insignia!

    El proyecto DEBE habilitar una o más marcas de advertencia del compilador, un modo de lenguaje "seguro", o usar una herramienta "linter" separada para buscar errores de calidad del código o errores simples comunes, si existe al menos una herramienta FLOSS que pueda implementar este criterio en el lenguaje seleccionado. [warnings]
    Ejemplos de marcas de advertencia del compilador incluyen gcc/clang "-Wall". Ejemplos de un modo de lenguaje "seguro" incluyen JavaScript "use strict" y perl5's "use warnings". Una herramienta "linter" separada es simplemente una herramienta que examina el código fuente para buscar errores de calidad del código o errores simples comunes. Estos se habilitan típicamente dentro del código fuente o instrucciones de compilación.

    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


    ¡Suficiente para una insignia!

    El proyecto DEBE abordar las advertencias. [warnings_fixed]
    Estas son las advertencias identificadas por la implementación del criterio warnings. El proyecto debe corregir las advertencias o marcarlas en el código fuente como falsos positivos. Idealmente no habría advertencias, pero un proyecto PUEDE aceptar algunas advertencias (típicamente menos de 1 advertencia por 100 líneas o menos de 10 advertencias).

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que los proyectos sean máximamente estrictos con las advertencias en el software producido por el proyecto, cuando sea práctico. [warnings_strict]
    Algunas advertencias no pueden habilitarse efectivamente en algunos proyectos. Lo que se necesita es evidencia de que el proyecto está esforzándose por habilitar marcas de advertencia donde pueda, de modo que los errores se detecten temprano.

    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


 Seguridad 16/16 ●

  • Conocimiento de desarrollo seguro


    ¡Suficiente para una insignia!

    El proyecto DEBE tener al menos un desarrollador principal que sepa cómo diseñar software seguro. (Ver 'detalles' para los requisitos exactos.) [know_secure_design]
    Esto requiere comprender los siguientes principios de diseño, incluyendo los 8 principios de Saltzer y Schroeder:
    • economía de mecanismo (mantener el diseño lo más simple y pequeño posible, por ejemplo, adoptando simplificaciones radicales)
    • valores predeterminados seguros ante fallas (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto)
    • mediación completa (cada acceso que pueda ser limitado debe ser verificado por autoridad y ser no evitable)
    • diseño abierto (los mecanismos de seguridad no deben depender de la ignorancia del atacante de su diseño, sino de información más fácilmente protegida y modificable como claves y contraseñas)
    • separación de privilegios (idealmente, el acceso a objetos importantes debe depender de más de una condición, de modo que vencer un sistema de protección no permita el acceso completo. Por ejemplo, la autenticación multifactor, como requerir tanto una contraseña como un token de hardware, es más fuerte que la autenticación de un solo factor)
    • mínimo privilegio (los procesos deben operar con el mínimo privilegio necesario)
    • mecanismo menos común (el diseño debe minimizar los mecanismos comunes a más de un usuario y de los que dependen todos los usuarios, por ejemplo, directorios para archivos temporales)
    • aceptabilidad psicológica (la interfaz humana debe estar diseñada para facilitar su uso - diseñar para "menos sorpresa" puede ayudar)
    • superficie de ataque limitada (la superficie de ataque - el conjunto de los diferentes puntos donde un atacante puede intentar entrar o extraer datos - debe ser limitada)
    • validación de entradas con listas de permitidos (las entradas típicamente deben verificarse para determinar si son válidas antes de aceptarse; esta validación debe usar listas de permitidos (que solo aceptan valores conocidos como buenos), no listas de denegados (que intentan listar valores conocidos como malos)).
    Un "desarrollador principal" en un proyecto es cualquier persona que esté familiarizada con la base de código del proyecto, se sienta cómoda haciendo cambios en él y sea reconocida como tal por la mayoría de los demás participantes en el proyecto. Un desarrollador principal típicamente haría una serie de contribuciones durante el año pasado (a través de código, documentación o respondiendo preguntas). Los desarrolladores típicamente serían considerados desarrolladores principales si iniciaron el proyecto (y no han dejado el proyecto hace más de tres años), tienen la opción de recibir información sobre un canal privado de reporte de vulnerabilidades (si existe uno), pueden aceptar commits en nombre del proyecto, o realizar versiones finales del software del proyecto. Si solo hay un desarrollador, ese individuo es el desarrollador principal. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir el diseño. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

    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


    ¡Suficiente para una insignia!

    Al menos uno de los desarrolladores principales del proyecto DEBE conocer tipos comunes de errores que conducen a vulnerabilidades en este tipo de software, así como al menos un método para contrarrestar o mitigar cada uno de ellos. [know_common_errors]
    Los ejemplos (dependiendo del tipo de software) incluyen inyección SQL, inyección de SO, desbordamiento de búfer clásico, cross-site scripting, falta de autenticación y falta de autorización. Ver el CWE/SANS top 25 o OWASP Top 10 para listas comúnmente usadas. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir errores de implementación comunes que conducen a vulnerabilidades. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

    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/


  • Use buenas prácticas criptográficas

    Tenga en cuenta que algunos programas de software no necesitan usar mecanismos criptográficos. Si su proyecto produce software que (1) incluye, activa o habilita funcionalidad de cifrado, y (2) podría ser liberado desde los Estados Unidos (EE.UU.) hacia fuera de los EE.UU. o a una persona que no sea ciudadana de los EE.UU., es posible que esté legalmente obligado a tomar algunos pasos adicionales. Típicamente esto solo implica enviar un correo electrónico. Para más información, consulte la sección de cifrado de Understanding Open Source Technology & US Export Controls.

    ¡Suficiente para una insignia!

    El software producido por el proyecto DEBE usar, por defecto, solo protocolos y algoritmos criptográficos que estén públicamente publicados y revisados por expertos (si se usan protocolos y algoritmos criptográficos). [crypto_published]
    Estos criterios criptográficos no siempre aplican porque algunos programas de software no necesitan usar capacidades criptográficas directamente.

    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


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto es una aplicación o una librería, y su propósito principal no es implementar criptografía, entonces DEBE SOLAMENTE invocar un software específicamente diseñado para implementar funciones criptográficas; NO DEBERÍA volver a implementar el suyo. [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


    ¡Suficiente para una insignia!

    Toda funcionalidad en el software producido por el proyecto que dependa de criptografía DEBE ser implementable usando FLOSS. [crypto_floss]
    Ver el Open Standards Requirement for Software by the 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


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN usar longitudes de clave predeterminadas que al menos cumplan con los requisitos mínimos de NIST hasta el año 2030 (como se declaró en 2012). DEBE ser posible configurar el software de modo que las longitudes de clave más pequeñas estén completamente deshabilitadas. [crypto_keylength]
    Estas longitudes mínimas de bits son: clave simétrica 112, módulo de factorización 2048, clave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 y hash 224 (el hash de contraseñas no está cubierto por esta longitud de bits, se puede encontrar más información sobre el hash de contraseñas en el criterio crypto_password_storage). Ver https://www.keylength.com para una comparación de recomendaciones de longitud de clave de varias organizaciones. El software PUEDE permitir longitudes de clave más pequeñas en algunas configuraciones (idealmente no lo haría, ya que esto permite ataques de degradación, pero las longitudes de clave más cortas a veces son necesarias para la interoperabilidad).

    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


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos rotos (por ejemplo, MD4, MD5, DES simple, RC4, Dual_EC_DRBG), o usar modos de cifrado que son inapropiados para el contexto, a menos que sean necesarios para implementar un protocolo interoperable (donde el protocolo implementado es la versión más reciente de ese estándar ampliamente soportada por el ecosistema de red, ese ecosistema requiere el uso de tal algoritmo o modo, y ese ecosistema no ofrece ninguna alternativa más segura). La documentación DEBE describir cualquier riesgo de seguridad relevante y cualquier mitigación conocida si estos algoritmos o modos rotos son necesarios para un protocolo interoperable. [crypto_working]
    El modo ECB casi nunca es apropiado porque revela bloques idénticos dentro del texto cifrado como lo demuestra el ECB penguin, y el modo CTR a menudo es inapropiado porque no realiza autenticación y causa duplicados si el estado de entrada se repite. En muchos casos es mejor elegir un modo de algoritmo de cifrado de bloque diseñado para combinar secreto y autenticación, por ejemplo, Galois/Counter Mode (GCM) y EAX. Los proyectos PUEDEN permitir a los usuarios habilitar mecanismos rotos (por ejemplo, durante la configuración) cuando sea necesario para la compatibilidad, pero entonces los usuarios saben que lo están haciendo.

    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


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBERÍAN depender de algoritmos o modos criptográficos con debilidades serias conocidas (por ejemplo, el algoritmo hash criptográfico SHA-1 o el modo CBC en SSH). [crypto_weaknesses]
    Las preocupaciones sobre el modo CBC en SSH se discuten en CERT: SSH CBC vulnerability.

    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


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBERÍAN implementar confidencialidad directa perfecta para protocolos de acuerdo de claves de modo que una clave de sesión derivada de un conjunto de claves a largo plazo no pueda ser comprometida si una de las claves a largo plazo es comprometida en el futuro. [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


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto causa el almacenamiento de contraseñas para la autenticación de usuarios externos, las contraseñas DEBEN almacenarse como hashes iterados con un salt por usuario mediante el uso de un algoritmo de estiramiento de claves (iterado) (por ejemplo, Argon2id, Bcrypt, Scrypt o PBKDF2). Ver también OWASP Password Storage Cheat Sheet. [crypto_password_storage]
    Este criterio se aplica solo cuando el software está forzando la autenticación de usuarios usando contraseñas para usuarios externos (también conocida como autenticación entrante), como aplicaciones web del lado del servidor. No se aplica en casos donde el software almacena contraseñas para autenticarse en otros sistemas (también conocida como autenticación saliente, por ejemplo, el software implementa un cliente para algún otro sistema), ya que al menos partes de ese software deben tener acceso a menudo a la contraseña sin hash.

    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


    ¡Suficiente para una insignia!

    Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN generar todas las claves criptográficas y nonces utilizando un generador de números aleatorios criptográficamente seguro, y NO DEBEN hacerlo usando generadores que son criptográficamente inseguros. [crypto_random]
    Un generador de números aleatorios criptográficamente seguro puede ser un generador de números aleatorios de hardware, o puede ser un generador de números pseudo-aleatorios criptográficamente seguro (CSPRNG) que usa un algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow o Fortuna. Ejemplos de llamadas a generadores de números aleatorios seguros incluyen java.security.SecureRandom de Java y window.crypto.getRandomValues de JavaScript. Ejemplos de llamadas a generadores de números aleatorios inseguros incluyen java.util.Random de Java y Math.random de 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


  • Entrega garantizada contra ataques de hombre en el medio (MITM)


    ¡Suficiente para una insignia!

    El proyecto DEBE usar un mecanismo de entrega que contrarreste los ataques MITM. Usar https o ssh+scp es aceptable. [delivery_mitm]
    Un mecanismo aún más fuerte es publicar el software con paquetes firmados digitalmente, ya que eso mitiga los ataques en el sistema de distribución, pero esto solo funciona si los usuarios pueden estar seguros de que las claves públicas para las firmas son correctas y si los usuarios realmente verificarán la firma.

    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


    ¡Suficiente para una insignia!

    Un hash criptográfico (por ejemplo, un sha1sum) NO DEBE recuperarse a través de http y usarse sin verificar una firma criptográfica. [delivery_unsigned]
    Estos "hash" se pueden modificar en tránsito.

    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


  • Vulnerabilidades públicamente conocidas corregidas


    ¡Suficiente para una insignia!

    NO DEBE haber vulnerabilidades sin parchar de severidad media o superior que hayan sido conocidas públicamente durante más de 60 días. [vulnerabilities_fixed_60_days]
    La vulnerabilidad debe ser parcheada y publicada por el proyecto mismo (los parches pueden desarrollarse en otro lugar). Una vulnerabilidad se convierte en conocida públicamente (para este propósito) una vez que tiene un CVE con información publicada públicamente sin muro de pago (reportada, por ejemplo, en la National Vulnerability Database) o cuando el proyecto ha sido informado y la información ha sido publicada al público (posiblemente por el proyecto). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Nota: esto significa que los usuarios podrían quedar vulnerables a todos los atacantes en todo el mundo durante hasta 60 días. Este criterio es a menudo mucho más fácil de cumplir que lo que Google recomienda en Rebooting responsible disclosure, porque Google recomienda que el período de 60 días comience cuando se notifica al proyecto incluso si el informe no es público. También tenga en cuenta que este criterio de insignia, como otros criterios, se aplica al proyecto individual. Algunos proyectos son parte de organizaciones paraguas más grandes o proyectos más grandes, posiblemente en múltiples capas, y muchos proyectos alimentan sus resultados a otras organizaciones y proyectos como parte de una cadena de suministro potencialmente compleja. Un proyecto individual a menudo no puede controlar el resto, pero un proyecto individual puede trabajar para publicar un parche de vulnerabilidad de manera oportuna. Por lo tanto, nos enfocamos únicamente en el tiempo de respuesta del proyecto individual. Una vez que un parche está disponible del proyecto individual, otros pueden determinar cómo lidiar con el parche (por ejemplo, pueden actualizar a la versión más nueva o pueden aplicar solo el parche como una solución seleccionada).

    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


    ¡Suficiente para una insignia!

    Los proyectos DEBERÍAN corregir todas las vulnerabilidades críticas rápidamente después de que se reporten. [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


  • Otros problemas de seguridad


    ¡Suficiente para una insignia!

    Los repositorios públicos NO DEBEN filtrar una credencial privada válida (por ejemplo, una contraseña funcional o una clave privada) que esté destinada a limitar el acceso público. [no_leaked_credentials]
    Un proyecto PUEDE filtrar credenciales de "muestra" para pruebas y bases de datos sin importancia, siempre que no estén destinadas a limitar el acceso público.

    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


 Análisis 8/8 ●

  • Análisis estático de código


    ¡Suficiente para una insignia!

    Al menos una herramienta de análisis de código estático (más allá de las advertencias del compilador y los modos de lenguaje "seguros") DEBE aplicarse a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento, si hay al menos una herramienta FLOSS que implemente este criterio en el lenguaje seleccionado. [static_analysis]
    Una herramienta de análisis de código estático examina el código de software (como código fuente, código intermedio o ejecutable) sin ejecutarlo con entradas específicas. Para los propósitos de este criterio, las advertencias del compilador y los modos de lenguaje "seguros" no cuentan como herramientas de análisis de código estático (estos típicamente evitan el análisis profundo porque la velocidad es vital). Algunas herramientas de análisis estático se centran en detectar defectos genéricos, otras se centran en encontrar tipos específicos de defectos (como vulnerabilidades), y algunas hacen una combinación. Ejemplos de tales herramientas de análisis de código estático incluyen cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (incluyendo FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, y HP Enterprise Fortify Static Code Analyzer. Se pueden encontrar listas más grandes de herramientas en lugares como la lista de Wikipedia de herramientas para análisis de código estático, información de OWASP sobre análisis de código estático, lista de NIST de analizadores de seguridad de código fuente, y lista de Wheeler de herramientas de análisis estático. Si no hay herramientas de análisis estático FLOSS disponibles para el(los) lenguaje(s) de implementación utilizado(s), puede seleccionar '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


    ¡Suficiente para una insignia!

    Se SUGIERE que al menos una de las herramientas de análisis estático utilizadas para el criterio static_analysis incluya reglas o enfoques para buscar vulnerabilidades comunes en el lenguaje o entorno analizado. [static_analysis_common_vulnerabilities]
    Las herramientas de análisis estático que están diseñadas específicamente para buscar vulnerabilidades comunes tienen más probabilidades de encontrarlas. Dicho esto, usar cualquier herramienta estática típicamente ayudará a encontrar algunos problemas, por lo que estamos sugiriendo pero no requiriendo esto para el nivel de insignia 'passing'.

    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


    ¡Suficiente para una insignia!

    Todas las vulnerabilidades explotables de severidad media y superior descubiertas con el análisis de código estático DEBEN corregirse de manera oportuna después de que se confirmen. [static_analysis_fixed]
    Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Tenga en cuenta que el criterio vulnerabilities_fixed_60_days requiere que todas esas vulnerabilidades se corrijan dentro de los 60 días de hacerse públicas.

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que el análisis de código fuente estático ocurra en cada commit o al menos diariamente. [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


  • Análisis dinámico de código


    ¡Suficiente para una insignia!

    Se SUGIERE que al menos una herramienta de análisis dinámico se aplique a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento. [dynamic_analysis]
    Una herramienta de análisis dinámico examina el software ejecutándolo con entradas específicas. Por ejemplo, el proyecto PUEDE usar una herramienta de fuzzing (por ejemplo, American Fuzzy Lop) o un escáner de aplicaciones web (por ejemplo, OWASP ZAP o w3af). En algunos casos, el proyecto OSS-Fuzz puede estar dispuesto a aplicar pruebas de fuzzing a su proyecto. Para los propósitos de este criterio, la herramienta de análisis dinámico necesita variar las entradas de alguna manera para buscar varios tipos de problemas o ser una suite de pruebas automatizada con al menos 80% de cobertura de ramas. La página de Wikipedia sobre análisis dinámico y la página de OWASP sobre fuzzing identifican algunas herramientas de análisis dinámico. La(s) herramienta(s) de análisis PUEDEN estar enfocadas en buscar vulnerabilidades de seguridad, pero esto no es obligatorio.

    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


    ¡Suficiente para una insignia!

    Se SUGIERE que si el software producido por el proyecto incluye software escrito usando un lenguaje no seguro en memoria (por ejemplo, C o C++), entonces se use rutinariamente al menos una herramienta dinámica (por ejemplo, un fuzzer o escáner de aplicaciones web) en combinación con un mecanismo para detectar problemas de seguridad de memoria como desbordamientos de búfer. Si el proyecto no produce software escrito en un lenguaje no seguro en memoria, elija "no aplicable" (N/A). [dynamic_analysis_unsafe]
    Ejemplos de mecanismos para detectar problemas de seguridad de memoria incluyen Address Sanitizer (ASAN) (disponible en GCC y LLVM), Memory Sanitizer, y valgrind. Otras herramientas potencialmente utilizadas incluyen thread sanitizer y undefined behavior sanitizer. También funcionarían aserciones generalizadas.

    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.


    ¡Suficiente para una insignia!

    Se SUGIERE que el proyecto use una configuración para al menos algún análisis dinámico (como pruebas o fuzzing) que habilite muchas aserciones. En muchos casos estas aserciones no deberían estar habilitadas en compilaciones de producción. [dynamic_analysis_enable_assertions]
    Este criterio no sugiere habilitar aserciones durante la producción; eso depende completamente del proyecto y sus usuarios decidir. El enfoque de este criterio es en cambio mejorar la detección de fallas durante el análisis dinámico antes del despliegue. Habilitar aserciones en el uso de producción es completamente diferente de habilitar aserciones durante el análisis dinámico (como las pruebas). En algunos casos, habilitar aserciones en el uso de producción es extremadamente imprudente (especialmente en componentes de alta integridad). Hay muchos argumentos contra habilitar aserciones en producción, por ejemplo, las bibliotecas no deberían bloquear a los llamadores, su presencia puede causar rechazo por las tiendas de aplicaciones, y/o activar una aserción en producción puede exponer datos privados como claves privadas. Tenga en cuenta que en muchas distribuciones de Linux NDEBUG no está definido, por lo que assert() de C/C++ estará habilitado por defecto para producción en esos entornos. Puede ser importante usar un mecanismo de aserción diferente o definir NDEBUG para producción en esos entornos.

    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


    ¡Suficiente para una insignia!

    Todas las vulnerabilidades explotables de severidad media y superior descubiertas con análisis de código dinámico DEBEN ser corregidas de manera oportuna después de que sean confirmadas. [dynamic_analysis_fixed]
    Si no está ejecutando análisis de código dinámico y por lo tanto no ha encontrado ninguna vulnerabilidad de esta manera, elija "no aplicable" (N/A). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente.

    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



Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Christopher D. Cavell y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Christopher D. Cavell.
Entrada creada el 2026-07-17 16:50:56 UTC, última actualización el 2026-07-17 17:40:24 UTC. Última obtención de la insignia de nivel básico el 2026-07-17 17:40:24 UTC.