There’s a popular bit of wisdom that says don’t stress over the things in your life that you cannot control. It’s great advice for all of us these days. Still, though, no matter how hard you try, there will be some things that are out of your control that you must be mindful of, especially in a business setting. One specific thing that you need to stay on top of, regardless of whether you have full control over it, is software developed by third parties. From the source code in your web applications, external libraries that are being called by your software, or the web interfaces of systems that you cannot update or otherwise maintain, there’s likely a lot of third-party software in your environment. And, knowing what we now know about application security, you need to do something about it.
Many of the more sizable security risks to any given organization are brought about by code written and, presumably, maintained by others. It’s easy to say well, that other people’s code is not my responsibility, but reality has a different set of plans. The last thing you need is a software exploit that facilitates an incident or breach. Regardless of which outside party wrote the original code, it’s now your responsibility because it’s part of your network environment. So, the question becomes, what are you going to do about it?
One thing that you have to remember is that outside parties such as auditors, customers, and even juries and judges don’t care how vulnerabilities got into your environment. Even if your hands are tied, application security flaws can and likely will reflect poorly on you. As soon as you become aware of an application security flaw that you have no immediate control over, you need to get the outside vendor involved as soon as possible.
Talk with your vendor to see what they might be able to do or what compensating controls they might be able to help with. Show them the tangible evidence you have of the specific vulnerability and then communicate how it’s impacting your business. The report from a web vulnerability scan or dynamic scan of software composition analysis could be all they need to see. They might need additional details uncovered by manual testing. Regardless, it could be a quick fix that their developers can easily resolve. The vendor might have some unbiased and solid ideas for remediation that are not clouded by the perception that you have of your own application and network environment.
It could be that the third parties who are responsible for the vulnerabilities are not interested in fixing them. If this is the case, you could go up the food chain and speak to management and try to leverage the relationship that you have with them. You might also try to find out who else is using this software and attempt to band together with a unified front that might help change the vendor’s mind.
Still, you might find yourself on a dead-end road with the vendor. If so, try to figure out what you might be able to do to mitigate the risk in terms of technical controls on your network. Update the software yourself, move to a new platform, use a web application firewall or perhaps network segmentation – whatever it takes.
One of the greatest challenges to application security is the failure to acknowledge vulnerabilities in the first place. Whether you are responsible for all of IT or have an application security focus, it’s imperative that you take reasonable steps to uncover security vulnerabilities in your software. This is true whether it’s internally developed or it’s someone else’s code. But you can’t stop there. You then must take that information, determine how the vulnerabilities are impacting the business, and then do what you can to minimize any identified risks. If you have third-party software dependencies containing unresolvable vulnerabilities, then you’re going to have to address them somehow. Once you see a vulnerability, regardless of how it got there, something must be done. Otherwise, it’s time to move on and away from such unnecessary risks