BadgeApp

安全 16/16 ●

安全开发知识

完成

不完整

该项目必须至少有一个主要开发人员知道如何设计安全软件。 ^{[know_secure_design]}

这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：

机制经济（保持设计简单实用，例如采用彻底简化）
故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
最小权限（进程应该以最少的权限运行）
最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
有限的攻击面（攻击面 —— 一组不同的入口，其中攻击者可以尝试输入或提取数据 —— 应该受到限制）
输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。

项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。

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.

完成

不完整

该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 ^{[know_common_errors]}

示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。

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.

使用基础的良好加密实践
请注意，某些软件不需要使用加密机制。
Criterion [crypto_published]
完成

不完整

N/A

?

项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 ^{[crypto_published]}
这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。
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]
完成

不完整

N/A

?

如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 ^{[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]
完成

不完整

N/A

?

项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 ^{[crypto_floss]}
请参阅OSI （开放源代码促进会）发布的软件开放标准需求。

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]
完成

不完整

N/A

?

项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 ^{[crypto_keylength]}
这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。

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]
完成

不完整

N/A

?

项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 ^{[crypto_working]}
在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。

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]
完成

不完整

N/A

?

由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 ^{[crypto_weaknesses]}
在 CERT：SSH CBC漏洞中讨论了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]
完成

不完整

N/A

?

项目产生的软件中的安全机制应该对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 ^[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]
完成

不完整

N/A

?

如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列。 ^{[crypto_password_storage]}
此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。

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]
完成

不完整

N/A

?

由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 ^{[crypto_random]}
密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的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.
安全交付防御中间人（MITM）的攻击

Criterion [delivery_mitm]
完成

不完整

?

该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 ^{[delivery_mitm]}
一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Criterion [delivery_unsigned]
完成

不完整

?

不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 ^{[delivery_unsigned]}
这些散列可以在传输过程中修改。

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)
修正公开的漏洞

Criterion [vulnerabilities_fixed_60_days]
完成

不完整

?

被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 ^{[vulnerabilities_fixed_60_days]}
该漏洞必须由项目本身修补和发布（修补程序可能在其他地方开发）。一旦漏洞具有公开发布的非付费信息的CVE（例如，在国家漏洞数据库）或项目已被通知，且信息已经发布给公众（可能是项目自己发布），则视为漏洞已经公众所知。如果其 CVSS 2.0 基本分数为4或更高，则漏洞是中等到高的严重性。注意：这意味着全世界的所有攻击者可能会对用户造成长达60天的伤害。这个标准通常比Google在重新启动负责任的披露中所推荐的容易得多。因为Google建议，如果报告不是公开的，那么当项目得到通知，甚至报告尚未公开时，60天的时间段就会开始。

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]
完成

不完整

?

项目在得到报告后应该迅速修复所有致命漏洞。 ^{[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.
其他安全问题
Criterion [no_leaked_credentials]
完成

不完整

?

公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 ^{[no_leaked_credentials]}
项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。
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.

该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Allan Engelhardt和OpenSSF最佳实践徽章贡献者。

obsidian-vault-intelligence

基本 13/13 ●

常规

基本项目网站内容

FLOSS许可证

文档

其他

变更控制 9/9 ●

公开的版本控制的源代码存储库

唯一版本编号

发行说明

报告 8/8 ●

错误报告流程

漏洞报告流程

质量 13/13 ●

可工作的构建系统

自动测试套件

新功能测试

警告标志

安全 16/16 ●

安全开发知识

Evidence Mapping

使用基础的良好加密实践

Link 1: Use of Expert-Reviewed SHA-256

Link 2: Use of Native OS Security Protocols

安全交付防御中间人（MITM）的攻击

修正公开的漏洞

其他安全问题

1. The Defensive Script

2. The Configuration

3. The Continuous Integration (CI) Enforcement

分析 8/8 ●

静态代码分析

动态代码分析