rvlsoft - Fotolia
Businesses want to deploy a lot of products. Consequently, developers are pushed to deploy code frequently -- multiple times a day -- and features every one or two weeks. In this rush to produce software, security testing usually gets neglected.
You can either choose to test thoroughly and deliver once a quarter, or do security poorly and release quickly and continuously. However, there is a third option: automated security testing.
I'm reluctant to give developers additional work. I've seen that overworked developers will skip security testing. If possible, streamline their workloads; otherwise, they will become weak links.
Automated security testing is essential in rapid application development and must be in place early on. You can't do a threat model analysis without automation or else developers will have to validate every single feature. In this model, more checkboxes will keep getting added. Then all of a sudden, there's a big template that either nobody ever follows or they spend too long completing.
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.
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.
Dig Deeper on Agile, DevOps and software development methodologies
Related Q&A from Matt Heusser
Through unit testing, software developers know source code works at the atomic level. Read why unit testing is important and valuable, as well as how... Continue Reading
Your boss has jumped on the bandwagon to automate software testing. Don't despair. Software testing expert Matt Heusser walks through what to say -- ... Continue Reading
Tracking defects can benefit the development team if done for the right reasons. Explore the reasons to track defects in this expert response. Continue Reading