Platform Build Drift

This page describes the nowisor-platform-build-drift check from the nowisor Instance Scan Pack v1.0.0. The check reads the glide.buildtag.last system property and matches it against the platform releases nowisor has verified against (currently Zurich Patch 6 and Australia GA + patches). A finding fires when the instance is running a build outside the verified set. The check is operational quality assurance, not a security finding per se — it signals that other findings may be unreliable due to schema drift between the pack's baseline and the instance's actual platform.

What this finding means

Your instance is running a ServiceNow build that nowisor v1.0.0 has not been explicitly verified against. The check uses regex patterns to match the buildtag against supported baselines:

• Zurich Patch 6 — the primary verification baseline. Build tag matches /zurich.*patch6/i. This is the release nowisor v1.0.0's property names, table schemas, and detection predicates were validated on.
• Australia GA and patches — secondary verification baseline. Build tag matches /^glide-australia/i or /australia.*patch[0-9]+/i. The pack was structurally verified against Australia though some checks have less behavioral validation here than on Zurich.

If your buildtag matches neither pattern, the check fires. You're running either an older release (Washington, Xanadu, Yokohama) or a newer release that hasn't yet been added to nowisor's verification baseline.

The finding is operational, not security-attack-focused. It doesn't mean an attacker is doing something to your instance; it means the pack's predicates may produce false positives (flagging properties that have been renamed or removed in your release) or false negatives (missing patterns that exist in your release but not in the verified baseline). The reliability of every other finding is conditional on the platform build matching.

Why it matters for your compliance

This is configuration-management evidence, not a direct security control.

NIS2 Article 21§2(a) — risk analysis and information system security policies. Your security posture documentation makes implicit assumptions about the platform version it's authored against. When the platform drifts to an unverified version, the assumptions need to be re-validated. NIS2 expects entities to maintain configuration awareness; the finding surfaces drift.

ISO 27001 A.8.32 — change management. A.8.32 covers change management for ICT systems. Platform version is the most-impactful change vector — every patch can shift property defaults, add new tables, deprecate old APIs. The finding aligns with A.8.32's expectation that the entity tracks platform version against tooling baselines.

Severity 3 (medium) because the finding indicates quality-assurance uncertainty rather than active exposure. A finding doesn't mean your instance is compromised; it means your scan output should be interpreted with extra care until nowisor's baseline catches up to your platform version.

How to fix it

Two paths:

Path 1 — Upgrade or downgrade to a supported build. If your instance is on an older release, upgrade to Zurich Patch 6 (or the latest verified release per the nowisor pack version you're running). If the instance is on a newer release that nowisor hasn't yet caught up to, you have the choice of staying on the latest release and accepting the uncertainty, or waiting for the next nowisor pack version that adds your build to the verification baseline.

Path 2 — Document the exception and continue. For instances that genuinely need to operate on an unsupported build (e.g., regulated environments with mandatory patch lag, or instances on a release nowisor has not yet caught up to), document the exception in your security posture documentation. Note that nowisor scan findings on this instance should be reviewed manually for release-specific drift before being treated as authoritative.

How to verify the fix

/*
 * Verify nowisor-platform-build-drift
 * Read-only, safe for production.
 * Reports the current build tag and supported patterns.
 */
(function checkBuildDrift() {
    var SENTINEL = '__NOT_REGISTERED__';
    var buildTag = gs.getProperty('glide.buildtag.last', SENTINEL);
    gs.print('Current build tag: ' + buildTag);

    var patterns = [
        { name: 'Zurich Patch 6', re: /zurich.*patch6/i },
        { name: 'Australia GA', re: /^glide-australia/i },
        { name: 'Australia Patch N', re: /australia.*patch[0-9]+/i }
    ];

    var matched = false;
    for (var i = 0; i < patterns.length; i++) {
        if (patterns[i].re.test(buildTag)) {
            gs.print('[PASS] Matches: ' + patterns[i].name);
            matched = true;
            break;
        }
    }
    if (!matched) {
        gs.print('[FAIL] Unverified build. nowisor findings on this instance should be reviewed manually.');
    }
})();

If you upgrade or downgrade, re-run the scan; the check should clear.

What to do next

The build-drift check is part of the operational-integrity cluster:

• nowisor-meta-active-check-coverage — confirms the pack is installed. Build-drift may explain why a deactivated check was deactivated (release incompatibility).
• nowisor-fabricated-property-references — property names can rename between releases. A drift finding may correlate with an increase in fabricated-property findings if the rename happened in your direction.

For organizations managing many instances with mixed release cadence (production on the previous LTS, sub-prod on the current release, dev on the latest), the nowisor advisor product is being built to report build-drift across the instance fleet so you can plan upgrade cadence with full visibility into where scan findings are most reliable. See the build-drift fleet view →