VMAFx

The source repository is public: https://github.com/VMAFx/vmafx

Git history records changes, author/committer identities and timestamps: https://github.com/VMAFx/vmafx/commits/master/

Public pull requests expose interim revisions before release: https://github.com/VMAFx/vmafx/pulls

The project uses distributed Git version control: https://github.com/VMAFx/vmafx

Each VMAFx release has a unique SemVer version and git tag, starting with v1.0.0-rc.1 (https://github.com/VMAFx/vmafx/releases/tag/v1.0.0-rc.1); the release-please verifier rejects a tag whose version does not match the tree. Development revisions are identified by full Git commit IDs, e.g. https://github.com/VMAFx/vmafx/commit/ce00cf2455f48424221a584208be64e66d039f52 .

Every VMAFx release is identified by a git tag that release-please creates when the release is published. The first release, v1.0.0-rc.1, is tag v1.0.0-rc.1 on commit ce00cf2455f48424221a584208be64e66d039f52 (https://github.com/VMAFx/vmafx/releases/tag/v1.0.0-rc.1). The v1.x-v3.x tags without a VMAFx release are inherited Netflix/vmaf upstream releases. Procedure: https://github.com/VMAFx/vmafx/blob/master/docs/development/release.md

Non-trivial release notes file in repository: https://github.com/VMAFx/vmafx/blob/master/CHANGELOG.md.

N/A: no release has fixed a publicly known vulnerability. VMAFx's first release, v1.0.0-rc.1 (https://github.com/VMAFx/vmafx/releases/tag/v1.0.0-rc.1), fixes none with a CVE or similar ID: the repository has no security advisories (https://github.com/VMAFx/vmafx/security/advisories), and NVD lists no VMAF CVE. The security policy commits to naming such fixes in the release notes (https://github.com/VMAFx/vmafx/blob/master/SECURITY.md).

CONTRIBUTING directs bug and enhancement reports to GitHub issue templates: https://github.com/VMAFx/vmafx/issues/new/choose https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/CONTRIBUTING.md

GitHub issues track individual reports: https://github.com/VMAFx/vmafx/issues

Window: 2025-09-26 to 2026-07-26 (2-12 months before this answer; the repository was created on 2026-05-28). The tracker received no bug reports from anyone other than the maintainer in that window. The only outside submissions were pull requests #1081 (a SYCL bug fix) and #1082, and both were answered and merged (https://github.com/VMAFx/vmafx/pull/1081, https://github.com/VMAFx/vmafx/pull/1082). All reports stay public at https://github.com/VMAFx/vmafx/issues?q=is%3Aissue.

Every genuine enhancement request in the last 2-12 months got a response. The only outside one, PR #1082 (the VMAF v1 model-port research digest and ADR), was answered and merged (https://github.com/VMAFx/vmafx/pull/1082). The only other third-party issue, #1225, was unsolicited automated solicitation and was answered and closed within 8 hours (https://github.com/VMAFx/vmafx/issues/1225).

Public issue history retains reports and responses for later searches: https://github.com/VMAFx/vmafx/issues?q=is%3Aissue

The public security policy documents confidential GitHub reporting at https://github.com/VMAFx/vmafx/security/advisories/new . The repository setting was enabled and independently read back as true on 2026-09-08; no response-history claim is made. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/SECURITY.md

Confidential GitHub reporting is available at https://github.com/VMAFx/vmafx/security/advisories/new . The setting was enabled and independently read back as true on 2026-09-08; no past-response or email-monitoring claim is made. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/SECURITY.md

N/A: no vulnerability report was received in the last 6 months. GitHub private vulnerability reporting is enabled and has produced no reports or draft advisories (https://github.com/VMAFx/vmafx/security/advisories). No report arrived through the e-mail channel listed in https://github.com/VMAFx/vmafx/blob/master/SECURITY.md, whose published target is acknowledgement within 72 hours.

Non-trivial build file in repository: https://github.com/VMAFx/vmafx/blob/master/Makefile.

Non-trivial build file in repository: https://github.com/VMAFx/vmafx/blob/master/Makefile.

The default build uses only FLOSS tools: GCC or Clang, Meson, Ninja and Python (https://vmafx.github.io/vmafx/getting-started/, https://github.com/VMAFx/vmafx/blob/master/core/meson.build). CUDA, SYCL and HIP are off by default. Metal is detected only on macOS; only those optional backends need a vendor toolchain.

Public BSD-licensed native tests and contributor instructions provide automated tests and invocation commands. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/core/test/meson.build https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/CONTRIBUTING.md https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/LICENSE

Native tests use the standard Meson test command documented in CONTRIBUTING. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/CONTRIBUTING.md

The Coverage Gate measures the CPU libvmaf build on every change. On master 52ead780c it exercises 79.5% of lines (28,565/35,935) and 62.5% of branches (https://github.com/VMAFx/vmafx/actions/runs/36268143869/job/108476747662). The GPU backends and the Go and Python packages have their own suites, which are not in this figure.

GitHub Actions runs the build, unit tests, Netflix golden-data tests, sanitizers, coverage, lint and security scans on every pull request and every push to master (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/tests-and-quality-gates.yml, https://github.com/VMAFx/vmafx/actions). A required aggregate CI status check gates merges to master.

The contribution guide requires major new functionality to include automated tests in the same change, covering the new behaviour and its failure paths. It also tells reviewers to check the tests against the actual change (https://github.com/VMAFx/vmafx/blob/master/CONTRIBUTING.md#review-expectations).

Recent major changes added tests together with the functionality. Examples: percentile temporal pooling in the C API (https://github.com/VMAFx/vmafx/pull/1340, https://github.com/VMAFx/vmafx/pull/1392), the MCP bridge to the gRPC control plane (https://github.com/VMAFx/vmafx/pull/1319), the uncapped PSNR option (https://github.com/VMAFx/vmafx/pull/1338) and SYCL chroma MS-SSIM (https://github.com/VMAFx/vmafx/pull/1523).

The test-addition policy is part of the change-proposal instructions in https://github.com/VMAFx/vmafx/blob/master/CONTRIBUTING.md#review-expectations. The pull-request template asks for passing unit tests and a reproducer command (https://github.com/VMAFx/vmafx/blob/master/.github/PULL_REQUEST_TEMPLATE.md).

The source configures compiler-independent clang-tidy and Cppcheck checks plus other diagnostics. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/.clang-tidy https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/.github/workflows/lint-and-format.yml

Warnings are fixed or explicitly justified. C/C++ builds use -Wall -Wextra (Meson warning_level=2). A whole-tree clang-tidy ratchet stops any file from gaining warnings and requires a lower baseline whenever a file is cleaned (https://github.com/VMAFx/vmafx/blob/master/scripts/ci/tidy-ratchet.py, https://vmafx.github.io/vmafx/development/ci/). The remaining strict-profile findings are about 0.9 per 100 lines across the five backend lanes (per-file counts in https://github.com/VMAFx/vmafx/tree/master/scripts/ci), and every in-source suppression states its reason.

Strict analyzer/CERT checks are enabled. This does not claim warning-free source or satisfy warnings_fixed. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/.clang-tidy

The primary developer (GitHub: lusoris) knows the secure-design principles listed in this criterion and applies them. Fail-safe defaults: the MCP HTTP transport binds to 127.0.0.1 and rejects every request with 401 until a token is configured (https://vmafx.github.io/vmafx/mcp/http-transport/). Complete mediation and least privilege: each request gets an RS256 JWT check with tenant isolation and role-based access (https://vmafx.github.io/vmafx/server/auth/). Small attack surface: model verification fails closed and runs cosign without a shell (https://vmafx.github.io/vmafx/ai/security/).

The primary developer knows the error classes that affect a C/C++ media-parsing library and its network services, with at least one mitigation for each. Classes: buffer overflows, integer overflow, use-after-free, NULL dereference, command injection, path traversal, missing authentication or authorization, and timing leaks. Mitigations: SEI CERT C and Power-of-10 rules with banned unsafe functions (https://vmafx.github.io/vmafx/principles/); ASan, UBSan, TSan and libFuzzer in CI (https://vmafx.github.io/vmafx/development/fuzzing/); posix_spawnp instead of system(); path allowlists; deny-by-default authentication; constant-time token comparison.

VMAFx uses only published, expert-reviewed cryptography: RS256 JWT signatures (RSASSA-PKCS1-v1_5 with SHA-256, RFC 7518) in the controller (https://github.com/VMAFx/vmafx/blob/master/cmd/vmafx-controller/auth/rsa.go); TLS 1.2/1.3 for the optional MCP HTTPS listener (https://github.com/VMAFx/vmafx/blob/master/mcp-server/vmaf-mcp/src/vmaf_mcp/http_transport.py); Sigstore/cosign signature checks for tiny-AI models (https://github.com/VMAFx/vmafx/blob/master/core/src/dnn/model_loader.c). No proprietary or home-grown algorithm is used.

VMAFx does not implement cryptographic primitives itself. It calls Go's standard crypto packages (crypto/rsa, crypto/sha256, crypto/rand, crypto/subtle), Python's ssl, hmac and hashlib modules (OpenSSL), and the cosign CLI for Sigstore verification (https://github.com/VMAFx/vmafx/blob/master/cmd/vmafx-controller/auth/rsa.go, https://github.com/VMAFx/vmafx/blob/master/core/src/dnn/model_loader.c).

Every cryptographic function is provided by FLOSS: the Go standard library (BSD-3-Clause), CPython's ssl, hmac and hashlib on OpenSSL (Apache-2.0), and Sigstore cosign (Apache-2.0). No proprietary cryptographic component is required.

Defaults meet NIST 2030 minimums and weaker keys are refused: the controller rejects JWKS RSA keys shorter than 2048 bits and malformed public exponents (https://github.com/VMAFx/vmafx/blob/master/cmd/vmafx-controller/auth/middleware.go, documented at https://vmafx.github.io/vmafx/server/auth/); node session tokens are 128-bit crypto/rand values; the optional MCP TLS listener uses OpenSSL security level 2 (at least 2048-bit RSA/DH, at least 224-bit ECC); model signatures use ECDSA P-256 via cosign.

The default security mechanisms use no broken algorithms or unsuitable modes. JWT verification accepts only RS256 and rejects alg=none and HS256 before key lookup (https://vmafx.github.io/vmafx/server/auth/). Python's ssl defaults on the optional MCP TLS listener allow only TLS 1.2 or later, with forward-secret suites that do not use SHA-1 MACs. Cosign checks use ECDSA P-256 with SHA-256. MD4, MD5, DES, RC4 and Dual_EC_DRBG are not used; SHA-1 appears only as a non-security cache key in the inherited Python harness.

No default security mechanism depends on SHA-1 or another algorithm or mode with serious known weaknesses. Signatures use SHA-256 (RS256, Sigstore), and token comparison is constant-time. Python 3.10+ ssl defaults disable TLS suites with SHA-1 MACs or without forward secrecy (https://docs.python.org/3.10/whatsnew/3.10.html#ssl). The SHA-1 calls in the inherited Python harness only name cached result files (https://github.com/VMAFx/vmafx/blob/master/compat/python-vmaf/core/result_store.py).

The only key-agreement protocol VMAFx runs itself is TLS on the optional MCP HTTPS listener. That listener uses Python's default server context: TLS 1.3, or TLS 1.2 limited to ECDHE/DHE suites, so every session has forward secrecy (https://github.com/VMAFx/vmafx/blob/master/mcp-server/vmaf-mcp/src/vmaf_mcp/http_transport.py). The Go services do not implement TLS or any other key agreement.

N/A: no VMAFx component stores passwords of external users. The controller authenticates users with JWTs issued by an external OIDC provider (https://vmafx.github.io/vmafx/server/auth/). The MCP HTTP transport compares one operator-supplied bearer token taken from the environment (https://vmafx.github.io/vmafx/mcp/http-transport/).

Security-relevant random values come from cryptographically secure generators. Controller node session tokens are 128-bit values from Go's crypto/rand (https://github.com/VMAFx/vmafx/blob/master/cmd/vmafx-controller/nodes/registry.go). TLS and Sigstore key and nonce generation is left to OpenSSL and cosign. math/rand is used only by a non-security parameter search (https://github.com/VMAFx/vmafx/blob/master/pkg/prefilter/tpe.go).

Distribution channels use HTTPS exclusively. [osps_br_03_02]

VMAFx never retrieves a cryptographic hash over plain HTTP. GitHub serves the source and release assets over HTTPS only. Python dependency hashes are committed in the repository's lock files, and pip verifies them (https://github.com/VMAFx/vmafx/blob/master/python/requirements-lock.txt). The release workflow signs every release asset keylessly with Sigstore cosign and publishes SLSA provenance (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/supply-chain.yml).

There is no publicly known vulnerability in VMAFx: the repository has no security advisories (https://github.com/VMAFx/vmafx/security/advisories), and no CVE names VMAF or libvmaf. Vulnerable dependencies are also updated within 60 days. For example, the Go advisories for kin-openapi and gRPC were fixed by https://github.com/VMAFx/vmafx/pull/1088 and https://github.com/VMAFx/vmafx/pull/1089, 8-36 days after the alerts opened.

No critical vulnerability has been reported in VMAFx. The security policy requires urgent handling of Critical reports, with a fix target of 30 days or less (https://github.com/VMAFx/vmafx/blob/master/SECURITY.md#response-timeline).

Gitleaks scans the full git history on every push and pull request and fails the build on any finding; the scan passes on master (https://github.com/VMAFx/vmafx/actions/runs/36268143884). GitHub secret scanning with push protection is enabled. Its only alert was a test fixture that grants access to nothing: the base64 of "user:pass" in a negative authentication test (https://github.com/VMAFx/vmafx/blob/master/cmd/vmafx-controller/auth/grpc_interceptor_test.go). Release signing is keyless, so there is no signing key to leak.

Static analysis runs on every pull request and every push to master, and releases are cut from master, so each proposed release is analysed. Tools: CodeQL (C/C++, Python, GitHub Actions) and Semgrep (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/security-scans.yml); clang-tidy with clang-analyzer and CERT checks, plus cppcheck (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/lint-and-format.yml); go vet and gosec (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/go-ci.yml). All passed on master 52ead780c (https://github.com/VMAFx/vmafx/actions/runs/36268143884).

Configured static tools include common-defect analyzer/CERT checks and project Semgrep rules. https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/.clang-tidy https://github.com/VMAFx/vmafx/blob/78c9d2bfc580880919d5168c18ad19441f9db96a/.semgrep.yml

All confirmed static-analysis findings are fixed. Master has no open CodeQL, Semgrep or Gitleaks alert; the only open code-scanning entries are four OpenSSF Scorecard repository-settings checks, which are not code findings. Findings closed without a code change carry a written dismissal: a false positive with proof that the operands are bounded, or test-only code. Fixes are logged in https://github.com/VMAFx/vmafx/blob/master/docs/state.md.

CodeQL, Semgrep, clang-tidy, cppcheck, go vet and gosec run on every push and pull request; an impact planner skips lanes a change cannot affect. The security scan also runs on a weekly schedule (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/security-scans.yml).

Every change to the C core runs the native test suite under AddressSanitizer plus UndefinedBehaviorSanitizer and under ThreadSanitizer, daily as well (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/sanitizers.yml). Five libFuzzer harnesses run nightly with ASan (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/fuzz.yml). Releases are cut from master, where these pass (https://github.com/VMAFx/vmafx/actions/runs/36268143829).

The C/C++ code is fuzzed nightly with libFuzzer and AddressSanitizer across five harnesses: Y4M and YUV input, CLI parsing, JSON model loading and DNN sidecar parsing (https://vmafx.github.io/vmafx/development/fuzzing/). The test suite runs under ASan, UBSan and TSan on every change (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/sanitizers.yml).

Sanitizer and fuzz builds use Meson's debug build type, so assert() stays enabled (NDEBUG is not defined), and the sanitizers abort on the first error (halt_on_error=1) (https://github.com/VMAFx/vmafx/blob/master/.github/workflows/sanitizers.yml, https://github.com/VMAFx/vmafx/blob/master/.github/workflows/fuzz.yml). A separate CI job enforces assertion density in the C core.

Memory-safety defects found by fuzzing and sanitizers are fixed within days, and their reproducers are kept as regression inputs. Examples: a NULL dereference on negative Y4M dimensions, a 4:1:1 chroma heap overflow, and a JSON-model heap overflow found by fuzz_json_model (https://vmafx.github.io/vmafx/state/, https://github.com/VMAFx/vmafx/tree/master/core/test/fuzz). No sanitizer or fuzzer finding is open.