Detection Methodology

Detection

(objective) A write/create/delete ACL exists with no condition, no script, and no required role, created by a named (non-vendor) account.

Recommendation

(guidance) Add a required role or restricting condition/script to this ACL. Customer-introduced open write access is the highest-priority ACL risk.

Source

ServiceNow Access Control (ACL) rules documentation; ACLs must grant the minimum access required. (NIST least-privilege / access-control principles.)

Confidence

high — Structural and exact: the ACL grants a write/create/delete operation with no condition, no script, and no required role, and was created by a named human. No inference over free text.

Why this severity

Critical: a customer-introduced write ACL with no restriction lets any authenticated user modify the protected data — direct, exploitable integrity exposure the customer owns.

When it's acceptable

Acceptable only if the table is intentionally world-writable (rare). Confirm intent; if deliberate, document the exception.

Documentation reference →

Detection

(objective) An admin-class account created a write ACL on a sensitive table (identity/auth/credentials/HR) with no condition, script, or role.

Recommendation

(guidance) Confirm this open write access to a sensitive table is intended. Verify it was deliberate; add a role or condition otherwise.

Source

ServiceNow Access Control documentation; sensitive tables (identity, auth, credentials, HR) warrant tighter restriction.

Confidence

high — Exact structural match plus the target table matching a curated sensitive-table pattern; author class is read from the record.

Why this severity

High not Critical: created by an admin-class account on this instance (a privileged human decision worth review) rather than an arbitrary user, but on a sensitive table — so above a non-sensitive open ACL.

When it's acceptable

An admin may have deliberately opened this for a documented integration. Review-only: confirm the decision was intentional.

Documentation reference →

Detection

(objective) A ServiceNow-internal account shipped a write ACL on a sensitive table with no condition, script, or role.

Recommendation

(guidance) Confirm the vendor-default exposure matches your security expectations; raise with ServiceNow support if it does not. No customer remediation is implied.

Source

ServiceNow Access Control documentation; surfaced for completeness as vendor baseline posture.

Confidence

high — Structural match; authored by a ServiceNow-internal account (system / *@snc / now.*), so classified as vendor-shipped.

Why this severity

High by pattern, but technical-tier: it is ServiceNow's baseline, not customer-introduced — it never drives the customer's grade.

When it's acceptable

Expected vendor default in most instances. Informational unless your security posture requires raising it with ServiceNow.

Documentation reference →

Detection

(objective) A system/admin account created a write ACL on a non-sensitive table with no condition, script, or role.

Recommendation

(guidance) Review whether this open write access is intended. Baseline platform ACLs are usually deliberate; admin-created ones warrant confirmation.

Source

ServiceNow Access Control documentation.

Confidence

high — Exact structural match; non-sensitive table; author class read from the record.

Why this severity

High pattern but technical-tier: open write on a non-sensitive system table is frequently intentional baseline behaviour; surfaced for review, not executive prioritization.

When it's acceptable

Often deliberate. Review-only.

Documentation reference →

Detection

(objective) A named account created a read ACL on a sensitive table with no condition, script, or role.

Recommendation

(guidance) Add a required role or condition. Sensitive-table read exposure introduced by a customer is a real data-exposure risk.

Source

ServiceNow Access Control documentation; data-exposure prevention on sensitive tables. (OWASP sensitive-data-exposure principles.)

Confidence

high — Structural: open READ on a sensitive table, no condition/script/role, customer-authored.

Why this severity

High: a customer-introduced read exposure on identity/credential/HR data is a real confidentiality risk, though read (not write) so below the Critical write case.

When it's acceptable

Acceptable if the data is intended to be broadly readable. Confirm the sensitive table truly holds non-confidential rows.

Documentation reference →

Detection

(objective) A system/admin account created a read ACL on a sensitive table with no condition, script, or role.

Recommendation

(guidance) Confirm the baseline exposure is expected; treat admin-created sensitive reads as review items.

Source

ServiceNow Access Control documentation.

Confidence

high — Structural match; system/admin-authored.

Why this severity

Medium, technical-tier: frequently OOB behaviour on sensitive tables; worth a review pass, not executive attention.

When it's acceptable

Commonly a baseline default. Review-only.

Documentation reference →

Detection

(objective) An open ACL exists that is neither a modify operation nor a sensitive read.

Recommendation

(guidance) No action required in most cases. Included for completeness in the technical appendix; hidden from the default report.

Source

ServiceNow Access Control documentation.

Confidence

high — Structural catch-all for open ACLs that are neither a modify op nor a sensitive read.

Why this severity

Informational, hidden tier: usually benign baseline behaviour; included only for completeness.

When it's acceptable

Almost always acceptable. Hidden from the default report by design.

Documentation reference →

Detection

(objective) A server script invokes eval / GlideEvaluator / GlideScopedEvaluator.

Recommendation

(guidance) Replace dynamic evaluation with explicit logic or a vetted allow-list dispatch. Remove eval()/GlideEvaluator from server scripts.

Source

ServiceNow Secure Coding guidelines; avoid dynamic evaluation of strings in server scripts. (OWASP Code Injection (A03).)

Confidence

high — Deterministic regex for eval / GlideEvaluator / GlideScopedEvaluator invocation; a match is a genuine use, not a guess.

Why this severity

High: dynamic evaluation is a code-injection vector and defeats static analysis; not Critical because exploitability depends on whether attacker-controlled input reaches it.

When it's acceptable

A vetted, constant-only argument may be safe. Review the argument source; refactor regardless where practical.

Documentation reference →

Detection

(objective) An active scheduled job runs as admin / security_admin / maint, created by a non-vendor account.

Recommendation

(guidance) Run scheduled jobs as a least-privilege service account with only the roles the job requires.

Source

ServiceNow Scheduled Jobs documentation; run jobs with least privilege. (NIST least-privilege.)

Confidence

high — Exact field read: run_as in {admin, security_admin, maint} AND active=true AND customer-authored.

Why this severity

High: an active job running as admin has instance-wide blast radius if it misbehaves or is compromised; scoped to active + customer-authored to avoid noise.

When it's acceptable

A job may genuinely require elevated rights. Review whether a least-privilege service account would suffice.

Documentation reference →

Detection

(objective) A client-callable Script Include builds a GlideRecord from a table name traceable to an AJAX parameter (direct or bounded same-scope assignment).

Recommendation

(guidance) Validate/allow-list the table name against a fixed set; never pass an AJAX parameter directly into new GlideRecord(). Add role checks before the query.

Source

OWASP Injection (A03) — user-controlled input flowing into a data query. (ServiceNow Script Include documentation.)

Confidence

medium — Strong but not proof: requires a client-callable include building a GlideRecord from a variable table AND a traceable getParameter→table flow (direct or bounded same-scope assignment). The declarative engine cannot resolve multi-step or cross-method flow, so it stays review-tier.

Why this severity

High: table/query injection reachable from the browser is a serious data-exposure path when the flow is real.

When it's acceptable

Acceptable if the table name is validated/allow-listed downstream in a way the regex cannot see. Confirm the parameter cannot influence the query.

Documentation reference →

Detection

(objective) A client-callable Script Include queries a sensitive table via GlideRecord with no visible authorization pattern.

Recommendation

(guidance) Add an explicit role check before the query, or use GlideRecordSecure so ACLs apply. Confirm the data returned is appropriate for a client caller.

Source

ServiceNow Script Include documentation; enforce authorization before returning data. (OWASP Broken Access Control (A01).)

Confidence

medium — Signal, not proof: a client-callable include queries a sensitive table with no visible authorization pattern. Absence of an authz pattern is suggestive; the check cannot prove none runs on every path.

Why this severity

High: browser-reachable read of identity/credential/HR data without an evident permission check is a plausible exposure.

When it's acceptable

Authorization may be enforced by a helper the regex cannot see, or the caller may be restricted elsewhere. Review-only.

Documentation reference →

Detection

(objective) A client-callable Script Include uses a dynamic table and reads AJAX input, but the parameter cannot be traced into the table argument.

Recommendation

(guidance) Confirm whether any AJAX parameter can influence the table/query. If so, allow-list the table name and add a role check. If the dynamic table is a fixed internal value, no action.

Source

OWASP Injection (A03). (ServiceNow Script Include documentation.)

Confidence

medium — Weaker than the traceable case: a dynamic table and AJAX input merely coexist; the parameter could not be traced into the table argument. Surfaced for manual review.

Why this severity

Medium, technical-tier: a possible injection path that the engine could not confirm — worth a look, below a traceable high.

When it's acceptable

Common when the dynamic table is a fixed internal value unrelated to the parameter. Review-only.

Documentation reference →

Detection

(objective) A client-callable Script Include runs a GlideRecord on a non-sensitive table with no visible authorization pattern.

Recommendation

(guidance) Confirm the data is appropriate to expose to client callers; add a role check or GlideRecordSecure if not.

Source

ServiceNow Script Include documentation; client-callable data access should be authorization-aware. (OWASP Broken Access Control (A01).)

Confidence

medium — A client-callable include runs a GlideRecord on a non-sensitive table with no visible authorization pattern — a signal, not proof.

Why this severity

Medium: lower risk than sensitive or injection cases, but broader exposure than a pure utility; technical-tier.

When it's acceptable

The data may be appropriate to expose to client callers. Review-only.

Documentation reference →

Detection

(objective) A client-callable Script Include queries data AND contains an authorization pattern (unverified as to ordering/coverage).

Recommendation

(guidance) Verify the authorization runs before any data access on every code path exposed to the client.

Source

ServiceNow Script Include documentation.

Confidence

low — The include has an authorization pattern present; the check cannot verify it runs before the sensitive work on every AJAX-reachable path. Surfaced, not cleared.

Why this severity

Informational, technical-tier: an authz pattern exists — most likely fine, flagged only for completeness of the partition.

When it's acceptable

Usually acceptable. Informational.

Documentation reference →

Detection

(objective) A client-callable Script Include with no direct GlideRecord access.

Recommendation

(guidance) No action in most cases. Review only if it delegates to helpers that access data.

Source

InstanceGuard partition completeness — no ServiceNow guidance implied; a utility include with no direct data access.

Confidence

low — 'No direct GlideRecord observed' is not 'safe' — it may delegate to helpers. Purely a partition bucket.

Why this severity

Informational, hidden: no action implied; exists so the client-callable partition is exhaustive and mutually exclusive.

When it's acceptable

Not a risk finding. Hidden by design.

Documentation reference →

Detection

(objective) An internal integration user holds a write/admin-class role (admin/itil/security_admin/sn_incident_write).

Recommendation

(guidance) Strip write/admin roles from integration accounts. Grant only the specific read roles required by the integration.

Source

ServiceNow Integration User documentation; integration accounts should hold only the roles the integration requires. (NIST least-privilege.)

Confidence

high — Exact join: an internal integration user holds a write/admin-class role. Read directly from sys_user_has_role.

Why this severity

High: a write/admin-capable integration credential is a high-value target and violates least privilege; suppressed when snc_read_only neutralizes the role.

When it's acceptable

The integration may genuinely require the role. Suppressed already when platform-enforced read-only applies; otherwise confirm necessity.

Documentation reference →

Detection

(objective) A client script instantiates new GlideRecord(), created by a non-vendor account.

Recommendation

(guidance) Move the query server-side into a client-callable Script Include and call it asynchronously via GlideAjax getXMLAnswer.

Source

ServiceNow Client Scripts best practices; do not use GlideRecord on the client.

Confidence

high — Regex for new GlideRecord( inside a client script — the exact documented anti-pattern.

Why this severity

High: forces synchronous server round-trips that block the UI and worsen under load; a direct, felt performance regression.

When it's acceptable

Rarely acceptable. A legacy script pending refactor may be low-traffic; still worth remediation.

Documentation reference →

Detection

(objective) A client script calls getXMLWait() (synchronous GlideAjax), created by a non-vendor account.

Recommendation

(guidance) Replace getXMLWait with the asynchronous getXMLAnswer/getXML callback pattern.

Source

ServiceNow GlideAjax documentation; getXMLWait is synchronous and discouraged.

Confidence

high — Regex for getXMLWait( — an exact call to a discouraged synchronous API.

Why this severity

High: blocks the browser thread until the server responds, freezing the form; degrades sharply under load.

When it's acceptable

Occasionally used intentionally in a constrained flow; the asynchronous callback pattern is almost always preferable.

Documentation reference →

Detection

(objective) A script builds an encoded query with a leading CONTAINS/LIKE/STARTSWITH or ORDERBY pattern, created by a non-vendor account.

Recommendation

(guidance) Filter on an indexed field first, avoid leading-wildcard CONTAINS, and add a database index where the access pattern justifies it.

Source

InstanceGuard operational heuristic informed by ServiceNow Table Administration (indexing) guidance — flags likely full-table-scan patterns; ServiceNow does not publish this specific rule. (ServiceNow Table Administration / database index documentation.)

Confidence

medium — Heuristic over the query string (leading CONTAINS/LIKE/ORDERBY): a likely-slow pattern, but true cost depends on data volume and actual indexes, which a read-only scan cannot see.

Why this severity

Medium: performance degrades with data growth, but impact is conditional on volume; not a security or correctness issue.

When it's acceptable

Acceptable on small tables or where a suitable index exists. Confirm against the table's size and indexes.

Documentation reference →

Detection

(objective) A customer update record flags replace_on_upgrade on a baseline-named record (in-place edit of an OOB artifact).

Recommendation

(guidance) Deactivate and clone the OOB record, or extend behaviour in a scoped/custom artifact instead of editing the baseline.

Source

ServiceNow Upgrades & Skipped Records documentation; do not modify baseline records in place.

Confidence

high — Structural: a customer update to a baseline record flagged replace_on_upgrade with a baseline-shaped name. Directly matches the documented skip mechanism.

Why this severity

High: in-place baseline edits cause upgrade skips and silent reverts — real, recurring upgrade cost and risk.

When it's acceptable

A deliberate, documented override may be intended. Review whether a scoped/extended artifact would be cleaner.

Documentation reference →

Detection

(objective) A script contains a 32-character hex literal (likely a hardcoded sys_id), created by a non-vendor account.

Recommendation

(guidance) Look records up by a stable key (name, number, property) or store the reference in a system property, not a literal sys_id.

Source

ServiceNow Secure Coding / best-practice guidance; avoid hardcoded sys_ids.

Confidence

medium — Regex for a 32-char hex literal in a script — a strong indicator, but some 32-hex literals are not sys_ids (hashes, tokens).

Why this severity

Medium: breaks across clones/environments and after reimports, but is a maintainability/portability issue rather than a direct security or availability risk.

When it's acceptable

The literal may be a non-sys_id hash or an intentional, stable reference. Review the usage.

Documentation reference →

Detection

(objective) A business rule calls current.update() without a setWorkflow(false) guard, created by a non-vendor account.

Recommendation

(guidance) Avoid current.update() in business rules; mutate fields on current in before rules (auto-persisted) or guard with setWorkflow(false) where an explicit update is unavoidable.

Source

ServiceNow Business Rules documentation; avoid current.update() inside a rule (recursion).

Confidence

high — Regex for current.update( without a setWorkflow(false) guard — the documented recursion anti-pattern.

Why this severity

High: can re-trigger the rule set causing recursion, duplicate side effects, and hard-to-trace loops.

When it's acceptable

A guarded or intentional single-pass update may be safe. Review whether the update is necessary and bounded.

Documentation reference →

Detection

(objective) A before business rule calls setWorkflow(false), created by a non-vendor account.

Recommendation

(guidance) Remove setWorkflow(false) unless deliberately bypassing automation, and document the reason inline when it is intentional.

Source

InstanceGuard maintainability heuristic — setWorkflow(false) in a before rule silently suppresses downstream automation; ServiceNow documents the API but not this as a defect. (ServiceNow Business Rules documentation.)

Confidence

medium — Exact match of a before rule using setWorkflow(false); whether it is a defect depends on intent, which the scan cannot read.

Why this severity

Medium: a frequent source of 'why did automation not fire' defects, but often deliberate; a maintainability concern, not a security risk.

When it's acceptable

Frequently intentional (deliberately bypassing automation). Should be documented inline; review-only.

Documentation reference →

Detection

(objective) A single non-platform account produced more than 150 configuration-change records in a 7-day window.

Recommendation

(guidance) Investigate the change burst, confirm it went through update-set review, and enforce peer review / change windows for high-volume contributors.

Source

InstanceGuard governance heuristic — a single account making >150 configuration changes in 7 days signals unreviewed bulk change. ServiceNow does not publish this threshold; it is derived from operational experience. (ServiceNow Update Sets / change-control documentation.)

Confidence

medium — The count is exact; the >150/7-day THRESHOLD is an InstanceGuard judgement, and high velocity is not itself proof of a governance failure.

Why this severity

High: concentrated unreviewed change materially raises regression risk — but review-only, because legitimate bulk work (migrations) can trip it.

When it's acceptable

A sanctioned migration or data load can legitimately exceed the threshold. Confirm the burst went through update-set review.

Documentation reference →

Detection

(objective) Four or more recent Script Includes exceed a normalized-token similarity threshold (a uniform-style cluster).

Recommendation

(guidance) Review the clustered artifacts for correctness, test coverage, and ownership. Confirm they were authored/reviewed by a human, regardless of tooling used.

Source

InstanceGuard heuristic — a tight cluster of near-identical recent Script Includes is CONSISTENT WITH bulk generation. This is not a ServiceNow concept and is explicitly not proof of AI authorship.

Confidence

low — A similarity signal only. Uniform style has many innocent causes (a template, one author, a framework). Deliberately informational and review-only.

Why this severity

Informational: a prompt to review recently-added, similar artifacts for correctness and ownership — never an assertion of wrongdoing.

When it's acceptable

Very common and legitimate (shared template, single prolific author). Review-only; treat as a nudge, not a defect.

Documentation reference →

Detection

(objective) An integration account produced more than 75 configuration-change records in a 7-day window.

Recommendation

(guidance) Confirm the automation account is authorized to make configuration changes, and route agent-driven changes through the same approval gates as human changes.

Source

InstanceGuard heuristic — rapid configuration change from a non-interactive integration account may indicate autonomous/agent-driven change without human review. Not a ServiceNow concept. (ServiceNow Integration User documentation.)

Confidence

low — Velocity from an integration account is suggestive, not proof of unreviewed or AI-driven change; the threshold is an InstanceGuard judgement.

Why this severity

High if real (agent-driven config change bypassing review is a genuine governance gap), but review-only and low-confidence because legitimate integrations also change config quickly.

When it's acceptable

A sanctioned integration that legitimately maintains configuration. Confirm the account is authorized and its changes are gated.

Documentation reference →