Cybersecurity

I'm working on developing a patch policy for a mid-size and quickly growing company. Patches have been at the bottom of the totem pole for years. I possess the ability and care enough to straighten it out. However I'd like some others input on the best way to handle the patch policy.

From when a patch is released how is communicated? How long to deployment? etc..
What are your trusted sources for patch alerts?

The discpline you are referring to is called Configuration Management, and there are many free and buy apps that can partially or completely do this. Part of this is tracking changes at the sites where you pick up open source. You can put a free watcher on each of them, so you can tell if they have new offerings.

You need a firm, written policy on configuration management, including what patches you take as normal maintenance, e/g/. updates to the latest stable release, even if you have to temporarily go closer to the ragged edge to get patches for emergency fixes, or even create your own patched files to get the fix in otherwise stable code or without forcing a major version update. You need to introduce these changes with proper SDLC, testing so you do not destabilize your product, and so you can roll back if bad things emerge.

One way to make this easy/cheap is with clone trees and symbolic links. A clone tree is a tree of directories in the same device as the master, with most files hard linked from the master (using 0 inodes and storage) but with the new files for this release. A symbolic link can point to the tree that is the current version. You can have versioned subtrees for simpler management, hung in the master trees by symbolic links, for instance for each source of open source software or major sub-application or team. If you use the right options and UNIX tools, hard and soft links can be transported from one system to another and saved in archive files. Dumb copies will make new files, but you can go back and replace them with hardlinks where the files cmp or cksum as identical. Infdividual developers can make their own clone trees to work in, being careful not to modify shared files. Shared files should all be made read-only as part of their make/build, to help ensure this.

There are free sites that can email you if a page changes, and some source sites have a newsletter that tells when there are new versions. You need to turn each of these that apply, immediately into a pendingplanned update toyour system. It is bad policy to run old code.

Bought code, opens source code and locally written code should be all in separate and distinct directory trees. It is embarassing or worse if a vendor has to come to fix their product and a file has been changed by accident. Local mods in one open source tree can be lost if a new open source tree is built. Sell your local mods back to the open sourcers, and you will be an open sourcer, too!