In some ways, dealing with problems caused by insecure third-party code is harder than resolving internal development issues. By default, you have less direct control over a vendor's actions when a security issue is discovered, making it difficult ensure that the issue is remediated. There are additional enterprise-vendor relationships to navigate -- sales teams, vendor executives, procurement teams, contract lawyers -- can all influence the level of risk your company absorbs from software vendors.
Too often absorbing this additional risk results in unwanted surprises. It's the reason security-minded enterprises put time and energy into finding third-party vendors that take security seriously. The best way to avoid its pitfalls is knowing the habits of a good vendor and recognizing the warning signs that a vendor might not be as focused on security as you'd like. To help, here are three red flags to look for when hiring third parties or implementing their code:
1. Less secure vendors don't take operational security seriously.
You can tell a lot about a vendor's commitment to security by looking at how it practices security at organizational and operational levels. Even small things, such as a lax attitude toward developer password policies or unlocked workstations or unrestricted physical access to project-critical hardware, can reflect a general lack of concern or a lack of understanding of how creative attackers will be in achieving their goals.
Worse, loose standards can be just the "front door" attackers need to access and exploit otherwise secure information or do damage on a larger scale. Lax password policies could make it easy for less-than-savory folks to gain access to a variety of systems -- including those used to develop the software you are buying.
Often, the key to learning this information is asking: If a vendor doesn't have a satisfactory answer, dig deeper — or be prepared to pass. When attackers can take any number of routes to perform their nefarious tasks, knowing that vendors take a holistic approach to security is important for your product, your users and your general peace of mind.
2. Less secure vendors don't control access to information.
How does your prospective vendor keep such critical info as user details and client communications safe? If words like obfuscate and separate don't appear to be part of a vendor's vocabulary, then it may be time to look another direction.
Take the simple — yet crucial — art of database management. A truly security-minded vendor will, for instance, keep big-time info such as user passwords safe from well-known vulnerabilities like SQL injection and the like by storing it away from hardware that's susceptible to attack. By the same token, its user access policies will show the same sort of "paranoia" (read: focus on safety), ensuring compromised employees don't (or, more accurately, can't) abuse their privileges to do bad stuff.
On a more general level, this sort of awareness often reflects a vendor's overall ability to "think like an attacker" and secure itself from multiple angles/vectors of attack. No one practice, or set of practices, can prevent all attacks all the time, but there's no need to invite trouble by dangling data over attackers' heads. It may sound like common sense, but that's exactly what you want from your vendors anyway.
3. Less secure third-party code isn't tested with transparency.
It makes sense that vendors want to keep security vulnerabilities in their code under wraps. The more details about specific vulnerabilities that are made public, the more likely a malicious expliot will be developed.
Then there's the issue of proprietary intellectual property, after all, software source code itself is intellectual property of the vendor. Most vendors aren't comfortable distributing their source code to outside companies when it isn't required — another justifiable concern, given how easy it is to replicate and reuse code.
But the code still needs to be independently checked. Security-focused vendors understand this, and they are often amenable to using newer testing techniques that can check third-party code without actually exposing the source code. Independent services using these new techniques can be used like a sort of escrow service: hiring enterprises can effectively check every line of code while also satisfying the vendor's need for privacy. It's a middle ground for a tough situation, in other words, and that's huge, considering the risks that come with letting vendors grade their own proverbial tests.
Stay Vigilant
These three factors are only a few of the many things to consider when bringing a new third party into the fold. As always, don't be afraid to ask an expert for help while you devise ways to find your own red flags — and whatever you do, make sure you are looking for those flags to begin with.
Photo Source: Wikimedia Commons
