You've just written a wonderful script that you're about to send out into the world, but something makes you pause. Yes, your new script will save you, your users, and the company time, money, and effort. It will likely increase productivity and elevate your status as a scripting guru. Everything seems right with the world, but you can't quite shake the feeling that there's still a problem. Then it dawns on you: Although the script you just wrote can do a lot of good if used properly, someone could, through malice or ignorance, change your script and create havoc.
By their very nature, scripts are open to the world. Anyone can see all the fine work you've done in a text editor. This is both good and bad. On the good side, it's great to be able to share scripts among fellow IT professionals. It's a common practice to keep a repository of scripts handy so that people can combine snippets from various scripts in order to create a new tool. On the bad side, if you write a script that's intended for use by others, they might be curious and try to dissect your code. Even worse, it's quite easy for them to make changes. This situation might not only become a support nightmare but also has the potential to cause damage, depending on what the script was designed to do. . . .