Yes. Anything that opens, converts or stores the files you ship is part of how the build is made. Content tools, their add-ons and the Git LFS client all run on your machines with your access, so a creative studio should list them next to its code dependencies.
What counts
- Digital content creation tools such as a 3D package, and every add-on installed in it.
- Scripts and exporters that convert art to engine formats.
- The Git LFS client that stores textures, audio and models.
- Editor plugins that process assets on import.
- Marketplace downloads that arrive as project files.
Evidence that these tools carry risk
Blender's manual explains that blend-files can contain scripts. Registered text blocks load on start, and animation drivers use Python expressions. Automatic execution is disabled by default, and a dialog appears when a file tries to run a script and is not allowed. The manual lists manual routes too, like running a script in the Text editor. It also describes a Preferences toggle that, once enabled, lets scripts run on file load, with an option to exclude directories such as the download folder.
The Git LFS site shows a security notice telling all users to update to version 3.7.1 or newer. That is a good example of an art pipeline tool with an update you would want to know about.
What to record for each tool
| Field | Why |
|---|---|
| Name and version | Match advisories to your machines |
| Add-ons and versions | Add-ons are code from other people |
| Where installed | Artist machines, build agents, render nodes |
| Who updates it | A named person, not everyone |
| Settings that matter | For example whether script auto-run is off |
How to roll it out
- Ask each team lead to list tools and add-ons in use. Expect surprises.
- Choose a baseline version and settings for workstations.
- Check build agents and render nodes, which often run older tools than desktops.
- Review add-ons the way you review plugins. See mod and plugin safety.
- Set a monthly slot to check release notes for the tools on the list.
- Keep this inventory beside the engine inventory so one page shows both. See engines, middleware and asset packs.
Handle outside contributors carefully
Freelancers and vendors hand over files from machines you do not control. Ask for exports in plain interchange formats where practical, open native project files in an isolated machine first and keep script auto-run off.
A worked example
Imagine a studio with eight artists, two outside freelancers and a render node. The tool list shows the same 3D package at three different versions, two add-ons nobody remembers installing and a Git LFS client two years old on the render node. None of that is dramatic. But it means a fix released for one tool reaches some machines and not others.
The repair is small. Pick one version, write the add-on list, update the render node and set a calendar reminder. The value is that next time an advisory or a vendor notice arrives, you can answer which machines are affected in minutes instead of days.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a software inventory lists items with versions, then add your art tools to a similar sheet.
Quick check
Do art tools belong in the same inventory as code?
Yes, at least as a separate section. They run with user access and handle every shipped asset.
What is one cheap control for creative machines?
Keep script auto-run off in tools that offer the setting, as Blender does by default.
Sources
Last reviewed: 19 October 2026.
