Creating your own Instance Scan, Scan Checks

[Mark Roethof]

Hi there,

Instance Scan, one of the great new features from the Quebec-release. Wrong! For all you out there still on the Paris-release or even the Orlando-release… Instance Scan is already on your instances. It's good to have that said 🙂

So how to use the Instance Scan?

I'll be sharing a few blogs on Instance Scan:
- Using Instance Scan on Orlando/Paris instances
- Creating your own Instance Scan, Scan Checks
- Unrevealing Instance Scan and sharing parts of the undocumented

The first blog to share how to get to the hidden Instance Scan on Orlando/Paris instances and to mention some of the differences to expect as opposed to Quebec.
The second blog to share experiences gained on how to build your own Scan Checks. At this moment, there's zero official ServiceNow documentation on this.
The third blog to share some thoughts and experiences I've gained the past few weeks on Instance Scan, to fill in some blanks because documentation on Instance Scan is really missing out there.

Let's get after it!

Scan Checks

In the Orlando/Paris release, there are three different types of Scan Checks available, while with the Quebec release a fourth type has been added.
- Table Check
- Column Type Check
- Script Only Check
- Linter Check [Quebec]

Common between the Scan Checks

These Scan Checks all have their own specifics, though let's first have a look at what is common.

Pretty straight forward. All of this information will be seen when working with actual Scan Results and Scan Findings. Name and Short Description feels a bit double, but oke. The Description and Resolution Details are the massive parts here in my opinion. Try to describe your Scan Check thoroughly, and what should be done to resolve any findings.

With the Quebec release, ServiceNow added the field Run Condition. You could leave it blank, though you could also use this to check for example if a certain plugin is installed, if it concerns a production environment, or if you are providing checks to multiple customers maybe you would like to check the Release the instance runs on, etcetera.
The condition only needs to evaluate to true (or it should be blank).

Differences between the Scan Checks

All four Scan Checks also contain a Script field. For the Table Check the Script field is optional, as you can create Table Checks using the Condition Builder. For the other Scan Checks the Script field is mandatory to use (not mandatory by dictionary attribute, though not using it won't populate any findings).

Table Check
As mentioned, the Table Check contains a Conditions field with which you can use the Condition Builder to create your Scan Check. The Condition Builder will list fields, based on the Table field. Optionally you could use the Script field, or also a combination of the Conditions field and the Script field.

An unknown one for me is the Use Upgrade Manifest field which is only available on the Table Check. No clue yet what this does. It's a true/false type field, and no of the out-of-the-box Table Checks are using this field.

Column Type Check
The Column Type Check contains a specific Column Type choice field that holds choices Script, XML, and HTML. This field let's you choose which type of fields to scan, so actually all Script fields or all XML fields or all HTML fields! This one is massive!!!

Script Only Check
No specifics.

Linter Check
No specific.

What can you do with the different types of Scan Checks

What the different types of Scan Checks can do, is one of the few things that kind of document. The Docs mentions:

"Table Check
Create a check by selecting Create a new Table Check if you know which specific table and conditions you want to test. This check type is applied on only one table at a time. You can also include your own script for more complex capabilities by selecting the Advanced option on the form.

Column Type Check
Retrieve all records containing a specific column field type from all tables in an instance by selecting Create a new Column Type Check. The Column Type Check type implements the rule you created to iterate all records matching the target column field type.

Script Only Check
Create a check without specifying a table or a column type by selecting Create a new Script Only Check. You can verify meta data, configurations, and execute complex checks by writing your own script.

Linter Check
Create a linter check to identify any issues in a script. When a linter check is run on a record, an abstract syntax tree for its code is generated. You can use the abstract syntax tree to analyze issues with the code."

Good to add. When working with the Script field on the Table Check and Column Type Check, you have to provide:
finding.increment()

While if you are working with the Script field on the Script Only Check, you have to provide: finding.increment() plus:
finding.setCurrentSource(<gliderecord object>)

The usage of these, is what actually creates a Scan Finding!

Customer updates - out-of-the-box artifacts

Good to mention, the Table Check and the Column Type Check will only scan customer updates. The Script Only Check will also scan out-of-the-box artifacts.
And the Linter Check… no clue. Haven't got this one working, no example checks, no documentation.

Only customer updates you say, so why am I also getting results on tables like asmt_metric, sp_instance, sys_script_execution_history... just because these are not seen as out-of-the-box artifacts. Getting findings on records like sys_script_execution_history is really annoying, you are not going to do anything with this 😞 Apart from deleting such scan_findings through a Business Rule or Flow, I haven't found a good solution. Only if we know what the finding or engine object holds... who knows that might give us some valuable info.

Any examples of Scripted custom Scan Checks?

I can't share all of the 350+ custom Scan Checks I've created, though some scripted examples should be okay. Scripted examples, where the script you could for example use GlideRecord queries, or compare system properties, etcetera. So mostly general ServiceNow scripting can be used here.

[Table Check] getMessage() called in Client Script without preloading message key

"Use the messages field to enter message strings that the client script can use as a key to look up a localized message alternative from the Message [sys_ui_message] table. Add each message key on a separate line. The instance looks for a localized message string anytime the client script makes a getMessage(msg) call where the msg string matches a key in the Messages field."

"Apply the string used in getMessage() to the messages field."

[Column Type Check] Reduce activity in Loops

"Loops are often used in programming. Each statement in a loop, including the for statement, is executed for each iteration of the loop. Statements or assignments that can be placed outside the loop will make the loop run faster."

"Bad:
for (var i = 0; i < arr.length; i++) {

Better Code:
var l = arr.length;
for (var i = 0; i < l; i++) {"

[Script Only Check] (Scheduled) Test suite execution should be disabled on production instances

"By default, the system property that is used to run automated tests is disabled to prevent you from accidentally running these tests on a production system."

"1. Navigate to <instance_name>.service-now.com/sys_properties_list.do
2. Search for the sys_properties record with the following parameters:
Name: sn_atf.runner.enabled
Type: true | false
3. Set/Update the following parameters:
Value: false"

[Script Only Check] Remove unused inactivity monitors

"These are a way to generate inactivity reminders. Unfortunately there's no active field on these and unless you are aware of them, they will continue to generate events."

"Remove unused inactivity monitors."

Unknowns

With the Quebec release new fields Score Max, Score Min, Scoring Scale have been added to the Scan Checks. Haven't tested these out yet, though sounds like these would be used to make the weighting of the Scores more specific. With Quebec also a Score Table has been added, which actually calculated scores for each Scan Result. Though somehow this Scan Table has not been made visible in a Dashboard, Related List, etc..

As mentioned, the Linter Check… what this does, how to get it working, etc.: no clue 😞

Object finding versus object engine. The example script within Orlando/Paris as well as the out-of-the-box Scan Checks, all use the finding object. With Quebec, the example script has been updated to use the engine object. These are different, though what the differences are, how engine is supposed to work, etc.: no clue. Again, no example checks, no documentation. Just replacing finding with engine does at least not work 🙂
I did try to debug finding and engine. Though haven't gotten more out of it than [Object finding] or [Object engine].

Scan Check Mute

Hé, wait! What about muting a Scan Check? This is available in Orlando/Paris right?! Yes... though with Quebec this is deprecated 🙂

This is a bit unfortunate in my opinion. Sure you can make a Scan Check active true/false. Though not for the out-of-the-box Scan Checks. These are all read-only... so you are stuck with these since muting them is not an option anymore with the Quebec release.

Is that it?!

Pfff… yes 🙂 Hope this additional background on Instance Scan, Scan Checks helps some people/companies. You can limit yourself by just using the out-of-the-box Scan Checks, or you could go for massively using the Instance Scan with your own Scan Checks!

---

If any questions or remarks, let me know!

👍	If this post helped you in any way, I would appreciate it if you hit bookmark or mark it as helpful. Interested in more articles, blogs, videos, and Share Projects on Instance Scan I published? - Instance Scan

Kind regards,
Mark
2020-2021 ServiceNow Community MVP
2020-2021 ServiceNow Developer MVP

---

LinkedIn