obsidian-vault-intelligence

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The project follows an open development model where all 'interim' work is conducted via public feature branches and Pull Requests. Commits are pushed iteratively to the GitHub repository, allowing for collaborative review throughout the development cycle, well before a final release tag is created.

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

We use git tags, see also https://github.com/cybaea/obsidian-vault-intelligence/blob/main/.github/workflows/auto-tag.yml

Non-trivial release notes file in repository: https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CHANGELOG.md.

Our project uses a structured CHANGELOG.md following the 'Keep a Changelog' format. We have a policy of explicitly identifying security remediations using standard identifiers (CVE or GHSA IDs). For example, the 9.3.1 release explicitly identifies the remediation of GHSA-w5hq-g745-h8pq.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/cybaea/obsidian-vault-intelligence/blob/main/SECURITY.md. [osps_do_02_01]

https://github.com/cybaea/obsidian-vault-intelligence/issues

Most issues are feature enhancements. Bug reports are all fixed.

https://github.com/cybaea/obsidian-vault-intelligence/issues?q=is%3Aissue%20state%3Aclosed

1. Security Vulnerabilities: We use GitHub Security Advisories. Once a vulnerability is remediated and the advisory is published, it is permanently archived and searchable in the public GitHub Advisory Database.
2. General Bugs/Reports: We use GitHub Issues. All historical bug reports, feature requests, and their corresponding discussions (responses) are publicly archived and fully searchable via the GitHub interface. https://github.com/cybaea/obsidian-vault-intelligence/issues?q=is%3Aissue

The vulnerability reporting process is published both in the repository's SECURITY.md file and as a dedicated 'Security Policy' page on the official project documentation site (https://cybaea.github.io/obsidian-vault-intelligence/SECURITY). The process includes instructions for both public (GitHub Advisories) and private (email) reporting.

As above: The vulnerability reporting process is published both in the repository's SECURITY.md file and as a dedicated 'Security Policy' page on the official project documentation site (https://cybaea.github.io/obsidian-vault-intelligence/SECURITY). The process includes instructions for both public (GitHub Advisories) and private (email) reporting.

The project has not received any external vulnerability reports in the last 6 months. However, our published Security Policy commits to an acknowledgement of all reports within 48 hours, well within the 14-day requirement.

The project provides a fully automated build system using npm and esbuild (https://github.com/cybaea/obsidian-vault-intelligence/blob/main/esbuild.config.mjs). The command npm run build performs all necessary steps to compile the TypeScript source code, inline web workers, and bundle the final JavaScript artifact for use in Obsidian. The build process is documented in https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CONTRIBUTING.md and verified in the project's CI/CD pipeline (https://github.com/cybaea/obsidian-vault-intelligence/blob/main/.github/workflows/lint.yml).

The project uses npm (Node Package Manager) as its primary build orchestration tool and esbuild for bundling. Both are standard, open-source tools in the TypeScript ecosystem. The build is triggered via the industry-standard npm run build command.

The project uses npm (Node Package Manager) as its primary build orchestration tool and esbuild for bundling. Both are standard, open-source tools in the TypeScript ecosystem. The build is triggered via the industry-standard npm run build command."

The project uses the open-source Vitest testing framework. The test suite is fully automated and can be executed by anyone using the command npm run test. Execution instructions are provided in https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CONTRIBUTING.md, and the tests are automatically run as a mandatory status check for all Pull Requests via GitHub Actions.

Compliant; npm run test is the standard way for Typescript.

The project maintains an extensive automated test suite of over 280 tests covering core logic, worker-based processing, and service orchestration. We prioritize 'high-risk' code paths, including vector indexing and multi-threaded communication. Test coverage is verified on every commit, and we maintain a policy of adding new tests for every bug fix and feature to prevent regressions. https://github.com/cybaea/obsidian-vault-intelligence/tree/main/tests

The project uses GitHub Actions for Continuous Integration (documented in our https://github.com/cybaea/obsidian-vault-intelligence/tree/main/.github/workflows ) . To ensure builds are 100% deterministic and reproducible, our CI pipeline uses npm ci rather than npm install. This guarantees that automated tests are always run against the exact dependency tree defined in our lockfile, preventing 'it works on my machine' inconsistencies.

The project has a formal testing policy documented in CONTRIBUTING.md. This policy mandates that all major new functionality and bug fixes must include corresponding automated tests. This requirement is enforced by the project's CI pipeline, which blocks the integration of any code that fails existing or new tests. https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CONTRIBUTING.md

Evidence of adherence to our testing policy can be found in our recent major feature Pull Requests. For example, in PR #420 https://github.com/cybaea/obsidian-vault-intelligence/pull/420, which added custom HTTP header support, the developer simultaneously updated the project's testing mocks and documentation to ensure the new functionality was fully verifiable. Furthermore, our CI history publicly shows that every major change in the last 6 months has passed a comprehensive battery of over 280 automated tests before being merged into the main branch.

The project's policy for adding tests is formally documented in the CONTRIBUTING.md file, which serves as the primary instruction set for all contributors. The policy explicitly mandates that new functionality and bug fixes must be accompanied by automated tests, and it is positioned as a mandatory step in the submission and review process.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CONTRIBUTING.md

The project uses a dual-layer static analysis approach. First, we use the TypeScript compiler in 'strict' mode to enforce type safety and catch common logic errors during compilation. Second, we use ESLint with a highly strict configuration (including typescript-eslint and eslint-plugin-perfectionist) to enforce code quality and style standards. These checks are integrated into our CI/CD pipeline, and any violation (even a single warning) will block the build and prevent merging.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/tsconfig.json
• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/eslint.config.mts

The project has a zero-tolerance policy for code warnings. Our Continuous Integration pipeline is configured with --max-warnings 0 for our linting process, ensuring that any Pull Request with even a single identified warning is blocked from merging. This forces developers to either fix the issue or explicitly document it as a false positive using standard in-code annotations (which we only permit in test files for mocking purposes). As a result, the main branch is maintained in a warning-free state.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/.github/workflows/lint.yml
• https://github.com/cybaea/obsidian-vault-intelligence/actions

The project strives for maximum strictness in its build and linting configuration. We use the TypeScript compiler in 'strict' mode (see tsconfig.json), which enforces rigorous type safety across the entire codebase. Our ESLint configuration is likewise tuned to maximum strictness, utilizing specialized plugins like typescript-eslint and perfectionist to catch not just functional errors, but also maintainability issues. All such checks are enforced by our CI pipeline with a zero-warning failure policy, ensuring that the highest possible quality is maintained automatically.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/tsconfig.json
• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/eslint.config.mts

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

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)

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.

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.

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.

The project applies multiple static code analysis tools to every commit and production release. First, we use ESLint with deep-analysis rules (via typescript-eslint) to catch logic and quality errors. Second, we have integrated GitHub CodeQL (see .github/workflows/codeql.yml) to perform advanced semantic security analysis and data-flow tracking. These tools are automated via GitHub Actions and must pass successfully before any code is merged into the main branch or tagged for release.

In addition to GitHub Dependabot, we utilize the Renovate bot to proactively manage dependency updates. This ensures that our software stack and security analysis tools (like ESLint and TypeScript) are always current, allowing us to benefit from the latest security patches and analysis rules immediately upon their release. See https://github.com/cybaea/obsidian-vault-intelligence/issues/100

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/eslint.config.mts
• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/.github/workflows/codeql.yml

The project uses specialized static analysis tools specifically designed to identify common vulnerabilities. Our GitHub CodeQL implementation is configured with the security-extended query suite to detect complex data-flow vulnerabilities like path traversal and injection. Additionally, we use secretlint to prevent credential leakage and eslint-plugin-obsidianmd to catch security anti-patterns specific to the Obsidian plugin environment. This multi-layered approach ensures that we are looking for vulnerabilities at the language, security, and platform levels.

In addition to GitHub Dependabot, we utilize the Renovate bot to proactively manage dependency updates. This ensures that our software stack and security analysis tools (like ESLint and TypeScript) are always current, allowing us to benefit from the latest security patches and analysis rules immediately upon their release. See https://github.com/cybaea/obsidian-vault-intelligence/issues/100

The project ensures that all vulnerabilities identified by static analysis are remediated immediately. This is enforced by our CI pipeline: CodeQL and ESLint scans are mandatory status checks for every Pull Request. If a medium or higher severity vulnerability is detected, the integration is automatically blocked. This ensures that no such vulnerabilities can enter the main branch. Furthermore, we conduct periodic security audits to ensure that existing code remains compliant as new analysis rules are released.

See https://github.com/cybaea/obsidian-vault-intelligence/pull/425/checks for example.

Static analysis occurs automatically on every Pull Request and every push to the main branch via GitHub Actions. This ensures that every individual commit is analyzed before it is permanently integrated into the software. Additionally, we have scheduled CodeQL scans that run weekly to identify any new vulnerabilities that may have been discovered in existing code or dependencies since the last integration.

In addition to GitHub Dependabot, we utilize the Renovate bot to proactively manage dependency updates. This ensures that our software stack and security analysis tools (like ESLint and TypeScript) are always current, allowing us to benefit from the latest security patches and analysis rules immediately upon their release. See https://github.com/cybaea/obsidian-vault-intelligence/issues/100

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/.github/workflows/codeql.yml

The project utilizes its extensive automated test suite (over 280 tests) to perform dynamic analysis of the software. This suite is executed on every major production release and provides high branch coverage across all core logic, including vector indexing, scoring algorithms, and multi-threaded worker communication. Many of our tests are specifically designed to exercise the software with varied and edge-case inputs (e.g., malformed JSON, network failure states, and drifted text) to identify runtime defects. This comprehensive behavioral verification serves as our primary dynamic analysis tool.

While our aggregate project coverage is currently below 80% (due to untestable UI components), our core logic and security utilities (which handle all data validation and external communication) are subject to intense dynamic analysis via our automated test suite. Specifically, our security-critical modules like url.ts and masking.ts maintain a branch coverage of 85% to 93%. We use these high-coverage tests to dynamically verify the software's behavior against varied and edge-case inputs on every release.

The project is written exclusively in TypeScript, which is a memory-safe language. All execution occurs within the sandboxed and memory-managed environment of the Chromium V8 engine. The project does not produce any code in memory-unsafe languages like C or C++ that would require manual memory-safety analysis tools.

he project implements a comprehensive system of 'logic assertions' and 'invariant checks' using TypeScript Type Guards and the Zod validation library. These checks are pervasive in our data-handling and service-orchestration layers. During dynamic analysis (automated testing), these assertions ensure that any violation of expected data integrity or logic state results in an immediate failure, allowing for rapid fault detection. This approach provides the same benefit as C/C++ assertions but within a memory-safe, modern TypeScript environment.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/src/services/GeminiProvider.ts#L107
• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/src/services/mcp/StdioTransportStrategy.ts#L48-L60

The project ensures that all vulnerabilities identified through dynamic analysis (automated testing) are remediated immediately. Our comprehensive test suite of over 280 tests is a mandatory component of our Continuous Integration pipeline; any failure (which indicates a potential vulnerability or defect) automatically blocks code integration. Furthermore, our documented project policy (see CONTRIBUTING.md) requires that a regression test be added for every confirmed vulnerability or bug, ensuring that remediations are permanent and verifiable through subsequent dynamic analysis.

• https://github.com/cybaea/obsidian-vault-intelligence/blob/main/CONTRIBUTING.md#testing-policy