Supply-Chain Risk: The 3 Most Popular Practices for Addressing RiskThe past few years have shown that as external network defenses become stronger, applications truly are the new security perimeter. Many enterprise CISOs have developed robust testing processes and programs for internal applications but don't quite have a handle on how to effectively expand those programs to include third-party software. For application security, supply-chain risk is at an all-time high as more and more enterprises rely on third-party and open-source software within their development environments, so CISOs have to learn how to best address this risk in both a meaningful and cost-effective manner.

This growing problem with security and the software supply chain is starting to get the attention it deserves, and CISOs finally have some documentation regarding successful practices to build their programs around. A new advisory report from 451 Research is one of the latest publications to shine a light on this subject. The report, titled "Third-Party Software and Supply-Chain Risk," utilizes eight interviews with security executives to find out both what major obstacles have to be overcome and what processes are currently showing success.

The Third-Party Risks

The report found that the obstacles businesses face with third-party software can be daunting. Third-party software is often used in non-mission-critical applications, resulting in a lower risk classification and a reduced likelihood that the software will be properly checked. This type of risk classification doesn't take into account modern interoperation and how major breaches can occur from vulnerabilities in the smallest of programs. Third-party software is also often assumed to be secure based on assurances from the vendor or community that produced it, but this is rarely the case. When asked about software as a whole, one security professional stated that even after four years of strict security testing within the business, 96 percent of software still fails on its first security test. The reality is that if security isn't prioritized, the outgoing software is usually not secure, despite assurances to the contrary.

On the positive side of things, the 451 Research report did list a number of processes and methods that successful organizations are currently utilizing to minimize their third-party security risk. CISOs currently operating without a standard testing program for third-party software would do well to consider these ideas as a starting point for their eventual security program:

Talk to Developers Directly

Third-party software compliance is often done through assessments and checklists sent to the vendor, but even if the vendor is as honest as possible, the person filling out the checklist is likely in the sales department and can unintentionally stretch the truth in order to make the sale. Speaking directly with the people creating the software can go much further in ensuring they are taking the appropriate security measures and will also ensure that questions and requests are fielded by someone who fully understands them.

Outsource Some Testing

Most enterprises will test at least some of their software in-house, and while not necessarily a bad thing, it can lead to some issues. With in-house testing, it's easy to allow prioritization to relegate third-party apps to the "don't test" pile, working off the assumption that they were checked by their developers. The testing processes also tend to be static over time, even as the threat landscape changes. By outsourcing at least some testing to a professional InfoSec business, enterprises can get an adaptable, scalable and robust solution that will help ensure all applications are fully tested against modern threats, including third-party apps — and not just those the InfoSec team has the time and resources for.

Utilize Existing Standards

When assessing third-party software, it's imperative to have a basis for your testing generated by an independent third-party. Standards like the OWASP Top 10 are a powerful tool not just because they identify modern vulnerabilities, but also because it becomes a black-and-white issue with a developer whose software fails to meet the standard. With in-house questionnaires and audits, there can be some gray areas that allow insecure software to pass through, while failing a test against a baseline of industry-accepted standards tells all parties that the failing software needs to be updated before it can be released.

For CISOs worried about third-party software, the 451 Research report provides a plethora of additional information on how to migrate a security process to cover third-party software as well. The addition of an outsourced InfoSec business to the process may be the single most powerful thing a CISO can do, but there are numerous other aspects of third-party risk that must be acknowledged and addressed by each individual enterprise. The findings in this report can be an excellent starting point for all businesses looking to secure their third-party software.

Photo Source: morgueFile

Shawn Drew has spent the last five years helping businesses understand the difference that technology can make for their internal processes, external connections, and bottom line. He specializes in all things cloud computing and security, and hopes to impart some knowledge on how the two can be combined to enhance the inherent benefits of each. His work has been published on the websites and blogs of a number of technology industry leaders, such as IBM, Veracode and Boundary.



contact menu