We’re living in the age of cyber insecurity. To say that breaches are widespread is an understatement. Each year sets new records for cybersecurity incidents, and each major attack--from the fouling up of the software supply chain with malicious code to ransomware that upends critical infrastructure--seems to be more shocking than the last. But what’s most shocking of all is not how bad the breaches are, but how often they keep occurring. Application developers have been acutely aware of security risks for years. Any decent coder today follows basic application security best practices, such as validating input and encrypting data. And, yet, the attacks have not only kept coming, but they’ve grown steadily worse.
That begs the question: What does it actually take to secure applications today? Why do businesses continue to struggle with application security, and what can they do to make it better?
To provide some answers, here’s a look at outside-the-box application security best practices. Instead of rehashing conventional tips for code security, this article discusses strategies for managing security threats in applications that you may be overlooking.
1. Use new libraries.
Here’s a radical approach to application security optimization: Whenever possible, adopt the latest and greatest libraries and tools instead of relying on tried-and-true ones.
Why? Because the newer a codebase is, the lower the chance that it contains vulnerabilities that are already being actively exploited. If a library has only been out for a few months, chances are that the bad guys may not yet have had a chance to find its flaws.
Of course, the obvious security risk here (to say nothing of the performance risks associated with using code that hasn’t seen much real-world usage) is that vulnerabilities are bound to be discovered in the code sooner or later. But if you keep changing things up by switching to newer libraries whenever they appear, you may stay one step ahead of threat actors.
2. Deploy apps on unpopular platforms.
Along similar lines, your overall application security posture may be stronger if you deploy your applications on platforms that are less widely used, and therefore less likely to be the target of frequent exploits.
There is, after all, a reason why malware that targets desktop Linux is relatively rare compared to similar exploits against Windows: Not many people run Linux on their PCs, which means there’s much less incentive for attackers to try to exploit desktop Linux.
For similar reasons, hosting apps on a tier 2 cloud, or managing them with an orchestrator other than Kubernetes (which controls about 77% of the market, or 86% if you count Red Hat OpenShift as a form of Kubernetes), may reduce your chances of being caught in attackers’ crosshairs, just because there are fewer attackers focused on your deployment platform.
3. Manage your software supply chain.
It’s common today for developers to borrow code from third-party sources. Whether you integrate libraries from open source projects, or rely on proprietary extensions or add-ons from your partners and vendors, chances are that a significant amount of the code that ends up in your application was not actually written by you.
Borrowing third-party code is a great way to build applications faster, of course. But it also creates a major security risk: If you didn’t write the code, you can’t ensure that it meets your organization’s security standards.
The takeaway here is that it’s critical to know where your code came from. And no matter how much you trust the source, assume the code is insecure, and put it through the same rigors as code you write in-house.
4. Strive for environment parity.
Sometimes, the weakest link in application security is not vulnerabilities lurking in your source code, but rather environment variables that enable an exploit when certain conditions are present.
The tricky thing about catching these security risks is that unless you run security tests under the right conditions, the vulnerabilities can go undetected.
To mitigate this risk, developers should do their utmost to ensure that the dev/test environment resembles their production environment as closely as possible. Containers are a great way to do this because they abstract the application from most environment variables--which means that if you test your application inside a container, you’ll accurately capture most of the potential risks to which it could be exposed if you deploy it in a container.
5. Make use of bounty programs.
No matter how much you test and scan your code, security flaws will creep in sooner or later. Your ability to optimize application security hinges in large part on your ability to find the flaws before the bad guys exploit them.
You can--and should--scan for vulnerabilities, data input issues and the like yourself. But you can only do so much in-house to secure your application.
To maximize your ability to detect vulnerabilities, consider running your own public bug bounty programs. Bug bounties are a great way to get help from well-intentioned people in discovering security issues before threat actors do. You may have to spend a little money to attract skilled participants to your bug bounty, but the investment is well worth it if it prevents a security breach that costs your business untold sums.
Conclusion: Think Beyond Conventional Application Security
You can, and should, follow standard application security best practices. But the harsh reality is that those practices, which are no longer novel to developers, haven’t proved sufficient for ending the barrage of security breaches. That’s why taking a more innovative approach to application security, including practices like avoiding popular deployment platforms and leveraging public bug bounties, is a wise strategy for teams that don’t want to settle for standard security.
