Automated security testing frees devs to prevent breaches

Simplify and modernize documentation

One way to help developers and testers is to replace static documentation with living documentation. Use a living documentation tool that makes it easy to enter a change, save and then notify others. Also, each file in a living document describes what a portion of code is supposed to do. You can't do that with Word or Excel. Nonetheless, some dev and test groups still use Word.

The most common tool is a wiki. A wiki, which is small and easy to constantly update, will comparatively show everyone's day-to-day work. That way, when the software pops out of the first build, it is more secure.

I know at least one small development team that uses an Excel spreadsheet, which is the official company process. When the auditors review, it looks like the developers have checked off all the right things. The joke is that those documents have no real value to anyone on the team, aside from saying -- disingenuously -- that security measures have been taken. The team members want to perform minimal security processes so that they can get back to developing and releasing.

Who's minding VM and open source security?

I sometimes consult with a company and discover that no one is paying attention to security. That's not to say that the company has automated security testing to the point where human intervention isn't needed. I mean that developers are running systems with zero oversight. It's common to see no one minding the security of virtual machines (VMs) and cloud applications.

I'm reluctant to give developers additional work. I've seen that overworked developers will skip security testing.

Many figure that VMs only exist to provide demands around testing and will never have production apps on them. That's faulty thinking. Software residing in VMs has to be updated as it gets patched. Some companies aren't aware of that. It's a solvable problem that's not being taken seriously.

On the cloud side, I've seen companies move apps to the cloud and pretty much turn off their own app security practices. That level of trust is naïve these days.

Too many companies trust the security of popular, well-known open source code, components and apps. Let's say a dev team chooses to use code from an unheard-of open source project in order to solve a unique problem it has. Because the code is not widely used, that team doesn't perform its security due diligence. Developers are more likely to let it be someone else's concern if they use open source software, like Apache. They may not have the time or the budget for scanning tools. They'll just piece some open source tool together and throw it out on the web.