Yes. Many RPA workflows call custom scripts, written in a general purpose language, that import open source libraries. Those libraries can carry known vulnerabilities or be tampered with, and a bot machine is rarely patched like a normal application. Treat bot scripts as application code with an inventory, scanning and updates.
Where the libraries hide
A bot developer who needs to parse a file, call an API or process a spreadsheet often writes a small script and installs a package on the bot machine. Nothing records which package, which version or why. The OWASP Citizen Development Top 10 lists vulnerable and untrusted components as a risk, covering exactly this kind of unchecked reuse.
Why it is easy to miss
- The script lives inside a workflow, not in a repository, so normal scanning does not see it.
- The package was installed by hand on a machine, with no manifest.
- Bot machines are treated as appliances and updated rarely.
- The builder has moved on and nobody knows what is installed.
A five step approach
| Step | What to do |
|---|---|
| Find | List every bot that runs custom code, and every machine that runs bots |
| Record | Capture the packages and versions on each machine as a software bill of materials |
| Scan | Check those versions against known vulnerability data |
| Prioritise | Fix what is reachable and exposed first, since not every finding matters equally |
| Update | Change versions through the normal change process, and retest the bot |
Reachability matters
A library can carry a vulnerability in a function your script never calls. Knowing whether a vulnerable function is reachable from your code helps you decide what to patch first. That shifts effort towards findings that can actually affect the bot, which keeps the update work manageable for a small automation team.
Move scripts into version control
Where the tool allows, keep scripts as files in a repository with a dependency manifest. You gain history, review, and automatic scanning. If scripts must stay inside the platform, export them on a schedule so you have something to scan.
Pin and review new packages
Before a bot developer adds a package, ask the same questions you would of any dependency: is it maintained, who publishes it, and do we need it at all. For a longer routine see our post on what to check when a contributor adds a new dependency, which applies equally here.
What good looks like
Each bot with custom code has an entry listing its packages and versions, a scan on a schedule, a named person who acts on findings and a record of when it last updated.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, with reachability analysis, covers this kind of custom code. You can try a free scan at https://gold.safeguard.sh/scan. It does not look inside proprietary RPA workflow formats.
Try it yourself
Click through the demo to see how a dependency inventory is built from a project. Look at how packages and versions are listed, then picture the same list for a bot machine.
Click through it at your own pace, or open it full screen.
Quick check
Do I need an SBOM for a bot?
If the bot runs custom code with third party packages, yes. It is the quickest way to answer which bots use an affected library.
Is a bot machine in scope for patching?
Yes. Treat it like any server that runs application code, with an owner and an update routine.
Sources
Last reviewed: 19 October 2026.
