How to handle temporary / ephemeral builds with Vulnerability Response

[rogerburns]

We have an issue with temporary or ephemeral builds that are built on a network, scanned by our VR scanner (CrowdStrike) and then patched. After the patching process, the builder then captures the snapshot of the build and then destroys it.  However, due to latency the integration with CrowdStrike will then insert a Discovered Item as it cannot find a matching device and populates it with many VITs.  This then requires someone to find that DI and reclassify something that is not even active anymore.  This causes a lot of rework and we are looking to find out how other organizations are handling those temporary builds with regards to VR. 

[Matthew_13 · Accepted solution]

Hi Buddy,

What’s happening is basically a timing issue. The build VM exists just long enough to get scanned, but by the time CrowdStrike sends the data into ServiceNow, the VM has already been patched, snapshotted, and destroyed. When ServiceNow can’t find a matching device anymore, it creates a Discovered Item and attaches a bunch of vulnerabilities to it. Since that build no longer exists, someone then has to clean it up manually — which is pure rework.

There isn’t really a setting that says dont create discovered items for short-lived hosts. Most organizations I have seen handle this by treating ephemeral build systems as out of scope for Vulnerability Response.

The most common approach is to filter them out so they never turn into actionable vulnerability records in the first place — usually by hostname pattern, subnet, or CrowdStrike group/tag. That way the data can still come in, but it doesn’t create noise that someone has to triage.

If teams still want the data to land, the next best option is to auto-close it quickly. When the build is destroyed, the CI is marked retired or simply stops reporting and auto-close rules clean up the vulnerabilities without human involvement.

In the end, most orgs dont try to “fix” this at the DI level. They either exclude ephemeral builds from VR or let VR auto-close them, because disposable infrastructure shouldnt generate long-lived remediation work.

@rogerburns - Please mark Accepted Solution and Thumbs Up if you found Helpful

[rogerburns]

Thanks Matthew_13

You captured what I was trying to describe.  We don't have complete visibility on the process, but you gave us ideas on how to accomplish our goals.  The build process is largely outside of ServiceNow but the CI's, DI's, and VITs are all a consequence of this and we will need to work with those teams to understand ways to improve the processes.

Roger

[QM_SSJ4]

Sounds like an issue with the 'golden image' itself. From a vulnerability perspecitve, the build image should not have outdated software on it. Patching after the fact seems like rework and the root cause of the problems it creates for you. Perhaps you can work with the build folks to get their image scanned regularly and remediated prior to it creating outdated devices all over your ephemeral environment.