The headlines about the recent SolarWinds data breach have brought three security risks center-stage: end of life software, third-party vulnerabilities and software supply chain risk. All of these played a major role in the attack, which has left almost every company dependent on third-party software wondering: How can we avoid something like this?
While the magnitude of the SolarWinds breach was unprecedented, the vulnerabilities exploited by the hackers are all too common. Deloitte reported that 83% of organizations experienced a third-party incident in the past three years, with 11% causing a severe impact on customer service, financial position, reputation or regulatory compliance. With odds like this, it’s mission critical for organizations to prioritize security to protect their own data workflows and minimize the risk of third-party and legacy software risks.
Third party vulnerabilities
If any point of your supply chain is dependent on third-party software, this can create a hefty risk surface – especially if it’s connected as a service and many others also depend on the software. The network effect – the idea that software becomes more powerful as more people use it – is a double-edged sword. More customers, more functionality, and reduced friction for integration make for a more useful tool, but they also introduce an exponential spectrum of vulnerabilities.
Using the SolarWinds example, the breach was used as a springboard to compromise a raft of U.S. government agencies. As a result of network effect and the list of high-profile clients using an outdated version of the software (including parts of the Pentagon, the Department of Homeland Security, the State Department, and a handful of Fortune 500 companies), the hack was “the largest and most sophisticated attack the world has ever seen,” according to Microsoft Corp President Brad Smith. The breach could have compromised up to 18,000 SolarWinds customers that used the company’s Orion network monitoring software by which the source code was modified.
For software providers, it’s high time to prioritize automated security as part of every build. Every new version of your software has the potential to create new vulnerabilities. Security requires continuous hygiene.
Software that once earned an “A” rating during a pen test may perform at a much lower level as new features and integrations are added, even if it was only dependency updates provided by the operating system or shared libraries such as open source software (think back to the Heartbleed and Shellshock OpenSSL or the GNU Glibc vulnerabilities a few years ago).
For customers dependent on third party software, this is a wake-up call. Now more than ever, it’s critical to take proactive security measures, make contingency plans, and find trusted, automated application shielding solutions to protect your data – even if your software vendor is compromised.
The right security approach starts with asking the right questions during the RFP process, asking for and verifying security and data breach policies that comply with ISO 27001, GDPR, CCPA, NY SHIELD, and others, siloing sensitive data and insert environmental checks at vulnerable points in your workflow to reduce the attack surface and ensure that your apps are only running on trusted devices, on trusted networks, on trusted platforms by trusted users with trusted credentials.
And most importantly, the right security approach will be one that ensures you have a complete corporate plan for routinely monitoring, testing, mitigating and resolving any breach that may occur to build good security hygiene beyond the IT team, but throughout your entire organization. Security is not one person or department’s job, it is the responsibility of the entire company.
Protect features you haven’t released yet from undermining app security
Additionally, many developers add what are called “feature flags” or “toggles” to their code that allow them to turn on/off features and A/B test new functionality for particular users and groups, or to compartmentalize risk. The ironic risk here is that if the application is reverse engineered and hackers can see the source code, the logic of your application will be exposed, and criminals will be able to steal or compromise your intellectual property.
This also means that if there are hidden feature flags in your source code, the features you haven’t yet publicly announced or shipped may be inadvertently given to hackers (or your competition). In theory, this would give criminals and thieves a headstart in learning how to copy, tamper or manipulate your software. Even if hackers gain access to code that isn’t yet fully functional, it could still offer comments and hints to what your plans are for the future.
Legacy and end-of-life (EOL) software
Part of a proactive security approach is ensuring that your company is never running on end of life (EOL) software – whether you’re a provider of the software or on the receiving end.
The best (and easiest) way to ensure that you are always running on the latest versions is to integrating automatic security updates into your continuous integration/continuous development (CI/CD) pipeline. This way, the latest vetted security improvements become part of every new software update. Integrating Code Protections and Whitebox cryptography into your CI/CD pipeline means that you will no longer need to think of adding security as a manual step – your software will be protected upon every release.
Any legacy code that hasn’t been reviewed recently, no matter how well it appears to work, might contain vulnerabilities.
In the case of commercial software:
If maintenance and support payments have been disrupted, so may your continuous flow of software updates from the vendor. You may be many versions behind the latest updates and may not be aware that this change was disrupted by someone in Finance or Procurement trying to control cash flow.
In the case of open source and third-party software:
It might mean the maintainer has stopped supporting it and isn’t creating patches when a new vulnerability is discovered, leaving your applications and systems vulnerable to security events that are increasingly exploited.
In the case of a codebase you inherited:
including from your own organization—it might mean that the software hasn’t gone through your current source code review and security testing process. M&A transactions are a perfect opportunity to force such a review of inherited code from top-to-bottom during due diligence and integration.
In the case of actively developed software:
As your development teams add new features, the old ones might remain functional but depreciated, thus creating regression issues. But organizations often focus their testing and remediation efforts on new code in the latest versions, which can lead to a false sense of security that your app isn’t vulnerable.
Take advantage of SaaS offerings and implement app security
So, what’s the answer? Surely it isn’t economically feasible for every business to go it alone and develop their own proprietary software for every function and use case. At this juncture, workflows are collaborative, and businesses are reliant on third-party vendors to optimize organizational value, derive efficiencies, and boost savings. Cutting out third parties entirely is simply not an option.
The solution is to be proactive with your security approach. You are responsible for your own security and safeguarding your data – even if one of your vendors is compromised. There are a few key moments that can make all the difference:
- If you’re running on an EOL version of software – it’s time to update. Coming up on end of life? Make the switch to a SaaS version so you’re always running on the latest technology and patches. If you can’t move to SaaS, enable automatic updates in your on-premise solutions. And don’t forget to ensure you are continuously paying for maintenance and support services to keep the updates and technical support coming uninterrupted.
- Protect your apps with automated, layered security as part of your CI/CD workflow. This will safeguard your intellectual property, private keys, APIs, SDKs, and user data – keeping it shielded, even in the event of a third-party breach.
Managing third-party risk is a continuous kaizen improvement process. It’s about prevention rather than reaction. Kicking the can down the road and treating cybersecurity like a periphery task can have dire consequences for a business, especially as every company becomes a technology company, accelerated further by the rapid digitalization required from the pandemic.
Bottom line: Simple math tells you that it will be cheaper in the long run to deal with risks now than to wait until vulnerabilities are exploited. Yes, it may be a headache to address legacy vulnerabilities, but failure to do so can create problems far worse than a headache and financial and legal liabilities for your company and your customers.
If you find yourself reacting to a security issue – it’s probably too late. The best way to approach security is to get ahead of it before you become another headline.
Protect every version of your software with saas security solutions
Reduce the risk of your supply chain being made vulnerable by old software and compromised third-party integrations. Verimatrix XTD Prevent (formerly App Shield) offers military-grade protection at SaaS speeds to keep source code, API keys, SDKs, personal data, and certificates secure. Even if your apps are running on legacy software, XTD Prevent injects powerful protection directly into your app package (Android APK and iOS xcarchive) with this zero-code cloud service allowing you to protect your customers on the current versions they are running without requiring them to do full end-to-end systems acceptance testing again.
