spector

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.

https://github.com/spectrayan/spector/commits/main - All development commits land publicly on main and feature branches continuously. There are currently 85 public commits on main since the last release tag (v0.1.0-alpha.2), all available for community review. Releases are tagged from an already-public commit history — the repo never contains only release commits.

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

Every release is identified in the Git repository using standard SemVer annotated tags (e.g., v0.1.0-alpha.1, v0.1.0-alpha.2) and mirrored to official GitHub Releases. https://github.com/spectrayan/spector/releases or https://github.com/spectrayan/spector/tags

Non-trivial release notes file in repository: https://github.com/spectrayan/spector/blob/main/CHANGELOG.md.

The project has had no publicly known run-time vulnerabilities or CVE assignments. Future releases that fix any CVE-assigned vulnerabilities will document them in release notes per our security policy (SECURITY.md).

Non-trivial SECURITY[.md] file found file in repository: https://github.com/spectrayan/spector/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues to track all bug reports, feature requests, and architectural tasks, with dedicated templates for bug reports, feature requests, and performance investigations. https://github.com/spectrayan/spector/issues

100% of bug reports submitted over the last 2–12 months have been acknowledged and triaged by maintainers, with the vast majority addressed and closed via linked pull requests. https://github.com/spectrayan/spector/issues

The project actively reviews, responds to, and implements community and team enhancement requests, with well over 50% addressed and resolved through linked PRs and milestone releases over the past 2–12 months. https://github.com/spectrayan/spector/issues

All bug reports, enhancement requests, triage decisions, and maintainer responses are permanently archived and publicly searchable in the project's GitHub Issues tracker and GitHub Discussions. https://github.com/spectrayan/spector/issues

The vulnerability reporting process is published in SECURITY.md in the project root, providing instructions for confidential reporting via GitHub Private Vulnerability Reporting (PVR) and security@spectrayan.com, with a defined 24-hour response SLA. https://github.com/spectrayan/spector/blob/main/SECURITY.md

Private vulnerability reports are supported via GitHub Private Vulnerability Reporting (creating a confidential draft accessible only to maintainers and reporter) and via dedicated email to security@spectrayan.com, as documented in SECURITY.md under 'Reporting a Vulnerability'. https://github.com/spectrayan/spector/blob/main/SECURITY.md#reporting-a-vulnerability

No external vulnerability reports were received in the last 6 months. The project's published security policy (SECURITY.md) establishes a mandatory initial acknowledgment SLA of 24 to 48 hours (and maximum 5 business days for low severity), well within the 14-day requirement. Maintainers monitor the private reporting channels continuously. https://github.com/spectrayan/spector/blob/main/SECURITY.md#response-timeline--severity-slas

Non-trivial build file in repository: https://github.com/spectrayan/spector/blob/main/pom.xml.

Non-trivial build file in repository: https://github.com/spectrayan/spector/blob/main/pom.xml.

The project is buildable entirely using FLOSS tools: OpenJDK 25 (GPLv2+CE), Apache Maven (Apache 2.0), and Node.js/npm (MIT/Artistic 2.0). Zero proprietary software, commercial tools, or non-FLOSS dependencies are required for building or testing. https://github.com/spectrayan/spector/blob/main/AGENTS.md#prerequisites

The project uses FLOSS test frameworks (JUnit 5 and jqwik under EPL-2.0, AssertJ under Apache 2.0). Detailed instructions for running the automated unit, integration, and property test suites are documented in CONTRIBUTING.md under 'Testing Expectations' (e.g., mvn test), and executed automatically in the GitHub Actions CI pipeline (.github/workflows/ci.yml). https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#testing-expectations

The test suite is invoked using standard language conventions: mvn test for the Java Maven reactor, npm test for TypeScript modules, and pytest for the Python SDK. https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#running-the-test-suites

The test suite implements a 4-tier testing methodology covering happy paths, edge cases, integration flows, and jqwik property-based tests for randomized branch and input coverage, tracked using JaCoCo. https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#testing-expectations

Continuous integration is implemented using GitHub Actions (.github/workflows/ci.yml). Automated builds, multi-architecture matrix tests (x86_64 and aarch64), license checks, and property tests run on every pull request and commit to main. https://github.com/spectrayan/spector/actions

The project maintains an explicit policy documented in CONTRIBUTING.md under 'Testing Expectations' requiring unit and integration tests for all new classes, features, and bug fixes. Every pull request enforces this policy via a required checklist item in .github/pull_request_template.md ('I have added tests to cover my changes'). https://github.com/spectrayan/spector/blob/main/.github/pull_request_template.md

Recent major feature pull requests demonstrate strict adherence to the test policy: PR #997 (Memory Portability) added 6 automated test suites including golden end-to-end tests; PR #996 (Purge & Compaction) added 14 unit and integration test suites; and PR #975 (Procedural Skills) added 17 test suites covering all newly introduced relays and MCP tools. All tests are validated automatically in CI prior to merge. https://github.com/spectrayan/spector/pull/997

The policy on adding tests is explicitly documented in the instructions for change proposals in CONTRIBUTING.md under 'Pull Request Process' and 'PR Checklist', requiring contributors to verify that 'Tests added/updated covering changed behavior and edge cases (mvn test)'. This is also enforced in the GitHub Pull Request submission template (.github/pull_request_template.md). https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#pr-checklist

The project uses GitHub CodeQL (.github/workflows/codeql.yml) as an automated static analyzer and linter running security-extended checks across Java, TypeScript, and Python on every pull request and push to main. In addition, ArchUnit is used in the Java test suite to enforce architectural rules and prevent code quality regressions. https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml

Compiler, linter, and static analysis warnings are actively addressed. The project runs an automated workflow (.github/workflows/codeql-to-issue-sync.yml) that syncs static analysis alerts to trackable GitHub issues for triage. Identified warnings are systematically remediated in dedicated PRs (e.g., issue #884 resolving CodeQL alerts). Build-time license and style checks fail CI if violations exist. https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql-to-issue-sync.yml

The project applies strict quality gates: CodeQL runs with the 'security-extended' query suite, documentation builds enforce 'mkdocs build --strict' (failing CI on any warning or broken link), and Maven license checks strictly fail the build on any compliance warning. https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml

The primary developer and project lead (@sbharatjoshi) designs software following secure architecture principles (defense-in-depth, least privilege, safe defaults). This is demonstrated across Spector's architecture: off-heap memory safety via Panama FFM bounded arenas, strict tenant namespace path sandboxing to prevent directory traversal, CRC32C data integrity validation, and API authentication. Maintainers actively triage security alerts (CodeQL, Dependabot) and adhere to the CVD process in SECURITY.md.

Project maintainers actively counter the primary vulnerability classes relevant to native memory engines and agent systems: memory corruption is mitigated via Panama FFM bounded arenas; path traversal via namespace sandboxing and path canonicalization; DoS/resource exhaustion via inline Bloom gating and recall visit budgets; and deserialization risks via custom binary formats with magic byte and CRC32C checksum verification rather than native serialization. https://github.com/spectrayan/spector/blob/main/SECURITY.md

The software exclusively uses standard, publicly vetted, and internationally reviewed cryptographic algorithms: AES-256-GCM (NIST SP 800-38D) for at-rest payload encryption, HMAC-SHA256 (RFC 2104) for blind indexing, and TLS 1.2/1.3 for in-transit network communications. No proprietary, home-grown, or unreviewed cryptography is used. https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md

The project does not re-implement cryptographic primitives. All cryptographic functionality is delegated to standard, established platform libraries: the Java Cryptography Architecture (JCA / javax.crypto) in OpenJDK for symmetric encryption and HMAC hashing, and standard TLS implementations for network transport.

All cryptographic functionality relies solely on FLOSS software: OpenJDK's standard JCA implementation (GPLv2 with Classpath Exception) and Apache Netty/OpenSSL (Apache 2.0). Zero proprietary cryptographic libraries, commercial licenses, or closed-source components are required.

The project uses 256-bit keys by default for symmetric encryption (AES-256-GCM) and HMAC operations (HMAC-SHA256), which exceeds NIST minimum requirements (128-bit minimum through 2030). Sub-standard key lengths and legacy ciphers (e.g., DES, 3DES, RSA < 2048) are completely unsupported and disabled by default by the OpenJDK 25 security provider and Spector's configuration validators.

The software does not depend on or use any broken or deprecated cryptographic algorithms (such as MD4, MD5, single DES, RC4, or SHA-1) or insecure modes such as ECB. All security mechanisms rely strictly on AES-256-GCM (AEAD), HMAC-SHA256, and modern TLS cipher suites. No backward-compatibility exceptions with legacy broken algorithms are present.

The default security mechanisms avoid algorithms or modes with known weaknesses. Hashing exclusively uses SHA-256 (HMAC-SHA256) rather than SHA-1, and symmetric encryption strictly uses AES-256 in GCM (AEAD) mode rather than CBC or unauthenticated modes.

Network transport (REST, gRPC, cluster replication) implements Perfect Forward Secrecy (PFS) via TLS 1.3 and TLS 1.2 using Ephemeral Diffie-Hellman (ECDHE) key exchange cipher suites. Compromise of a server's long-term private key does not compromise previously recorded session traffic.

For local demo and standalone user authentication in Synapse, user passwords are stored using PBKDF2 with HMAC-SHA256, a 16-byte independent salt per user, and 310,000 iterations matching the OWASP Password Storage Cheat Sheet baseline (implemented in SecurityConfig.java). Enterprise deployments are directed to upstream OAuth2/OIDC identity providers.

All cryptographic keys, AES-GCM initialization vectors (nonces), salts, and security tokens are generated exclusively using java.security.SecureRandom. Insecure pseudo-random number generators (such as java.util.Random or Math.random) are never used for cryptographic or security mechanisms. https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/security/crypto/AesGcmCipher.java#L50

Distribution channels use HTTPS exclusively. [osps_br_03_02]

All software downloads, checksums, and dependency hashes are retrieved exclusively over secure HTTPS/TLS (via GitHub Releases and Maven Central). Unencrypted plain HTTP is never used for retrieving hashes or artifacts. https://github.com/spectrayan/spector/blob/main/scripts/install.sh

There are zero unpatched vulnerabilities in Spector that have been known for more than 60 days (0 open Dependabot alerts, 0 CVEs). The project's published security policy (SECURITY.md) commits to resolving Critical vulnerabilities in <= 7 days, High in <= 14 days, and Medium in <= 30 days. Maintainers remediate all dependency and scan findings well within these windows.

The project maintains a documented SLA in SECURITY.md to acknowledge critical vulnerabilities within 24 hours and release fixes within 7 days. In practice, maintainers prioritize security findings immediately, with security fixes and dependency remediations typically merged within 24–48 hours of detection. https://github.com/spectrayan/spector/blob/main/SECURITY.md#response-timeline--severity-slas

The public repository contains no valid private credentials, secrets, or private keys. GitHub Secret Scanning is enabled, all sensitive inputs are injected via environment variables at runtime, and every pull request enforces a mandatory checklist check that no hardcoded secrets or credentials are included. https://github.com/spectrayan/spector/blob/main/.github/pull_request_template.md

The project applies automated static code analysis using GitHub CodeQL (.github/workflows/codeql.yml) with the security-extended query suite across all languages (Java, TypeScript, Python) on every pull request and push to main prior to any release. In addition, ArchUnit performs architectural static analysis during the test lifecycle, and Trivy scans container release images.

CodeQL is configured with the 'security-extended' query suite (.github/workflows/codeql.yml line 58), which incorporates rules covering the OWASP Top 10 and CWE Top 25 vulnerabilities for Java, TypeScript, and Python (including path injection, deserialization flaws, command execution, and cryptographic misconfigurations). https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml#L58

All confirmed medium and higher severity vulnerabilities discovered through static analysis are tracked via automated issue sync (.github/workflows/codeql-to-issue-sync.yml) and remediated in a timely manner. The project's documented SLA in SECURITY.md mandates fixes within 7 days for Critical, 14 days for High, and 30 days for Medium severity issues (demonstrated in past remediations like issue #884).

CodeQL static analysis is triggered automatically on every commit pushed to main and on every pull request commit (.github/workflows/codeql.yml lines 4–24). In addition, architectural static analysis (ArchUnit) executes as part of the automated build and test pipeline on every commit.

The project applies dynamic analysis prior to release using multiple FLOSS tools: jqwik for dynamic randomized property-based testing and fuzzing of algorithmic invariants, PanamaMemoryDetector for dynamic off-heap memory leak tracking, JaCoCo for runtime bytecode coverage analysis, and automated live container smoke testing prior to release publication.

Not applicable. The software produced by the project is written in memory-safe languages (Java 25, TypeScript, and Python) with no compiled C or C++ binaries. Native off-heap memory operations in Java utilize Project Panama's bounded MemorySegment and Arena APIs with built-in spatial/temporal bounds checking, accompanied by dynamic runtime leak detection (PanamaMemoryDetector).

Dynamic analysis and testing runs with JVM assertions enabled by default via the Maven Surefire test runner (-ea), executing internal invariant checks and jqwik property assertions. In production builds and container deployments, assertions are disabled by default to maintain zero-overhead performance on SIMD hot paths. https://github.com/spectrayan/spector/blob/main/pom.xml#L748-L758

All confirmed medium and higher severity vulnerabilities discovered through dynamic analysis are prioritized and resolved in accordance with the response timeline in SECURITY.md (Critical in <= 7 days, High in <= 14 days, Medium in <= 30 days). Dynamic property and smoke tests execute as mandatory CI gates, preventing unpatched runtime defects from entering release branches.