← All KB Checks
MEDIUMScriptOnlyCheck

Meta — Active Check Coverage

nowisor-meta-active-check-coverage··Source on GitHub →

Meta — Active Check Coverage

This page describes the nowisor-meta-active-check-coverage check from the nowisor Instance Scan Pack. The check is a self-meta operational telemetry check — it verifies that every active check in the pack is installed and active in the x_nowisor_isp scope. A healthy install produces zero findings. A finding indicates the pack is partially uninstalled or some checks have been deactivated.

What this finding means

The check counts active records across the four Instance Scan check tables (scan_script_only_check, scan_table_check, scan_linter_check, scan_column_type_check) filtered to the x_nowisor_isp scope with active = true. The expected total is the pack's active inventory — currently 47. If the count is below that number, the check fires a single aggregate finding listing which expected checks are missing or inactive.

This is the only check in the pack that carries no framework mappings. The reason: it's not a security control — it's an installation health indicator. The check exists to give operators visibility into whether the pack's protection is actually in place. A check that thinks it's running but isn't installed produces zero findings forever, and zero findings looks like compliance. The meta check is the structural defense against that false-positive failure mode.

Note: deferred checks (nowisor-hardcoded-credentials and nowisor-direct-property-write) ship with active: false in the manifest. Those are expected to be inactive. The check accounts for this — it expects 47 active checks plus 2 deferred = 49 total recorded, with the 2 deferred being legitimately inactive. If the count of active checks drops below 47, the finding fires.

This expected count is a literal in an ES5 script that runs inside your instance, so it cannot read the manifest at runtime. It was left at 26 while the pack grew to 49, which — because the comparison is totalActive >= EXPECTED_COUNT — meant this check reported a clean install on an instance missing up to 21 checks. It is now pinned to the manifest by a build-time test.

Why it matters for your compliance

This is operational telemetry, not a regulatory control. The empty framework_mappings field is correct, not an omission.

However, the operational state matters for compliance evidence. If your compliance documentation says "we run the nowisor Instance Scan Pack monthly to detect platform security misconfigurations," the implicit claim is that the pack is actually installed and active. This check is the structural verification of that claim — auditors who probe deeply enough to ask "how do you know the pack is running?" can be answered with "this check confirms it; here's the scan output."

How to fix it

If the check fires, the pack install is incomplete or partially deactivated. Three remediation paths:

  1. Re-run the pack installer. Restore missing checks via npx now-sdk install --reinstall (or the equivalent SDK command for your install path). After reinstall, re-run the suite bootstrap to link the restored checks to the suite.

  2. Audit and reactivate. Navigate to the Instance Scan check tables (scan_script_only_check.list, scan_table_check.list, scan_linter_check.list, scan_column_type_check.list) filtered by sys_scope = x_nowisor_isp, identify inactive entries, and reactivate them.

  3. Document intentional deactivation. If a specific check was deactivated for a defensible operational reason (it conflicts with local policy, it produces unmanageable false-positive volume on your instance), document the exception. The exception is a known issue in your security posture documentation; the documentation is what compliance asks for.

How to verify the fix

/*
 * Verify nowisor-meta-active-check-coverage
 * Read-only, safe for production.
 * Counts active nowisor checks across all four scan check tables.
 */
(function verifyMetaCoverage() {
    var tables = [
        'scan_script_only_check',
        'scan_table_check',
        'scan_linter_check',
        'scan_column_type_check'
    ];
    var EXPECTED_ACTIVE = 47;  // 49 total minus 2 deferred
    var total = 0;
    for (var i = 0; i < tables.length; i++) {
        var gr = new GlideRecord(tables[i]);
        gr.addQuery('sys_scope.scope', 'x_nowisor_isp');
        gr.addQuery('active', true);
        gr.query();
        var n = gr.getRowCount();
        total += n;
        gs.print('  ' + tables[i] + ': ' + n);
    }
    gs.print('');
    gs.print('Total active: ' + total + ' (expected: ' + EXPECTED_ACTIVE + ')');
    if (total >= EXPECTED_ACTIVE) {
        gs.print('[PASS] Coverage complete.');
    } else {
        gs.print('[FAIL] ' + (EXPECTED_ACTIVE - total) + ' check(s) inactive or missing.');
    }
})();

After remediation, the total should be 24 or more (depending on which deferred checks have been reactivated in subsequent pack releases).

What to do next

The meta-coverage check is part of the operational-integrity cluster:

A note on this check's role: this check is what an operator can run after install to confirm everything is in place — before relying on the other 48 checks for actual security signal. It's the "did the deployment work?" verification. See the operational-integrity view →

Related checks

← All KB Checks