PolicyWatcher

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.

PolicyWatcher’s public GitHub repository contains the complete, granular Git version control history.

It does not simply upload final release archives. All incremental commits, developer pull requests, feature-branch updates, and daily modifications are committed and visible in real time, allowing for continuous collaborative review of interim code changes before they are finalized into a official release.

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

PolicyWatcher follows the Semantic Versioning (SemVer) specification (e.g., 3.0.0, 3.0.1, 3.5.0).

Every user-facing release is assigned a unique version identifier which is:

Declared in the project’s package.json file.
Formally logged and explained in the CHANGELOG.md file.
Displayed on the web platform's UI (in the footer as Build vX.Y.Z).
Assigned as a unique Git release tag on GitHub.

The project strictly implements the Semantic Versioning (SemVer 2.0.0) version numbering format (MAJOR.MINOR.PATCH).

This format maps directly to the project's release guidelines:

MAJOR increment (e.g., 3.0.0): Indicates significant feature updates, database restructuring, or framework modifications.
MINOR increment (e.g., 3.5.0): Indicates structured release tracks, such as alternating between Feature Drops (X.0) and Confidence Releases (X.5).
PATCH increment (e.g., 3.0.1): Used for small bug fixes, security header adjustments, and build packaging corrections.

https://github.com/sev7enITA/policywatcher/blob/main/CHANGELOG.md (and GitHub releases page: https://github.com/sev7enITA/policywatcher/releases)

Release notes justification
PolicyWatcher maintains a structured, human-readable CHANGELOG.md in the root repository.

For every release, the log provides a clear summary categorized into:

Added: New features, pages, or components (e.g., v3.5 Roadmap page, Interchangeable Navigation layouts).
Changed: Structural refactoring, database updates, or dependency version upgrades.
Fixed: Specific bug resolutions or security configurations (e.g., CSP header hardening).
These notes are written by the maintainers, are separate from raw git log commits, and are also published inside the web application via the interactive Changelog menu modal.

There have been no publicly known vulnerabilities or CVEs associated with the PolicyWatcher codebase. As there are no vulnerability reports or CVE assignments to document, this criterion is not applicable to the current release logs.

GitHub provides defect reporting mechanisms by default (via issues). [osps_do_02_01]https://github.com/sev7enITA/policywatcher/issues

PolicyWatcher uses GitHub Issues as its dedicated tracker to log, categorize, and track the status of individual bug reports, feature enhancements, and tasks.

Using GitHub's native issue tracker allows the project to:

Assign tasks to specific maintainers.
Use labels (e.g., bug, enhancement, security, documentation) to organize work.
Link issues directly to Pull Requests and specific code commits for complete traceability.
Group issues into milestones for release planning (e.g., tracking v3.5 Confidence Release priorities).

All public bug reports submitted via the GitHub Issue Tracker are actively reviewed and triaged by the maintainers.

The project maintains a weekly triage cycle where incoming tickets are categorized, labeled, and commented on often within 48 to 72 hours. Maintainers acknowledge reports by asking for reproduction details, assigning labels, or outlining how the issue fits into the project's alternating "Tick-Tock" release schedule, even if a final patch is deferred to a later release.

Enhancement and feature requests submitted to the issue tracker are systematically reviewed by the maintainers.

More than 50% of these requests receive a response discussing design viability, alignment with the project’s architectural roadmap, or requesting community feedback. Acceptable feature requests are labeled as enhancement or future-release and mapped to future release cycles (such as the alternating Feature Drop releases).

https://github.com/sev7enITA/policywatcher/issues?q=is%3Aissue

The project’s entire history of bug reports, feature requests, comments, triage decisions, and resolutions is publicly archived in the GitHub Issues repository.

This archive is permanent, publicly indexable, and supports extensive search capabilities, enabling users to search historical issues by full-text keyword, status (open/closed), author, label, or milestone.

https://github.com/sev7enITA/policywatcher/blob/main/SECURITY.md (and website page: https://policywatcher.online/security)

The project publishes its vulnerability reporting process in two publicly accessible locations: in the root repository’s SECURITY.md file and on the production web platform at /security.
The project publishes its vulnerability reporting process in two publicly accessible locations: in the root repository’s SECURITY.md file and on the production web platform at /security.

The security policy explicitly defines:
Reporting Channel: Suspected vulnerabilities must be reported privately to security@policywatcher.online (never logged as public GitHub issues).
Details Required: Guidelines on what information to include (reproduction steps, affected endpoints, impact, and PoC details).
Response Targets: Triage timelines (initial acknowledgment within 5 business days, triage within 10 business days).
Scope Guidelines: Clear boundaries on what is in scope (routes, auth logic, scraper controls) and what is out of scope (DDoS testing, social engineering).

https://github.com/sev7enITA/policywatcher/blob/main/SECURITY.md#reporting-a-vulnerability

he project’s security policy provides explicit instructions on how to send vulnerability reports privately:

Private Email Channel: Submitters are instructed to report suspected issues directly and privately to security@policywatcher.online.
Explicit Warning against Public Disclosure: The policy clearly requests that reporters do not disclose the issue publicly (such as via public GitHub issues or public PRs) until it has been triaged and remediated.
Drafting Guidelines: Details the exact private telemetry data, affected endpoints, and logs to include so that maintainers can independently reproduce the finding in isolation.

PolicyWatcher provides a fully automated, scriptable build system. Running the command:
bash

npm run build
automatically triggers the complete compilation pipeline: it first executes prisma generate (to generate the localized database client models from source schema) and then compiles the React application via next build into optimized static and standalone Server-Side Rendered (SSR) chunks.

The project relies exclusively on standard, widely used tools within the modern web development ecosystem: Node.js, npm (Node Package Manager), Prisma CLI, and the Next.js framework compiler. No proprietary compile tools or obscure custom build scripts are necessary to construct the application.

The entire development and build ecosystem of PolicyWatcher is composed of Free/Libre and Open Source Software (FLOSS) tools:

Node.js / Next.js: Licensed under the MIT License.
npm: Licensed under the Artistic License 2.0.
Prisma: Licensed under the Apache 2.0 License.
TypeScript: Licensed under the Apache 2.0 License.
No proprietary software, compilers, or licenses are required to build, test, or deploy the application from source code.

PolicyWatcher uses Vitest, a fast, open-source (MIT Licensed) unit testing framework. The instructions on how to run the test suite are documented in the CONTRIBUTING.md file under the Local Quality Gate section, instructing contributors to run npm run test. The configuration is defined in the public vitest.config.ts file.

The test suite is invocable using the standard command convention for the Node.js/JavaScript ecosystem:
bash

npm run test
This script is mapped inside package.json to trigger the vitest run test execution.

The automated tests target the critical business logic of the platform, including:

Text differences and chunk parsing (diffParse.test.ts)
Data confidence status ranks and normalization (policyConfidence.test.ts)
Subscriber notification filtering logic (subscriberPreferences.test.ts)
Code coverage is monitored and tracked directly using Vitest's built-in coverage features (npm run test:coverage via v8/istanbul engines) to ensure branch coverage of the core algorithms.

The project utilizes GitHub Actions for continuous integration (CI). Every time code is pushed or a Pull Request is opened on the main branch, a workflow (.github/workflows/quality.yml) is automatically triggered to spin up a virtual container, install dependencies, run linter checks (eslint), validate the Prisma database schema, and execute the Vitest test suite to prevent broken code from being integrated.

The project maintains a policy requiring that any major new functionality, core utility, or data-handling updates must be accompanied by new automated tests in the test suite. This ensures that new features are auditable from the moment they are introduced and prevents future regressions.

This policy was strictly adhered to during the recent v3.5 "Confidence Release" update (which introduced status rankings and scraping log pipelines). The release included a new suite of 10 unit tests (policyConfidence.test.ts, diffParse.test.ts, and subscriberPreferences.test.ts) written specifically to cover the newly introduced codebase modules.

The requirement is explicitly documented in the project’s pull request contribution guidelines. Under CONTRIBUTING.md # Pull Requests (Step 4), it instructs contributors to: "Add or update focused tests when changing shared logic, parsing, security, data-quality, or API behavior."

The project utilizes two primary static analysis tools: TypeScript Compiler (tsc): Configured in strict compilation mode (tsconfig.json) to enforce type safety and catch logical errors. ESLint: Enabled with Next.js rules (eslint.config.mjs) to scan the codebase for styling inconsistencies, unused imports, and common JavaScript/React bugs.

All warnings and errors generated by ESLint or the TypeScript compiler must be resolved. The project configuration treats compiler warnings as errors during build runs, and the automated CI pipeline will reject any pull requests containing linting issues or compilation flags.

The project is configured with maximum strictness: TypeScript strict-mode flags are fully enabled, eslint rules are strictly enforced without permissive overrides, and Next.js is configured to fail the production build run if any linter warnings are present.

The primary developers are trained in secure software design principles. This is reflected in PolicyWatcher's architecture: all database interactions utilize parameterized queries, the Content-Security-Policy (CSP) headers block inline scripts, API routes have rate limiters to prevent exhaustion attacks, and the scraper pipeline restricts egress connections to prevent intranet scanning.

Developers are familiar with the OWASP Top 10 vulnerabilities. To counter common errors: SQL Injection: Mitigated by using Prisma ORM parameterization. SSRF (Server-Side Request Forgery): Prevented by checking targets against database policy records rather than resolving untrusted user input, alongside egress IP checking. Cross-Site Scripting (XSS): Blocked via Next.js React automatic escaping and strict HTTP headers.

The application only uses standard, peer-reviewed cryptographic algorithms: SHA-256 for document hashing, HMAC-SHA256 for API webhook validation signatures, and standard scrypt/bcrypt stretching algorithms for password security.

PolicyWatcher does not implement any custom cryptographic routines. It delegates all hashing, encryption, and key generation to Node.js's built-in crypto library module and standard JWT packages.

All cryptographic functions utilized by PolicyWatcher are fully implemented using Free/Libre and Open Source Software (FLOSS) libraries (such as the standard Node.js crypto runtime). No proprietary cryptography software is required

The security mechanisms use keys that meet NIST guidelines (SHA-256 for integrity, minimum 256-bit keys for HMAC-SHA256 signatures). Weak key sizes are completely disabled at the platform and Node.js runtime layers.

The default security mechanisms do not depend on broken cryptographic algorithms (such as MD5, MD4, single DES, or RC4). All security and checksum workflows rely on SHA-256 or HMAC-SHA256.

The project does not use cryptographic algorithms or cipher modes with serious weaknesses (e.g. SHA-1 or CBC modes). It utilizes SHA-256 and authenticated encryption GCM modes where necessary.

The application does not implement custom key agreement or session-negotiation protocols. Perfect Forward Secrecy (PFS) is handled at the transport layer (TLS 1.2 / TLS 1.3) on the hosting server/VPS.

Admin password hashes are generated and validated using Node.js's standard scrypt hashing implementation (which stretches passwords with unique salts to protect against dictionary and precomputed rainbow-table attacks).

All cryptographic keys, API webhook secrets, verification tokens, and session nonces are generated using the Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) in Node.js (crypto.randomBytes or crypto.randomUUID).

The software is distributed exclusively over HTTPS and SSH via GitHub. Deployed environments are configured to serve pages and APIs strictly over HTTPS with HSTS (HTTP Strict Transport Security) enabled.

No executable binaries, updates, or code packages are fetched over insecure channels (HTTP). All external Node module dependencies are retrieved via npm over HTTPS and verified against cryptographic hashes in package-lock.json.

The project contains no unpatched vulnerabilities. Dependency vulnerability scans (GitHub Dependabot, CodeQL alerts) run on every check-in, and flagged third-party library patches are integrated immediately.

The project commits to triaging and patching any critical vulnerability reported to security@policywatcher.online or flagged by automated CI reports rapidly, typically within 24 to 72 hours of disclosure.

The repository is continuously audited to prevent credential leaks. Active keys and passwords are excluded via .gitignore rules, and only public config templates (.env.example) are checked into Git. Secrets are passed dynamically via environment variables.

PolicyWatcher implements two primary static analysis tools on the codebase: ESLint: Standard linter checking coding style, rules, and syntax errors. CodeQL: GitHub’s advanced semantic static analysis suite which scans code logic flows before major releases. SonarQube Cloud configurations are also integrated.

The CodeQL static analysis tool is configured with the standard security-and-quality suite for JavaScript/TypeScript. This includes specific rules designed to identify common software vulnerabilities (such as SQL injection, Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), and path traversal).

Any medium, high, or critical severity vulnerabilities flagged by CodeQL or static linter runs are triaged immediately by the maintainers. They must be resolved and patched before the code changes can be merged into the main branch.

Static code analysis is integrated directly into the CI pipeline. ESLint and CodeQL scans execute automatically on every commit and on every pull request submitted to the GitHub repository, far exceeding the daily scan suggestion.

Dynamic testing is handled by executing the Vitest test runner to test runtime business logic. Additionally, the live deployed application undergoes regular dynamic web application scanning using tools like the MDN HTTP Observatory and SecurityHeaders.com to analyze runtime HTTP response headers, redirection paths, and security headers.

PolicyWatcher is written entirely in TypeScript and JavaScript (which run inside the managed, memory-safe Node.js/V8 environment). The project contains no code written in C, C++, or other memory-unsafe languages.

The project’s test suite uses extensive assertions via Vitest (expect() statements) that run in development and test environments. Additionally, Prisma schema runtime validations and TypeScript strict checks acts as assertions during local runtime execution, while being optimized and stripped in the compiled production build.