obsidian-vault-intelligence

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í:

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/12733/badge)](https://www.bestpractices.dev/projects/12733)

o insertando esto en su HTML:

<a href="https://www.bestpractices.dev/projects/12733"><img src="https://www.bestpractices.dev/projects/12733/badge"></a>

Estos son los criterios de nivel

. También puede ver los criterios de nivel

.

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

Seguridad 16/16 ●

Conocimiento de desarrollo seguro

Cumplido

No cumplido

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 primary developer (Allan Engelhardt) has demonstrated expertise in secure design through the iterative hardening of the project. This is evidenced by the project's 'Security and Robustness' guide (devs/security-and-robustness.md), which explicitly discusses attack surface reduction and input validation. Recent project updates have implemented the principle of Least Privilege (hardened GitHub Action permissions), Separation of Privilege (migration to Obsidian SecretStorage for API keys), and Complete Mediation (unified file access through service facades). The developer's commitment to secure supply chain practices is further evidenced by the implementation of signed commits and automated vulnerability remediation (GHSA-w5hq-g745-h8pq).

https://github.com/cybaea/obsidian-vault-intelligence/blob/main/devs/security-and-robustness.md

If you (really) need more:

Evidence Mapping

Principle	Evidence in Our project
Economy of Mechanism	Our Service-Oriented Architecture (SOA) (defined in `devs/ARCHITECTURE_AND_STANDARDS.md`) keeps the design simple and modular,
	separating complex "AI Agent" logic from "Obsidian UI" logic.
Fail-Safe Defaults	The plugin follows a Local-First philosophy. It defaults to private, local processing unless the user explicitly configures a cloud
	provider.
Complete Mediation	All file and data access is mediated through the `VaultManager` and `PersistenceManager` services. Agents cannot write directly to the
	file system; they must use specialized tools that validate every path.
Open Design	Our security policy, architecture docs, and CI workflows are all public. We do not rely on "security by obscurity"; We rely on
	hardened GitHub permissions and signed commits.
Separation of Privilege	We recently migrated sensitive API keys to `SecretStorage` while keeping non-sensitive metadata in the standard `data.json`. This
	separates "secret" data from "configuration" data.
Least Privilege	We just hardened Our GitHub Actions with `permissions: read-all` at the top level, explicitly granting write access only to the
	specific jobs that need it (e.g., tagging or releases).
Least Common Mechanism	The plugin stores its internal index and shadow graph in a isolated `.vault-intelligence` directory, minimizing the shared state
	with other Obsidian plugins or core vault functionality.
Psychological Acceptability	Our UI follows Obsidian's "Least Astonishment" principles, using standard CSS variables and sentence case so that security settings
	(like API key entry) are intuitive and predictable for the user.
Limited Attack Surface	By moving to Local Embeddings (Transformers.js), We significantly reduced the attack surface by eliminating the need for external
	network calls to third-party APIs for core search functionality.
Input Validation (Allowlists)	Our `ToolRegistry` and `VaultManager` use Allowlists for file extensions (e.g., only processing `.md` files) and directory paths to
	prevent path traversal attacks.

Cumplido

No cumplido

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 has deep knowledge of common software vulnerabilities (OWASP Top 10 / SANS Top 25) and has implemented specific, documented mitigations for them within the plugin architecture. This is evidenced by our 'Security and Robustness' architectural guide (devs/security-and-robustness.md).

A standout example of our secure design is the MCP Trust Hashing mechanism. Recognizing that plugin configuration files are often synchronized across untrusted channels, we implemented a cryptographic SHA-256 fingerprinting system for all external tool configurations. If a configuration is altered (e.g., via a malicious sync), the plugin detects the hash mismatch and hard-blocks execution until a human developer performs a manual review and re-approval. This effectively mitigates Remote Code Execution (RCE) attacks originating from configuration tampering. -- https://github.com/cybaea/obsidian-vault-intelligence/blob/main/src/services/McpClientManager.ts#L94-L103

Other key examples include:

Command Injection: We strictly prohibit string-based shell execution (exec). Instead, we use child_process.spawn with explicit argument arrays, mathematically eliminating injection via shell metacharacters.
SSRF (Server-Side Request Forgery): We have implemented a custom URL firewall that uses a 'Default Deny' policy for local network IPs, loopback addresses, and cloud metadata endpoints (e.g., 169.254.169.254).
DNS Rebinding: We enforce HTTPS for all AI-initiated network requests, leveraging Chromium’s native TLS/SNI handshakes to neutralize rebinding attacks.
Path Traversal: All LLM-generated paths are normalized and stripped of leading slashes to prevent escaping the vault boundaries.
Regular Expression Denial of Service (ReDoS): All Markdown parsing regexes have been audited to eliminate deep nesting and unbounded repetition, preventing catastrophic backtracking.
Broken Access Control: We use Obsidian's native SecretStorage for API keys to prevent credential leakage through vault sync services.

These mitigations are not just theoretical; they are integrated into the project's core services and are verified by our automated test suite.

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.
Criterion [crypto_published]
Cumplido

No cumplido

N/A

?

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.
ll cryptographic operations in the project utilize publicly published and expert-reviewed algorithms. Specifically, we use SHA-256 for configuration integrity checks. Our implementation relies on the standard Web Crypto API (via the host environment's Chromium engine), which is a widely audited and industry-standard interface. We do not use any custom or proprietary cryptography.

Link 1: Use of Expert-Reviewed SHA-256
- Link: src/services/McpClientManager.ts#L94-L96
- Evidence: Shows the direct call to the native Web Crypto API using the publicly published SHA-256 algorithm.
Link 2: Use of Native OS Security Protocols
- Link: src/main.ts#L115-L125 (approximate lines where SecretStorage is handled)
- Evidence: Shows the integration with Obsidian's secretStorage, which leverages the operating system's native keychain (macOS Keychain, Windows Credential Manager, etc.) to handle encryption keys according to platform-standard security protocols.
Criterion [crypto_call]
Cumplido

No cumplido

N/A

?

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]}

The project follows the best practice of delegating all cryptographic operations to specialized, environment-provided security modules. We do not re-implement any cryptographic functions. Instead, we utilize the native Web Crypto API for configuration integrity and the host environment's SecretStorage (delegating to the OS keychain) for credential management. See links in previous answer.

Criterion [crypto_floss]
Cumplido

No cumplido

N/A

?

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 in the project is implemented using standard, open algorithms (like SHA-256) that are natively supported by 100% FLOSS environments. The plugin is fully functional on Linux using open-source implementations of the Web Crypto API and OS-level keyrings (e.g., libsecret). No proprietary hardware or closed-source libraries are required for the project's cryptographic features to operate.

Criterion [crypto_keylength]
Cumplido

No cumplido

N/A

?

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 project ensures all cryptographic keylengths and algorithms meet or exceed NIST requirements through 2030. We use SHA-256 for all data integrity checks, which provides 256 bits of security strength. For credential storage, we utilize the OS-native keychain via the SecretStorage API, which enforces high-bit-length encryption by default. Insecure algorithms with smaller keylengths (like MD5 or SHA-1) are not supported or implemented within the project.

Criterion [crypto_working]
Cumplido

No cumplido

N/A

?

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.

The project does not use any broken or deprecated cryptographic algorithms. We have standardized on SHA-256 for all integrity checks and delegate credential encryption to modern, audited OS-level subsystems (via SecretStorage). Legacy or broken algorithms like MD5, SHA-1, or DES are explicitly avoided, and no interoperability requirements exist that would force their use.

Criterion [crypto_weaknesses]
Cumplido

No cumplido

N/A

?

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 proactively avoids cryptographic algorithms and modes with known weaknesses. We have specifically selected SHA-256 for all data integrity and configuration hashing tasks, explicitly avoiding weaker alternatives like SHA-1. All our security-critical operations are built on modern, secure-by-default primitives provided by the Web Crypto API and the OS Keychain.

Criterion [crypto_pfs]
Cumplido

No cumplido

N/A

?

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]

The project is a local-first application and does not implement its own key agreement or communication protocols. All network communication with AI providers is conducted over standard HTTPS/TLS, which is managed by the host environment's Chromium engine. Therefore, Perfect Forward Secrecy is handled at the transport layer by the host, and is not applicable to the plugin's internal logic.

Criterion [crypto_password_storage]
Cumplido

No cumplido

N/A

?

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.

The project is a single-user local application and does not manage, store, or authenticate external user accounts or passwords. For the storage of third-party service credentials (API keys), we use the host environment's secure SecretStorage (OS Keychain) rather than a local database.

Criterion [crypto_random]
Cumplido

No cumplido

N/A

?

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.

The project delegates all sensitive random number generation to the host environment's native, cryptographically secure random number generators (CSPRNGs). We use the Web Crypto API (crypto.getRandomValues()) or the Node.js crypto module, both of which are backed by the operating system's entropy sources. We do not use insecure generators like Math.random() for security-critical operations.
Entrega garantizada contra ataques de hombre en el medio (MITM)

Criterion [delivery_mitm]
Cumplido

No cumplido

?

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.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Criterion [delivery_unsigned]
Cumplido

No cumplido

?

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 ensures all software and data delivery is secured against Man-in-the-Middle (MITM) attacks. We do not retrieve any code, dependencies, or cryptographic hashes over unencrypted HTTP. Our dependency management (via npm) and our asset retrieval (via Hugging Face) are conducted exclusively over HTTPS. Furthermore, we use a package-lock.json file containing SHA-512 hashes for all dependencies, which are automatically verified during our CI build process (npm ci)
Vulnerabilidades públicamente conocidas corregidas

Criterion [vulnerabilities_fixed_60_days]
Cumplido

No cumplido

?

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).

The project maintains a zero-tolerance policy for known vulnerabilities of medium or higher severity. We utilize automated scanning (GitHub Dependabot) to identify issues and have a track record of remediating them promptly, often within days of disclosure. For example, our 9.3.1 release explicitly addressed a moderate-severity vulnerability (GHSA-w5hq-g745-h8pq). A public audit of our package-lock.json via npm audit will confirm that no unpatched vulnerabilities with a CVSS score of 4.0 or higher currently exist in our production dependencies.
Criterion [vulnerabilities_critical_fixed]
Cumplido

No cumplido

?

Los proyectos DEBERÍAN corregir todas las vulnerabilidades críticas rápidamente después de que se reporten. ^{[vulnerabilities_critical_fixed]}
The project prioritizes the rapid remediation of all critical vulnerabilities. Through our integration with GitHub Dependabot and our automated CI/CD pipeline, we are able to identify, test, and release security patches almost immediately upon notification. Our typical response time for critical dependency updates is well under 7 days, and our public commit history demonstrates a consistent pattern of proactive dependency management and security hygiene.

Recent examples:
- PR #411: Remediated multiple vulnerabilities in under 1 minute.
- PR #413: Upgraded major toolchain dependencies (Vite 8) in 33 minutes.
- PR #424: Conducted comprehensive security hardening and vulnerability remediation (GHSA-w5hq-g745-h8pq) in 18 minutes.
Otros problemas de seguridad
Criterion [no_leaked_credentials]
Cumplido

No cumplido

?

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 project has a strict, automated policy against the leakage of private credentials. We utilize secretlint with the 'recommended' rule preset to scan all files in the repository for sensitive data (API keys, private keys, etc.). This scan is integrated into our npm run lint process and is a mandatory status check in our Continuous Integration pipeline. Any commit containing potentially sensitive credentials will fail the CI build and be blocked from merging. This automated defense was implemented as a permanent safeguard following a proactive security audit.

1. The Defensive Script
- Link: package.json (see lint:secrets)
- Evidence: The script "lint:secrets": "secretlint \"**/*\"" is part of the standard linting suite.
2. The Configuration
- Link: .secretlintrc.json
- Evidence: Shows you are using the @secretlint/secretlint-rule-preset-recommend, which catches a wide variety of tokens (AWS, Google, GitHub, etc.).
3. The Continuous Integration (CI) Enforcement

This is the most important link because it proves the check is mandatory.
- Link: .github/workflows/lint.yml
- Evidence: Shows that npm run lint (which triggers the secret scan) must pass on every single commit before code can be merged.

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 Allan Engelhardt y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Allan Engelhardt.
Entrada creada el 2026-05-02 20:34:44 UTC, última actualización el 2026-05-02 22:20:14 UTC. Última obtención de la insignia de nivel básico el 2026-05-02 22:20:14 UTC.

obsidian-vault-intelligence

Fundamentos 13/13 ●

General

Contenido básico del sitio web del proyecto

Licencia FLOSS

Documentación

Otro

Control de cambios 9/9 ●

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

Numeración única de versión

Notas de lanzamiento

Informes 8/8 ●

Proceso de reporte de errores

Proceso de informe de vulnerabilidad

Calidad 13/13 ●

Sistema de construcción funcional

Suite de pruebas automatizadas

Pruebas de nueva funcionalidad

Banderas de advertencia

Seguridad 16/16 ●

Conocimiento de desarrollo seguro

Evidence Mapping

Use buenas prácticas criptográficas

Link 1: Use of Expert-Reviewed SHA-256

Link 2: Use of Native OS Security Protocols

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

Vulnerabilidades públicamente conocidas corregidas

Otros problemas de seguridad

1. The Defensive Script

2. The Configuration

3. The Continuous Integration (CI) Enforcement

Análisis 8/8 ●

Análisis estático de código

Análisis dinámico de código