obsidian-vault-intelligence

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.

Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci :

Voici comment l'intégrer :

Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12733/badge)](https://www.bestpractices.dev/projects/12733)

ou en incorporant ceci dans votre HTML :

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

Ce sont les critères du niveau

. Vous pouvez également afficher les critères des niveaux

.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

Sécurité 16/16 ●

Connaissance du développement sécurisé

Atteint

Non atteint

Le projet DOIT avoir au moins un développeur principal qui sait comment concevoir un logiciel sécurisé. (Voir les « détails » pour les exigences exactes.) ^{[know_secure_design]}

Cela nécessite de comprendre les principes de conception suivants, y compris les 8 principes de Saltzer et Schroeder :

économie de moyens (maintenez la conception aussi simple et petite que pratique, par exemple en adoptant des simplifications conséquentes)
valeurs sûres par défaut (les décisions d'accès par défaut devraient être de refuser l'accès et l'installation des projets devrait être sécurisée par défaut)
médiation complète (tous les accès qui pourraient être limités doivent être vérifiés pour l'autorité et ne pas être contournables)
conception ouverte (les mécanismes de sécurité ne doivent pas dépendre de l'ignorance par l'attaquant de sa conception, mais plutôt d'informations plus facilement protégées et modifiées comme des clés et des mots de passe)
séparation des privilèges (idéalement, l'accès aux objets importants devrait dépendre de plus d'une condition, de sorte que la défaillance d'un système de protection n'autorisera pas l'accès complet. Par exemple, l'authentification multi-facteurs, comme l'exigence d'un mot de passe et d'un jeton matériel, est plus forte qu'une authentification à un seul facteur)
principe de plus faible privilège (les processus doivent fonctionner avec le minimum de privilège requis)
mécanisme de partage minimal (la conception devrait minimiser les mécanismes communs à plus d'un utilisateur et nécessaires à tous les utilisateurs, par exemple, les répertoires pour les fichiers temporaires)
acceptabilité psychologique (l'interface humaine doit être conçue pour faciliter l'utilisation - la conception pour « l'étonnement minimal » peut aider)
surface d'attaque limitée (la surface d'attaque - l'ensemble des différents points où un attaquant peut essayer d'entrer ou d'extraire des données - devrait être limitée)
validation d'entrée avec des listes blanches (les entrées devraient généralement être vérifiées pour déterminer si elles sont valides avant qu'elles ne soient acceptées ; cette validation devrait utiliser des listes blanches (qui n'acceptent que des bonnes valeurs connues), et non des listes noires (qui tentent de répertorier les valeurs mauvaises connues)).

Un « développeur principal » dans un projet est celui qui connaît la base de code du projet, est à l'aise pour faire des modifications et est reconnu comme tel par la plupart des autres participants au projet. Un développeur principal a effectué généralement un certain nombre de contributions au cours de l'année écoulée (du code, de la documentation ou des réponses aux questions). Des développeurs sont généralement considérés comme des développeurs principaux s'ils ont lancé le projet (et n'ont pas quitté le projet il y a plus de trois ans), ont la possibilité de recevoir des informations sur un canal privé de déclaration de vulnérabilités (s'il y en a un), peuvent accepter des contributions au nom du projet, ou effectuer les distributions finales du logiciel du projet. S'il n'y a qu'un seul développeur, cette personne est le développeur principal. De nombreux livres et cours sont disponibles pour vous aider à comprendre comment développer des logiciels plus sûrs et pour discuter de leur conception. Par exemple, le cours Bases du développement logiciel sécurisé est un ensemble gratuit de trois cours qui expliquent comment développer des logiciels plus sûrs (il est possible de le suivre gratuitement comme auditeur ; il est aussi possible de payer pour obtenir un certificat prouvant que vous avez compris les enseignements du cours).

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.

Atteint

Non atteint

Au moins l'un des principaux développeurs du projet DOIT connaître les types courants d'erreurs qui conduisent à des vulnérabilités dans ce genre de logiciel, ainsi qu'au moins une méthode pour contrer ou atténuer chacun d'eux. ^{[know_common_errors]}

Des exemples (selon le type de logiciel) incluent l'injection SQL, l'injection OS, le débordement mémoire classique, le cross-site scripting, l'authentification manquante et l'autorisation manquante. Voir CWE/SANS top 25 ou OWASP Top 10 pour les listes couramment utilisées. De nombreux livres et cours sont disponibles pour vous aider à comprendre comment développer des logiciels plus sûrs et discuter des erreurs courantes de mise en œuvre qui conduisent à des vulnérabilités. Par exemple, le cours Bases du développement logiciel sécurisé est un ensemble gratuit de trois cours qui expliquent comment développer des logiciels plus sûrs (gratuitement ; vous pouvez payer pour obtenir un certificat démontrant que vous avez assimilé le matériel présenté).

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.

Utiliser de bonnes pratiques de base de cryptographie
Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .
Criterion [crypto_published]
Atteint

Non atteint

N/A

?

Le logiciel produit par le projet DOIT utiliser, par défaut, uniquement les protocoles cryptographiques et les algorithmes publiés publiquement et revus par des experts (si des protocoles et algorithmes cryptographiques sont utilisés). ^{[crypto_published]}
Ces critères cryptographiques ne s'appliquent pas toujours car certains logiciels n'ont pas besoin d'utiliser directement de capacités cryptographiques.
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]
Atteint

Non atteint

N/A

?

Si le logiciel produit par le projet est une application ou une bibliothèque, et si son objectif principal n'est pas d'implémenter de la cryptographie, alors il DEVRAIT simplement appeler un logiciel spécialement conçu pour implémenter des fonctions cryptographiques ; il ne DEVRAIT PAS ré-implémenter les siennes. ^{[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]
Atteint

Non atteint

N/A

?

Toutes les fonctionnalités du logiciel produit par le projet qui dépendent de la cryptographie DOIVENT être réalisables à l'aide de FLOSS. ^{[crypto_floss]}
Consultez les Exigences des standards ouverts pour les logiciels par l'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]
Atteint

Non atteint

N/A

?

Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT utiliser des longueurs de clés par défaut qui satisfont au moins aux exigences minimales du NIST jusqu'à l'année 2030 (comme indiqué en 2012). Il DOIT être possible de configurer le logiciel afin que les plus petites longueurs de clés soient complètement désactivées. ^{[crypto_keylength]}
Ces longueurs de bit minimales sont : pour une clé symétrique 112, pour un modulo de factorisation 2048, pour une clé de logarithme discret 224, pour un groupe du logarithmique discret 2048, pour une courbe elliptique 224 et pour un hachage 224 (le hachage de mot de passe n'est pas couvert par cette longueur de bit, plus d'informations sur le hachage de mot de passe peuvent être trouvées dans le critère crypto_password_storage). Voir https://www.keylength.com pour une comparaison des recommandations sur les longueurs de clés de diverses organisations. Le logiciel PEUT permettre de plus petites longueurs de clés dans certaines configurations (idéalement non, car cela permet des attaques de dégradation, mais des longueurs de clés plus courtes sont parfois nécessaires pour l'interopérabilité).

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

Non atteint

N/A

?

Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes cryptographiques cassés (par exemple, MD4, MD5, DES unique, RC4, Dual_EC_DRBG) ou utiliser des modes de chiffrement inappropriés dans le contexte, sauf si ils sont nécessaires pour implémenter un protocole d'interopérabilité (où le protocole implémenté est la version la plus récente du standard supporté largement par l'écosystème du réseau, l'écosystème requiert l'utilisation de cet algorithme ou mode, et cet écosystème n'offre pas d'alternative plus sûre). La documentation DOIT décrire tous les risques de sécurité appropriés et les parades connues si ces algorithmes ou modes cassés sont nécessaires pour un protocole d'interopérabilité. ^{[crypto_working]}
Le mode ECB n'est presque jamais approprié car il révèle des blocs identiques dans le texte chiffré, comme le montre le pingouin ECB, et le mode CTR est souvent inapproprié car il n'effectue pas d'authentification et provoque des doublons si l'état d'entrée est dupliqué. Dans de nombreux cas, il est préférable de choisir un mode d'algorithme de chiffrement de bloc conçu pour combiner le secret et l'authentification, par exemple Galois/Counter Mode (GCM) et EAX. Les projets PEUVENT permettre aux utilisateurs d'activer les mécanismes cassés (par exemple pendant la configuration) si nécessaire pour la compatibilité, mais les utilisateurs savent alors qu'ils le font.

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

Non atteint

N/A

?

Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DEVRAIENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). ^{[crypto_weaknesses]}
Les préoccupations concernant le mode CBC en SSH sont discutées dans CERT : vulnérabilité SSH CBC.

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

Non atteint

N/A

?

Les mécanismes de sécurité dans le logiciel produit par le projet DEVRAIENT implémenter la confidentialité persistante pour les protocoles d'échange de clés afin qu'une clé de session dérivée d'un ensemble de clés à long terme ne soit pas compromise si l'une des clés à long terme est compromise dans le futur. ^[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]
Atteint

Non atteint

N/A

?

Si le logiciel produit par le projet entraîne la sauvegarde de mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être sauvegardés comme hachages itérés avec un salage par utilisateur en utilisant un algorithme d'étirement de clé (itéré) (par exemple Argon2id, Bcrypt, Scrypt, ou PBKDF2). Voir également le pense-bête sur le stockage des clés d'OWASP. ^{[crypto_password_storage]}
Ce critère s'applique uniquement lorsque le logiciel applique l'authentification des utilisateurs utilisant des mots de passe pour les utilisateurs extérieurs (càd l'authentification entrante), telles que des applications Web côté serveur. Il ne s'applique pas dans les cas où le logiciel sauvegarde des mots de passe pour l'authentification dans d'autres systèmes (càd l'authentification sortante, par exemple, le logiciel implémente un client pour un autre système), car au moins certaines parties de ce logiciel doivent avoir souvent accès au mot de passe en clair.

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

Non atteint

N/A

?

Les mécanismes de sécurité dans le logiciel produit par le projet DOIVENT générer toutes les clés cryptographiques et les nonces en utilisant un générateur de nombres aléatoires cryptographiquement sécurisé, et NE DOIVENT PAS le faire en utilisant des générateurs qui ne seraient pas cryptographiquement sécurisés. ^{[crypto_random]}
Un générateur de nombres aléatoires cryptographiquement sécurisé peut être un générateur de nombres aléatoires matériel ou un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG) utilisant un algorithme tel que Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Des exemples d'appels de générateurs de nombres aléatoires sûrs incluent java.security.SecureRandom en Java et window.crypto.getRandomValues de JavaScript. Des exemples d'appels de générateurs de nombres aléatoires non sûrs incluent java.util.Random en Java et Math.random en 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.
Livraison sécurisée contre les attaques man-in-the-middle (MITM)

Criterion [delivery_mitm]
Atteint

Non atteint

?

Le projet DOIT utiliser un mécanisme de livraison qui contrecarre les attaques MITM. L'utilisation de https ou ssh+scp est acceptable. ^{[delivery_mitm]}
Un mécanisme encore plus fort distribue le logiciel sous forme de paquetages signés numériquement, car cela atténue les attaques sur le système de distribution, mais cela ne fonctionne que si les utilisateurs peuvent être convaincus que les clés publiques pour les signatures sont correctes et si les utilisateurs vérifient la signature.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Criterion [delivery_unsigned]
Atteint

Non atteint

?

Un hachage cryptographique (par exemple, un sha1sum) NE DOIT PAS être récupéré par http et utilisé sans vérifier une signature cryptographique. ^{[delivery_unsigned]}
Ces hachages peuvent être modifiés en transit.

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)
Vulnérabilités publiquement identifiées et corrigées

Criterion [vulnerabilities_fixed_60_days]
Atteint

Non atteint

?

Il ne DOIT pas y avoir de vulnérabilités non corrigées de gravité moyenne ou supérieure connues publiquement depuis plus de 60 jours. ^{[vulnerabilities_fixed_60_days]}
La vulnérabilité doit être corrigée et diffusée par le projet lui-même (les correctifs peuvent être développés ailleurs). Une vulnérabilité devient publique (à cet effet) une fois qu'elle a un CVE avec des informations non payantes publiquement publiées (signalée, par exemple, dans la Base de données Nationale des Vulnérabilités) ou lorsque le projet a été informé et que l'information a été diffusée au public (éventuellement par le projet). Une vulnérabilité est considérée de gravité moyenne ou supérieure si son score de base qualitatif du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.Note : cela signifie que les utilisateurs peuvent être laissés vulnérables à tous les attaquants du monde entier jusqu'à 60 jours. Ce critère est souvent beaucoup plus facile à atteindre que ce que Google recommande dans son Redémarrage de la divulgation responsable, car Google recommande que la période de 60 jours commence lorsque le projet est notifié même si le rapport n'est pas public. Notez que ce critère de badge, comme d'autres critères, s'applique à un projet individuel. Certains projets font parti d'organisations ou de projets englobants, parfois à plusieurs niveaux, et de nombreux projets fournissent leurs résultats à d'autres organisations et projets au sein d'une chaîne approvisionnement potentiellement complexe. Un projet individuel ne peut souvent pas contrôler le reste, mais un projet individuel peut travailler à fournir un correctif de vulnérabilité à temps. Pour cette raison, nous nous concentrons seulement sur le temps de réponse des projets individuels. Une fois qu'un correctif est disponible de la part d'un projet individuel, les autres projets peuvent déterminer comment appliquer le correctif (par exemple, ils peuvent mettre à jour la dernière version ou ils peuvent appliquer uniquement le correctif).

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

Non atteint

?

Les projets DEVRAIENT corriger rapidement toutes les vulnérabilités critiques après leur signalement. ^{[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.
Autres problèmes de sécurité
Criterion [no_leaked_credentials]
Atteint

Non atteint

?

Les dépôts publics NE DOIVENT PAS fuiter un certificat privé valide (par exemple, un mot de passe ou une clé privée) qui est destiné à limiter l'accès public. ^{[no_leaked_credentials]}
Un projet PEUT fuiter des « échantillons » de certificats pour les tests et pour des bases de données sans importance, pour autant qu'ils ne soient pas destinés à limiter l'accès public.
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.

Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Allan Engelhardt et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Allan Engelhardt.
Soumission créée le 2026-05-02 20:34:44 UTC, dernière mise à jour le 2026-05-02 22:20:14 UTC. Le dernier badge obtenu l'a été le 2026-05-02 22:20:14 UTC.

obsidian-vault-intelligence

Notions de base 13/13 ●

Général

Contenu basique du site Web du projet

Licence FLOSS

Documentation

Autre

Contrôle des modifications 9/9 ●

Dépôt source public sous contrôle de version

Numérotation unique de la version

Notes de version

Compte-rendu 8/8 ●

Procédure de signalement des bogues

Processus de signalement de vulnérabilité

Qualité 13/13 ●

Système de construction opérationnel

Suite de tests automatisée

Nouveau test de fonctionnalité

Options d'avertissement

Sécurité 16/16 ●

Connaissance du développement sécurisé

Evidence Mapping

Utiliser de bonnes pratiques de base de cryptographie

Link 1: Use of Expert-Reviewed SHA-256

Link 2: Use of Native OS Security Protocols

Livraison sécurisée contre les attaques man-in-the-middle (MITM)

Vulnérabilités publiquement identifiées et corrigées

Autres problèmes de sécurité

1. The Defensive Script

2. The Configuration

3. The Continuous Integration (CI) Enforcement

Analyse 8/8 ●

Analyse statique de code

Analyse dynamique de code