WhitePact

WhitePact maintains one active supported release line and provides a documented upgrade and backward-compatibility path to newer versions. The project follows Semantic Versioning, with breaking changes reserved for major releases.

Legacy package names, import paths, environment variables, CLI names, and MCP resource identifiers are retained through compatibility aliases and documented transition periods so existing installations can upgrade without abrupt breakage.

Supported-version policy:
https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/SECURITY.md

Migration/upgrade compatibility:
https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/MIGRATION_WHITEPACT_V2.md

WhitePact uses the GitHub Issues tracker to track individual bugs, enhancement requests, and other actionable project issues.

https://github.com/Guruprasath-Annadurai/Whitepact/issues

N/A — WhitePact has not resolved any externally reported vulnerabilities during the last 12 months.

The project's security policy nevertheless explicitly commits to crediting vulnerability reporters in release notes unless the reporter requests anonymity.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/SECURITY.md

WhitePact maintains a documented vulnerability-response process in SECURITY.md.

Security vulnerabilities must be reported privately rather than through public GitHub issues. The policy defines the reporting channel, required report information, scope, responsible-disclosure expectations, acknowledgement within 48 hours, and a resolution timeline within 7 days.

WhitePact also commits to communicating with reporters, crediting them unless anonymity is requested, and not pursuing legal action against good-faith security researchers.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/SECURITY.md

WhitePact publicly documents its coding standards in CONTRIBUTING.md.

Python code uses Ruff for linting and formatting, with the configured rule set maintained in pyproject.toml. Public functions require type annotations and mypy is used for static type checking. Contributions are required to follow these standards and pass CI before merge.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md

WhitePact automatically enforces its documented Python coding standards through GitHub Actions.

Every relevant change is checked using Ruff linting, Ruff formatting verification, and mypy static type checking. A violation causes CI to fail and prevents the required checks from passing.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml

N/A — WhitePact is primarily a Python project distributed as pure-Python wheel and source distributions using Hatchling. The project does not build native C/C++ binaries and therefore does not directly invoke native compilers or linkers requiring CC, CFLAGS, CXX, CXXFLAGS, or LDFLAGS propagation.

N/A — WhitePact's project-owned distribution is pure Python and does not produce native compiled objects with removable debugging symbols. There is therefore no project build step such as install -s that strips requested native debugging information.

WhitePact uses Hatchling as a single Python packaging build backend. The build does not recursively invoke independent subdirectory build systems with cross-dependencies; the project's Python packages are assembled by the single configured Hatchling build target.

WhitePact uses Hatchling as its build backend. Hatchling enables reproducible builds by default and uses SOURCE_DATE_EPOCH for build timestamps, with a stable default timestamp when it is not provided.

WhitePact does not disable Hatchling's reproducible-build behavior, so wheel and source-distribution generation uses the backend's reproducible build mechanism.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/pyproject.toml

WhitePact uses the standard Python packaging ecosystem for installation and removal.

End users install the published package using pip, for example:

pip install "rai-governance-platform[dashboard]"

and it can be removed using the standard:

pip uninstall rai-governance-platform

Installation instructions are publicly documented in README.md.

https://github.com/Guruprasath-Annadurai/Whitepact#install

WhitePact delegates installation-location handling to pip, the standard Python package installer, rather than implementing a custom installer. Standard pip installation controls such as virtual environments, --target, --prefix, --root, and --user are therefore honored without being overridden by WhitePact.

WhitePact documents a standard development installation using a Python virtual environment and an editable pip installation:

pip install -e ".[dev]"

This installs WhitePact together with its development and testing dependencies, including pytest, pytest-cov, Ruff, mypy, and related development tooling.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md

WhitePact declares its external runtime, optional, and development dependencies in the machine-processable pyproject.toml package configuration.

Dependencies are separated into the core dependency list and named optional groups for dashboard, PostgreSQL, Redis, telemetry, SSO, model providers, billing, testing, and other integrations.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/pyproject.toml

WhitePact automatically checks dependencies for known vulnerabilities using pip-audit.

Dependency auditing runs in normal CI and in a separate recurring security workflow that runs on pushes to main and weekly. Confirmed dependency vulnerabilities fail the applicable security check unless a specific finding has been explicitly investigated, documented, and determined not to be exploitable in WhitePact's usage.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/security-scan.yml

WhitePact uses standard Python package dependencies declared centrally in pyproject.toml rather than embedding private or difficult-to-identify copies of those dependencies.

Dependency versions and compatibility constraints can therefore be identified and updated through the normal Python packaging workflow and validated by the automated test and security-audit pipelines.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/pyproject.toml

WhitePact uses maintained libraries and APIs and periodically reviews dependency compatibility and security.

Where a new major dependency version contains breaking API changes, compatibility constraints are explicitly documented rather than silently ignored. Such migrations are handled deliberately with tests and backward-compatibility planning instead of continuing unknowingly on obsolete interfaces.

WhitePact runs its automated test suite through GitHub Actions on every push to main and develop and on pull requests targeting main.

The CI job installs the project and development dependencies, runs linting and type checking, executes pytest with coverage, and reports success or failure through the GitHub Actions status checks.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml

WhitePact's engineering policy requires functional changes and bug fixes to include automated tests, and pull requests that reduce coverage are required to add tests before merge.

The project therefore targets regression-test coverage substantially above the Silver requirement that at least 50% of fixed bugs receive regression tests.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md

WhitePact's FLOSS automated pytest/pytest-cov test suite exceeds the required 80% statement-coverage threshold.

The verified coverage run contains 2,249 passing tests. Pure branch coverage is independently measured at 80.19% (1469/1832), while the overall statement-plus-branch coverage is approximately 89%; because branch coverage is below that combined percentage, statement coverage is necessarily above the combined percentage and therefore comfortably above the 80% Silver statement-coverage requirement.

Coverage is generated automatically in CI using pytest-cov/coverage.py.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/OPENSSF_DYNAMIC_ANALYSIS.md

WhitePact has a formal written engineering policy requiring automated tests for functional changes and major new functionality.

CONTRIBUTING.md states that every functional change needs a test, and WhitePact-specific development sections additionally define the testing expectations for governance features, MCP tools, providers, migrations, and security-sensitive changes.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md

WhitePact's documented instructions for proposed changes explicitly require tests.

CONTRIBUTING.md states that tests are required for pull requests, functional changes must have tests, coverage must not regress, and CI must pass before a change is considered ready for merge.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md

WhitePact uses strict automated quality checks appropriate to its Python implementation.

Ruff is configured with error, Pyflakes, import-order, pyupgrade, bugbear, and naming rules, while mypy performs static type checking. Both run as hard CI checks, so violations fail the build.

Only a small documented set of Ruff rules is intentionally excluded where strict enforcement is not practical for the existing codebase.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/pyproject.toml
https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml

WhitePact implements secure-design principles throughout the project.

Security-sensitive design includes least-privilege RBAC, tenant isolation, parameterized database access, explicit validation of untrusted network destinations, strong cryptographic key-generation and minimum-strength policies, rate limiting, secure secret handling, fail-closed authorization behavior, and automated security analysis.

The project's internal security review documents manual review of authentication, authorization, SQL construction, SSRF, dangerous-function usage, cryptography, and tenant isolation, including real vulnerabilities discovered and remediated with regression tests.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/INTERNAL_SECURITY_REVIEW.md

WhitePact's default security mechanisms do not depend on cryptographic algorithms with known serious weaknesses.

The project uses SHA-256/HMAC-SHA256 for hashing and message authentication, cryptographically secure random generators for secrets, modern Fernet-based field encryption, and RSA keys of at least 2048 bits for OIDC verification.

OIDC JWT validation is restricted to modern RS256/RS384/RS512 and ES256/ES384/ES512 signature algorithms.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/auth/crypto_policy.py

WhitePact supports cryptographic algorithm agility where protocols require algorithm negotiation.

OIDC token validation supports multiple modern signature algorithms across two algorithm families: RSA (RS256, RS384, RS512) and elliptic-curve ECDSA (ES256, ES384, ES512).

TLS is delegated to modern TLS implementations/reverse proxies capable of negotiating multiple approved TLS cipher suites rather than binding the application to one fixed transport cipher.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/auth/oidc.py

WhitePact stores authentication credentials and private application cryptographic keys separately from application source code.

Secrets are supplied through environment variables or external secret-management systems and can be replaced without recompiling or modifying application code.

The field-encryption mechanism explicitly supports key rotation using an ordered multi-key configuration so data can be migrated to a new key without requiring application recompilation.

No private credentials or encryption keys are stored in the public repository.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/KEY_MANAGEMENT.md

WhitePact supports secure network communication through HTTPS/TLS for production deployments.

TLS is terminated by the deployment's trusted reverse proxy, load balancer, ingress, or managed cloud edge. The documented production nginx configuration enables TLS 1.2 and TLS 1.3 with modern authenticated cipher suites.

Plain HTTP is used for local/internal application transport and development, while public production endpoints are expected to be exposed through TLS.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/DEPLOYMENT.md

WhitePact supports TLS 1.2 or later for production network communication.

The documented production reverse-proxy configuration explicitly enables TLS 1.2 and TLS 1.3. The WhitePact reference deployment has also been verified to negotiate TLS 1.3.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/DEPLOYMENT.md

WhitePact performs TLS certificate verification by default for outbound HTTPS communication.

OIDC discovery, JWKS retrieval, token exchange, and other HTTPS client operations use httpx's secure default TLS configuration. WhitePact does not disable certificate verification with verify=False in these security-sensitive paths.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/auth/oidc.py

WhitePact relies on standard HTTPS/TLS client behavior in which the TLS handshake and server-certificate verification are completed before HTTP request headers or request bodies containing private authentication information are transmitted.

OIDC token-exchange requests use httpx with certificate verification enabled by default; no insecure certificate-verification override is configured.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/auth/oidc.py

WhitePact cryptographically attests its published wheel and source-distribution artifacts using GitHub Artifact Attestations backed by Sigstore and GitHub Actions OIDC.

The release workflow creates build-provenance attestations for dist/* before publishing to PyPI and uses PyPI Trusted Publishing, so no long-lived private PyPI or signing key is stored on the public distribution service.

Every GitHub Release includes verification instructions:

gh attestation verify <artifact> --owner Guruprasath-Annadurai

This verifies that the artifact was produced by WhitePact's trusted GitHub Actions workflow from the identified repository and commit.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/publish.yml

WhitePact maintains a public security assurance case that connects the project's security requirements to concrete architecture, implementation controls, tests, and automated security evidence.

The assurance case includes an explicit threat model, clearly identified trust boundaries, an argument demonstrating application of secure-design principles, and an analysis showing how common implementation security weaknesses are countered through controls including authentication, RBAC, tenant isolation, input validation, SSRF protection, parameterized database access, cryptographic-strength policies, secure secret handling, runtime authority enforcement, CI security scanning, dependency auditing, and supply-chain provenance.

Residual risks and known limitations are explicitly documented rather than represented as solved.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/SECURITY_ASSURANCE_CASE.md

WhitePact validates untrusted input at its external boundaries.

The REST API uses FastAPI/Pydantic models, typed fields, constrained values, email validation, query validation, and explicit field validators. Security-sensitive inputs receive additional validation rather than relying only on schema parsing.

Examples include SSRF-resistant webhook/upstream URL validation, minimum webhook-secret strength, minimum OIDC RSA key size, authentication and role validation, tenant isolation, and parameterized database queries.

Invalid or unsafe input is rejected before the protected operation is performed.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/INTERNAL_SECURITY_REVIEW.md

WhitePact uses defense-in-depth hardening mechanisms to reduce the impact of software defects.

The dashboard applies security response headers including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Cache-Control, and Permissions-Policy.

Additional hardening includes request rate limiting, RBAC, tenant isolation, SSRF defenses, strong secret generation, minimum cryptographic key-strength checks, secure error responses, automated SAST, dependency auditing, and security regression tests.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/dashboard/middleware.py

WhitePact cryptographically signs important Git version tags and documents how users can verify those signatures.

Important release tags are created as annotated cryptographically signed tags using an approved project release-signing identity. The release process verifies that a release tag is annotated, signed, valid, and issued by an approved signer before publication.

Public verification information is provided so users can independently verify Git tag signatures. This complements, rather than replaces, WhitePact's existing GitHub/Sigstore build-provenance attestations for published release artifacts.

https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/RELEASING.md

WhitePact uses Bandit, a FLOSS Python static-analysis security tool designed to identify common security weaknesses and insecure coding patterns in Python source code. Bandit scans the WhitePact application source recursively as part of the security workflow.

N/A — WhitePact's project implementation does not include C, C++, or another memory-unsafe implementation language requiring AddressSanitizer, Valgrind, or equivalent memory-safety dynamic analysis. Its primary runtime implementation uses memory-safe languages such as Python and TypeScript/JavaScript.