3 Key Questions for Smart AppSec Automation
It’s no secret that most application security teams are overextended and short-staffed. In fact, a recent ESG study showed that many cybersecurity professionals experience increased stress and job burnout.
Automating the routine aspects of application security could prove tremendously helpful in reducing the pressure while continuing to handle today’s expanding threat landscape. However, many security teams are slow to adopt automated tools. This may be because automation itself is technologically challenging, but more often than not it’s because users need to gain more trust in automation before they feel comfortable adopting it. When it comes to cybersecurity, the focus should be on automation that is built smartly and transparently. The following questions can help cybersecurity professionals find automated tools that fit their needs without increasing risk.
Can you opt in?
Introducing automation for an existing manual process should be an explicit opt-in process for the end user. Developers would seldom want a security admin to begin introducing automated code changes, even if those changes make the code base more secure. This is because developers may feel apprehensive that an automated change could break functionality and create more work, rather than reducing the workload. Instead, developers should be able to test the tool on a few, relatively simple, use cases. Once they see that nothing breaks, they will trust the tool. Then it’s easier to increase its use.
What is the configuration burden?
Developer environments are extremely heterogeneous, so configuring an automated process in one environment does not necessarily mean you can easily do it in another environment, even if they are similar. This is a relatively widespread phenomenon and for a developer, the need to do extensive initial configuration work for each new automation tool often puts the kibosh on bringing a tool in house. It seems like a paradox, but a new tool needs to work on a multitude of developer environments without the requirement for extensive configuration. The solution is to create a default configuration that will work for simple use cases in a wide range of environments, while providing extensive configuration options for support of more advanced use cases.
How easy is it to reverse actions?
When automation is invisible and the tool you’ve recently adopted is a “black box”, it’s hard to trust it because you have no idea what’s happening behind the scenes, and no idea why a given action was taken. Providing context by creating visibility into logs or an audit trail of actions, is imperative to help users understand and trust the tool.
Such visibility is also vital to reversing actions when needed. No automation is perfect, and edge cases and errors are bound to occur. The ability to handle these errors when they appear is strongly reliant on how well the automated process is logged and displayed to the user. Providing visibility gives users a clear and easy way to reverse actions that cause errors. And as Jeff Bezos has told us, reversibility is a key aspect of smart decision making. Because users know that actions can be reversed, they will be more comfortable trying the tool, since risk is minimized.
Gaining user trust and buy-in will have significant benefits, because automation not only reduces the time that developers spend on security, but also makes security processes faster and more thorough than a manual approach. Consequently, automation eases the stresses of labor shortage for cybersecurity professionals. And by deploying solutions that automatically detect and remediate vulnerabilities, companies can improve AppSec outcomes and make it simpler and easier to integrate application security into the software development life cycle.
