Ah April. Spring is in full tilt and flowers are blooming in the Northern Hemisphere, and it’s in the heart of autumn for friends in the Southern hemisphere. It’s a great time to be outside, but for many in the U.S., it’s also the month that requires a considerable amount of time inside, because it’s when income taxes have to be completed. Just like there are changes each year that leave families trying to figure out their situation, how an organization handles application security also goes a long way in determining whether it will be “taxed” by vulnerabilities in production or getting a nice refund of their customers’ trust.
We all know that every year there are going to be changes to the tax laws that go into effect, but how many of us actually take the time to read through them, ask questions, understand them and then take action? Unfortunately, many just have a vague sense of awareness of those changes and either take small token actions or none at all.
Sadly, in many organizations today, application security is like that too. We all know there is no such thing as a perfectly secure application. We know there are new vulnerabilities that arise daily, and that this raises our risk of being exploited. But we think it won’t happen to us. So, just like the taxpayer who is surprised and shocked by the results of their return, we end up dazed and wondering what happened and what we could have done to prevent it.
A good friend of mine likes to say that “proper prior planning prevents poor performance.” Consider this as an example: For 2019, the big recommendation from the Internal Revenue Service (IRS) was to review and update withholdings for how much is held each time you are paid. But did you know that more than 80 percent of taxpayers did not do this? The 20 percent that did make necessary changes were rewarded with reduced taxes later on. The great news here is that, just like you can minimize your taxes with good planning, application security can reduce the potential “taxes” you would pay in production.
While it is true that every line of code written has income potential and new capabilities mean new opportunities, it is equally true that every new line of code also has the potential to introduce new vulnerabilities. Finding those flaws while applications are still in development means you are reducing your likelihood of having to pay a “loss of customer trust” or “out-of-compliance fine” tax. Wise planning can also make a great difference with the open-source software being used by most companies, especially larger ones. Scanning open-source libraries before they are committed to your pipeline could be the difference between a slight delay for a fix today and an enormous impact on production tomorrow.
In tax terms, the biggest determinant for families between getting a refund or owning money is in the amount of deductions they are able to take to reduce their taxes. Contributions to a retirement plan, charitable contributions, excessive health costs and a host of other things all help to reduce taxes. Maximizing deductions is a great strategy to lessen or even eliminate having to pay taxes on tax day.
In application security terms, deductions come in the form of finding and removing vulnerabilities. Every time you run a static source scan in development and remediate an issue, you are removing potential taxes paid in production. Every time you dynamically scan a built application for potential attacks as part of your pipeline, you are lowering the overall risk. Every time you can run a quick interactive scan as a sanity check, you are helping to keep breach likelihood low. Every time you are able to leverage cognitive capabilities and machine learning to do better-targeted, faster scanning and testing with greater accuracy and reliability, you increase your overall effectiveness. And when all of this is done in ways that are seamlessly integrated into the software development life cycle, it greatly enhances the ability for software developers to participate consistently.
The advice here is simple: Don’t just key in on part of application security, such as runtime application self-protection (RASP) or static application security testing (SAST). Instead, take advantage of all your application security “deductions” and increase the refund of customer trust for what you deliver.
With some wise planning and deduction consideration in your application security program, your organization can excel at eliminating potential “taxes” paid in production — taxes like the lost revenue, lost reputation and lost trust that all come with significant breaches. Making sure to leverage application security techniques, principles and practices throughout your software delivery pipeline will help find and, more importantly, remediate those issues that would otherwise break the bank. Don’t delay; examine your application security posture today and it just might be you with the great refund next season.