“Resistance to change is proportional to how much the future might be altered by any given act.” — Stephen King
Humans are naturally resistant to change. The fear of the unknown and loss of control can cripple attempts to innovate and modernize. This is often true when it comes to DevSecOps initiatives. Many people accept the need for a more integrated and automated approach to security, but concerns about security teams slowing teams down or hindering innovation hold many companies back from embracing it.
Meanwhile, the digital economy is becoming more competitive, talent is becoming harder and more expensive to acquire, and the cost of breaches — financially and on companies’ reputations — has skyrocketed. In this environment, the benefits of DevSecOps far outweigh the upfront costs and ongoing investment.
In reality, teams can’t, and shouldn’t, completely ignore the costs of DevSecOps or risk optimism bias. DevSecOps indeed requires the upfront investment of time and money.
Tools and training cost money. Even if you invest fully in open source tooling and also leverage internal expertise, the time you spend in security training and embedding security into discussions and processes takes time away from business-line work. In a similar vein, building in automation requires an investment to set up and integrate solutions. On an individual project level, helping you fix bugs in your code throughout the development life cycle does increase the time of initial development compared to not worrying about security at all during development.
These upfront and ongoing costs still add up to far less than the cumulative benefits of DevSecOps. The benefits show up in three areas: increased revenue, decreased cost and lowered risk.
DevSecOps aims to embed security earlier in development phases, leading to faster feedback cycles and a lesser burden on security and compliance. Saving time is saving money, and efficiency is the source of satisfaction.
Part of the benefit of DevSecOps is encouraging developers to proactively patch their own code. When that happens, the burden on understaffed security teams is lessened. Think of it this way: When an infrastructure-as-code-(IaC) template — such as a Terraform module, Helm chart or container base image — is made, it can have dozens of vulnerabilities and misconfigurations. Dozens of other engineers can use those same templates to provision hundreds of resources across different cloud, Kubernetes and container environments, leading to thousands of runtime alerts for the security team to process.
If, instead, you address those misconfigurations while they’re being developed, cloud infrastructure and applications are more secure from the start. That results in fewer security alerts, freeing up security teams’ time to work on higher-priority projects and alleviating the issue of being understaffed.
With reactive security monitoring in place, the burden isn’t just on security to triage, prioritize and assign remediations. You also bear the weight of manually reviewing security issues, remembering the context in which they may have been made, scheduling time to address, and finally, making out-of-band fixes. With the number of alerts created from traditional security tools, it could take a week, if not longer, to fix the litany of security issues.
So despite those upfront costs of fixing a security bug and implementing the right tools and automation, the long-tail costs decrease dramatically. Also, if issues are surfaced early as the code is written, then the context is all fresh in your mind. You know the nuances of how you chose to tackle a shortcoming in a cloud provider’s managed Kubernetes clusters or the unique way you used a Node.js library to solve a problem. That makes it drastically easier to modify IaC resources to fix a misconfiguration or update a dependency in a container image to remediate a vulnerability.
Many teams wait for an audit to apply security rules. Not only does that expose companies to unnecessary fines and may even force you to stop business operations, but it also increases the time it takes to pass an audit. If, instead, you build in continuous compliance automation, you prepare as you build and minimize the audit findings, saving your business time and money. Of course, it also goes without saying what the positive impact on revenue may be when you’re able to get those coveted certifications.
There’s also a positive externality to the previous two cost-saving benefits: Minimizing menial and manual work leads to increased job satisfaction. When you’re able to spend more time building new features and seeing tangible results, your job satisfaction increases. Similarly, when AppSec and SOC teams can focus on more complex problems than “close port 22” and “update your dependencies,” their satisfaction increases as well. Higher job satisfaction leads to longer retention and decreased turnover. With the increasing demand for skilled workers and the high cost of turnover (33% of a person’s salary), higher retention leads to actual tangible savings and helps contribute to meaningful and uninterrupted value resulting from institutional knowledge.
Increased revenue is always the hardest to tie directly back to a single initiative. However, there are measurable ways to show the impact DevSecOps can have on the top line.
Code can be shipped much faster when the overall time to fix issues goes down and manual work is minimized. With the right DevSecOps feedback in place, it takes minutes to resolve issues at the time of code, hours when caught as part of a code review, and a day or two with continuous integration guardrails in place. That is all faster time to market. When you’re building an innovative new feature for your web application, beating competitors to market means more time to monopolize the demand for that feature.
In fact, agility is a key indicator of overall company health. You can attribute a greater demand for a feature to the additional time in the market.
Another top-line benefit of DevSecOps is increasing customer satisfaction. This comes from two angles. First, security bugs and related outages are minimized, making customers more comfortable with your product. Second, you’re able to get innovative features out the door faster, delighting customers. Watching net promoter scores (NPS) or other customer satisfaction key performance indicators (KPIs) increase is a leading indicator of network effects. Customers organically tell their friends about your product, and there is decreased churn where customers leave your product.
Last but not least, decreasing risk is a logical argument for implementing DevSecOps. While reducing risk might lead to higher revenue (less customer churn) and lower costs (fines and other costs for a data breach), its impact is not typically measured in quarters, so it is often broken out separately.
DevSecOps decreases risk dramatically by increasing the time-to-patch rate and reducing the attack surface. Using automated tools to assess least-privileged IAM (identity and access management) roles, for example, won’t have a noticeable impact on earnings, but might end up saving you $4.24 million when credentials are stolen, and the lack of access thwarts a bad actor.
Also, as mentioned in the decreased security costs, with DevSecOps, security teams have more time to find other security issues beyond the low-hanging fruit. This allows them to proactively threat model and identify breaches faster, lowering the company’s overall risk.
The idea of DevSecOps, with more collaboration and automation and less security gatekeeping, can be daunting. However, the profitability benefits outweigh the costs and justify the investment. Upfront investments in training, automation and bug tackling pay for themselves as the pace of innovation and employee productivity increases without sacrificing security.
This post originally appeared on The New Stack.