Home  /  Empower and Protect  /  Assessing the Security Posture of Software Vendors

Assessing the Security Posture of Software Vendors

By Dan Sherman •  February 24, 2014

You have much more leverage in getting a security flaw fixed before you execute the contract. 

How many of you audit software before you purchase it, whether it is an enterprise application or something installed in that thing they call the cloud?  When evaluating software, business units need to evaluate not only whether the solution meets their business needs, but also whether it meets the security requirements of the organization. Based on the security of the offering, the risk of using the software or service may prove too high.

I know that many vendors like to wave a certification in your face or tell you that “someone” has evaluated their software and everything checked out. However, almost every piece of software I have ever looked at has some type of flaw or risk associated with it. You have much more leverage in getting a security flaw fixed before you execute the contract. Make sure you test the software or service, or at least have a report from a reputable company that has performed a thorough security assessment. If the company will not even consider letting you perform a vulnerability assessment on their software or service, you should seriously consider walking away – the risk is just too high.

Let’s take a look at some of the statistics from Veracode’s recent report,  State of Software Security Report – Volume 5:

70 percent of applications failed to comply with enterprise security policies on first submission

  • SQL injection prevalence has plateaued, affecting approximately 32  percent of web applications
  • Cryptographic issues affect 64 percent of Android and 58 percent of iOS applications
  • 87 percent of applications do not comply with the OWASP Top 10 upon first submission

Here’s an example to put this in perspective: if an organization were set to purchase a new web-based accounting system, moved their health benefits to a cloud provider (web-based), and implement a mobile device management solution (web-based, iOS and Android apps), there is a very good chance that one of the three new web-based applications will have SQL injections, XSS (cross-site scripting), or some other critical vulnerability.  On top of that, the chances of having security issues with the mobile applications are more than half.

To avoid running into these security issues, ask yourself the following questions:

  • Do they store credentials on the device?
  • Is it encrypted? Do they store session authentication in a cookie?
  • Do they store session rights in a cookie?
  • Do they store anything in a cookie?
  • Do they encrypt data using a standard security algorithm or did they make their own?

Putting a WAF (web application firewall) in front of a web server is not the answer to having a truly secure infrastructure.

One last note: just because it passed a security evaluation at the time of install does not mean that the software or service remains secure throughout its lifecycle. Continuously assessing your organization’s information security posture is critical.

The Empower and Protect Blog brings you cybersecurity and information technology insights from top industry experts at Telos.


  • Darrel Lowery says:

    Dan, GREAT advice! All software vendors and other partners in your supply chain are potential threats. In addition to your specific checks for software do’s and dont’s, I’d also recommend taking a look at establishing a general Supply Chain Risk Management (SCRM) program to determine and monitor vendors at multiple trust levels to ensure your internal systems and customer solutions are secure. DoD and NIST have good assurance policies for government system programs as does the Supply Chain Council’s SCOR model (Supply Chain Operations Reference model) to help manage your vendor supply chain risks.

  • Dan Sherman says:

    Darrel, thanks for the feedback. I know some organizations in the UK require that a source code analysis is performed and meets a certain level before they would even consider procuring 3rd party software. A failing grade would require the 3rd party software vendor to raise the level of security before entering into any agreement. I will look further into the programs you suggested. Thanks again.

  • Frank Johnson Frank Johnson says:

    Darrel and Dan — another article about the Target breach just came out that goes right to the issue of IT SCRM. It’s about Target’s HVAC contractor, whose systems were breached, which allowed the hackers to get into Target’s billing system, and from there their POS system. Here’s the money quote:

    The network lacked advanced authentication mechanisms, such as two-factor authentication, because, according to another source who managed Target vendors, “Target would have paid very little attention to vendors like Fazio, and I would be surprised if there was ever even a basic security assessment done of those types of vendors by Target.” Essentially, because of Target’s lack of preparedness, an experienced hacker had nearly unfettered access to its network after escalating Active Directory privileges. From there, it was a piece of cake to get into Target’s Point of Sale (POS) system data and extract credit card information.

    The Target Breach: How Network Security Best Practices Could Have Prevented It

Leave a Reply

Your email address will not be published.

ten − five =