BadgeApp

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Erfüllt

Unerfüllt

Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) ^{[know_secure_design]}

Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:

Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
Fehlersichere Voreinstellungen (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Berechtigungen überprüft werden und darf nicht umgangen werden können)
Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter schützbare und änderbare Informationen wie Schlüssel und Passwörter)
Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z. B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
Psychologische Akzeptanz (Die menschliche Schnittstelle muss benutzerfreundlich entworfen werden - Design für "geringeste Überraschung" kann dabei helfen)
Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).

Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

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.

Erfüllt

Unerfüllt

Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. ^{[know_common_errors]}

Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

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.

Verwende grundlegend gute kryptographische Praktiken
Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.
Criterion [crypto_published]
Erfüllt

Unerfüllt

N/A

?

Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). ^{[crypto_published]}
Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.
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]
Erfüllt

Unerfüllt

N/A

?

Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. ^{[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]
Erfüllt

Unerfüllt

N/A

?

Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. ^{[crypto_floss]}
Siehe 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]
Erfüllt

Unerfüllt

N/A

?

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. ^{[crypto_keylength]}
Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, und hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe https://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

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]
Erfüllt

Unerfüllt

N/A

?

Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. ^{[crypto_working]}
Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR-Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z. B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

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]
Erfüllt

Unerfüllt

N/A

?

Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). ^{[crypto_weaknesses]}
Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

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]
Erfüllt

Unerfüllt

N/A

?

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. ^[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]
Erfüllt

Unerfüllt

N/A

?

Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Siehe auch OWASP Password Storage Cheat Sheet). ^{[crypto_password_storage]}
Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von externan Benutzern mit Passwörtern erzwingt (inbound authentication), wie z. B. bei serverseitigen Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (outbound authentication, z. B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

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]
Erfüllt

Unerfüllt

N/A

?

Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. ^{[crypto_random]}
Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Javas java.security.SecureRandom und JavaScripts window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Javas java.util.Random und JavaScripts Math.random.

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.
Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe

Criterion [delivery_mitm]
Erfüllt

Unerfüllt

?

Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. ^{[delivery_mitm]}
Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Criterion [delivery_unsigned]
Erfüllt

Unerfüllt

?

Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. ^{[delivery_unsigned]}
Diese Hashes könnten bei der Übermittlung verändert werden.

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)
Öffentlich bekannte Schwachstellen wurden behoben

Criterion [vulnerabilities_fixed_60_days]
Erfüllt

Unerfüllt

?

Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. ^{[vulnerabilities_fixed_60_days]}
Die Sicherheitslücke muss vom Projekt selbst gepatched und freigegeben werden (Patches dürfen woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen, nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird, selbst dann, wenn der Bericht nicht öffentlich ist. Beachten Sie auch, dass dieses Badge-Kriterium, wie andere Kriterien, auf einzelne Projekte zutrifft. Manche Projekte sind teil einer größeren Organisation oder eines größeren Projektes, möglicherweise als Teil mehrer Lagen, und manche Projekte füttern ihre Ergebnisse an andere Organisationen oder Projekte als teil einer möglicherweisen komplexen Lieferkette. Daher fokussieren wir uns auf die Antwortzeit einzelner Projekte. Wenn ein Projekt einen Patch bereitgestellt hat können andere entscheiden wie sie damit umgehen möchten (z. B. können sie auf eine neue Version upgraden oder nur einzelne Patches auswählen und einspielen).

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]
Erfüllt

Unerfüllt

?

Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. ^{[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.
Andere Sicherheitsissues
Criterion [no_leaked_credentials]
Erfüllt

Unerfüllt

?

Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. ^{[no_leaked_credentials]}
Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.
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.

Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Allan Engelhardt und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

obsidian-vault-intelligence

Grundlagen 13/13 ●

Allgemein

Grundlegende Informationen auf der Projektwebseite

FLOSS-Lizenz

Dokumentation

Andere

Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

Öffentliches Versionskontroll-Source-Repository

Einzigartige Versionsnummerierung

Versionshinweise

Berichterstattung 8/8 ●

Bug-Report-Prozess

Anfälligkeits-Prozessbericht

Qualität 13/13 ●

Produktivsystem

Automatisierte Test-Suite

Neue Funktionalitätsüberprüfung

Warnhinweise

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Evidence Mapping

Verwende grundlegend gute kryptographische Praktiken

Link 1: Use of Expert-Reviewed SHA-256

Link 2: Use of Native OS Security Protocols

Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe

Öffentlich bekannte Schwachstellen wurden behoben

Andere Sicherheitsissues

1. The Defensive Script

2. The Configuration

3. The Continuous Integration (CI) Enforcement

Analyse 8/8 ●

Statische Codeanalyse

Dynamische Codeanalyse