Vietnam web governance baseline
NKLattice is a technical release gate for inventoried Next.js, Vite + React and React applications. Its project governance report records the policy, input commit, scanner versions, evidence and result for each required domain. Version 0.5.0 runs eight domains; version 0.4.0 had seven before accessibility and the conditional React library catalog were added. A pass means the configured technical gates passed for the declared apps and analyzed commit. It does not certify a whole information system or an organization’s operations.
Current technical controls
Section titled “Current technical controls”| Decision area | Evidence in version 0.5.0 | Default release gate |
|---|---|---|
| App scope and dependency policy | Exact app inventory; manifest ranges, source imports and npm/pnpm lockfile importers | Every discovered managed app is declared; allowed ranges and locked versions meet the reviewed floors. |
| Architecture | Local JS/TS import graph, source findings and score | Score at least 75; no error finding or module cycle. |
| Dependency security | Native npm/pnpm audit against the lockfile | No known high or critical advisory. A pnpm workspace audit is reported as workspace evidence. |
| Code quality | ESLint, TypeScript, Vitest and V8 line coverage | No lint error; required typecheck and tests pass; line coverage at least 70%. |
| Code security | Semgrep p/ci and Gitleaks |
No high/critical SAST finding and no detected secret. |
| Accessibility | axe-core via Playwright on tested routes | Desktop Chromium and emulated Android Chrome scans with WCAG 2.1 A/AA tags; no violation or inconclusive check. |
| Browser and mobile behavior | Playwright projects for Chromium, Firefox, WebKit, Android Chrome and iPhone Safari emulation | All five projects pass with at least two tests and two viewport widths each. The measured engine version and configured mobile OS user-agent version meet the reviewed test-environment floors. |
Missing, stale or malformed required evidence produces incomplete; a measured breach produces fail. Security findings cannot be hidden by an architecture score. The central policy owns thresholds, so teams can review each change before updating the pinned governance workflow in their repositories.
Relation to Vietnamese references
Section titled “Relation to Vietnamese references”| Reference | Relevance | What NKLattice can substantiate |
|---|---|---|
| TCVN 11930:2017 and Circular 12/2022/TT-BTTTT | Information-system security by level | The report supplies selected code and dependency evidence. System classification, organizational controls, infrastructure, operations and formal assessment remain outside the CLI. |
| Circular 26/2020/TT-BTTTT | Accessibility standards for specified information and public-service sites; other organizations are encouraged to apply them | NKLattice gates automated axe checks on tested routes. Each organization must still determine applicable provisions and perform human accessibility review. |
The default thresholds are a product baseline for web teams serving Vietnam; they are not thresholds prescribed by those documents. A green report must not be described as legal compliance or a security certification.
Evaluated integrations
Section titled “Evaluated integrations”| Need | Current implementation | Candidate and condition for adoption |
|---|---|---|
| Additional vulnerability source | Native npm/pnpm audit | OSV-Scanner could add an advisory source after validating lockfile package coverage and evidence format. It is not run by the current gate. |
| Accessibility | axe-core for Playwright gates tested desktop and emulated Android routes | Untested routes and human review remain outside the verdict. See Accessibility evidence. |
| Declared browser targets | The reviewed Playwright matrix | Browserslist could express supported browser versions, then be checked against actual test projects. A declaration alone would not prove compatibility. |
| Dependency update proposals | Review and update the central policy and consumer SHA | Renovate can propose manifest and lockfile updates. Its PRs still need the governance gate and human review. |
| Physical devices | No physical-device run | BrowserStack Automate exposes web-test sessions with device, OS version, browser version and result. A provider account and real sessions are required; this connector is not in the current CLI. |
The current mobile projects use Playwright emulation. Policy version 5.0.0 retains minimum tested environment versions using minimumTestedBrowserVersions and minimumEmulatedOsVersions; the report shows both measured and required values. A run below a floor is fail, and missing or malformed version evidence is incomplete. These floors prevent CI from silently using an older browser binary or mobile user agent. They do not prove support for every version above the floor, a physical device, or a specific real Android/iOS release. For a buyer that requires specific devices, keep that separate decision incomplete until physical-device evidence is added and reviewed.
Measured sample and physical-device acceptance
Section titled “Measured sample and physical-device acceptance”The public standalone React fixture produced the following browser matrix in main CI on 18 October 2026. These are observed test environments for that fixture, not a minimum supported-browser promise:
| Project | Browser engine recorded | Mobile setting |
|---|---|---|
| Chromium desktop | 156.0.8078.4 | None |
| Firefox desktop | 157.0 | None |
| WebKit desktop | 27.2 | None |
| Android Chrome | Chromium 156.0.8078.4 | Android 14 user-agent emulation |
| iPhone Safari | WebKit 27.2 | iOS 15.0 user-agent emulation |
Each project passed two tests at two viewport widths. This matrix verifies the configured browser projects; it does not prove an Android 14 or iOS 15 physical device was tested.
For a future physical-device rule, NKLattice would need to retrieve the result from the test provider rather than trust a submitted user-agent string. The evidence contract should require a provider session ID, analyzed commit, test time, device model, real_mobile status, OS name/version, browser/version, test count and final result. The BrowserStack Automate build API supplies session metadata, while its session API supplies more test detail. The adapter would also need to verify physical-device status and test counts from the provider or runner, bind the build to the commit, and paginate sessions: the build-detail response alone is capped at 100 recent sessions. A required target with no matching, verified provider session should remain incomplete; a failed session should be fail. This is a proposed adapter, not a shipped scan or a present-day report claim.