zk-proof-engine

The project maintains a documented upgrade path through its versioned releases and release documentation. Changes are tracked in the version-controlled repository, and release notes document significant changes and upgrade-impact information for users moving between releases. The project uses tagged/versioned releases rather than requiring users to remain on an unsupported historical version.

GitHub Issues is enabled and publicly available for tracking individual project issues.

https://github.com/vishnuvardhanburri/zk-proof-engine:No vulnerability reports have been resolved by the project during the last 12 months. Therefore, there are no vulnerability reporters requiring credit under this criterion.

https://github.com/vishnuvardhanburri/zk-proof-engine:https://github.com/vishnuvardhanburri/zk-proof-engine/blob/main/SECURITY.md.The project documents a vulnerability response process in SECURITY.md, including the private reporting channel, information expected from reporters, acknowledgement and triage, remediation, coordinated disclosure, and supported-version handling.

The project identifies TypeScript/JavaScript coding standards through its ESLint configuration and contribution/development documentation. Contributors are expected to follow the repository's configured linting and formatting rules.:https://github.com/vishnuvardhanburri/zk-proof-engine

https://github.com/vishnuvardhanburri/zk-proof-engine.The project's ESLint checks are automatically executed in CI, so contributions that violate enforced lint rules fail the automated quality checks.

https://github.com/vishnuvardhanburri/zk-proof-engine.The project does not produce native binaries through a compiler/linker build system requiring CC, CFLAGS, CXXFLAGS, or LDFLAGS handling.

The project's primary build/install workflow produces JavaScript/TypeScript software rather than a conventional native binary installation requiring preservation of compiler debugging information.

The project does not use the native recursive subdirectory build model targeted by this criterion.

The release/build process is designed to produce deterministic outputs from the same source and dependency state, and reproducibility is verified by the project's release validation process.The release/build process is designed to produce deterministic outputs from the same source and dependency state, and reproducibility is verified by the project's release validation process.

The project provides standard npm-based installation and workspace setup using package manifests and npm commands.

The project does not use a traditional system-wide POSIX installation mechanism requiring DESTDIR or an equivalent installation-prefix convention.

The repository provides documented developer setup instructions covering dependency installation, build, testing, linting, typechecking, and the required development environment.

External dependencies are declared in the repository's package manifests and package-lock.json, providing a computer-processable dependency inventory.https://github.com/vishnuvardhanburri/zk-proof-engine

https://github.com/vishnuvardhanburri/zk-proof-engine: The project monitors dependencies through automated dependency updates and security scanning, including OSV-Scanner, npm audit, and Dependabot-based dependency updates.

External components are managed through package manifests and a lockfile, making dependency versions identifiable and updateable. Automated dependency update tooling also creates updates for vulnerable or outdated components.

The project maintains current APIs and dependencies appropriate to its supported technology stack and reviews dependency updates through automated dependency-management and security-scanning workflows.

https://github.com/vishnuvardhanburri/zk-proof-engine:GitHub Actions executes the project's automated test suites on repository changes and reports success or failure as required CI status checks.

Recent bug fixes are accompanied by regression tests covering the corrected behavior, including security, concurrency, isolation, queue, self-healing, and proof-verification failure paths.

Recent bug fixes are accompanied by regression tests covering the corrected behavior, including security, concurrency, isolation, queue, self-healing, and proof-verification failure paths.

The project has a documented development policy requiring automated tests when major new functionality is introduced. CI requires the automated test suite to pass for repository changes.

The project's contribution/development documentation instructs contributors to add automated tests for new or changed functionality, and CI validates the resulting test suite.

The project applies strict linting and type checking in CI. ESLint and TypeScript checks are required to pass, preventing lint and type-quality violations from being accepted through the normal CI workflow.

The project implements defense-in-depth secure-design principles across its API, engine, cryptographic, and on-chain boundaries. Controls include fail-closed defaults, input validation, authentication and authorization, tenant isolation, bounded concurrency, rate limiting, replay/idempotency protection, separation of privileges, and explicit trust-boundary enforcement.

The project's default security mechanisms avoid cryptographic algorithms and modes with known serious weaknesses, including SHA-1 and other deprecated primitives.

The current cryptographic interfaces intentionally use fixed, explicitly specified algorithms and do not yet provide user-selectable algorithm agility across multiple equivalent cryptographic implementations.

Authentication credentials and cryptographic key material are supplied through external configuration/credential mechanisms rather than being compiled into the application. Credentials and keys can therefore be rotated or replaced without recompiling the software.

Network communication uses secure HTTPS/TLS-capable mechanisms. Insecure protocols such as FTP, Telnet, SSLv3, and SSHv1 are not part of the supported default communication model.

TLS-capable network communication supports TLS 1.2 or later through the underlying HTTPS/TLS stack.

TLS certificate verification is performed by the underlying HTTPS/TLS implementation by default. The application does not disable certificate verification as part of its normal network communication path.

Private authentication material is transmitted only through the configured secure HTTPS/TLS communication path, with certificate verification performed before protected HTTP communication.

Project releases intended for public use are cryptographically signed. The repository documents how users obtain the public verification key and verify release signatures. Private signing material is kept separate from public software distribution infrastructure.

Important release version tags are cryptographically signed and can be independently verified using Git's tag-signature verification mechanisms.Important release version tags are cryptographically signed and can be independently verified using Git's tag-signature verification mechanisms.

The project validates untrusted inputs at its API and proof-processing boundaries using explicit schemas and domain validation. Invalid, malformed, unauthorized, expired, or otherwise out-of-policy inputs are rejected rather than implicitly accepted.

The project applies multiple hardening mechanisms including strict TypeScript type checking, ESLint, schema validation, bounded request and verification concurrency, rate limiting, fail-closed authorization and verification, dependency scanning, secret scanning, CodeQL analysis, and security-focused CI controls.https://github.com/vishnuvardhanburri/zk-proof-engine

The project provides a documented security assurance case covering the threat model, trust boundaries, security requirements, secure-design principles, and mitigations for common implementation weaknesses. The documentation connects these security claims to concrete controls implemented in the API, engine, cryptographic layer, CI/supply-chain controls, and on-chain registry.https://github.com/vishnuvardhanburri/zk-proof-engine

CodeQL performs security-focused static analysis for JavaScript/TypeScript and includes rules designed to identify common vulnerability classes in the analyzed environment.

The project does not produce application software written in memory-unsafe languages such as C or C++. This criterion is therefore not applicable.