Mitigating Inherent Security Risks Of Software Of Unknown Pedigree (SOUP)
Assuming that third-party suppliers are taking sufficient security precautions is a risky assumption. In actuality, the majority of externally developed software applications fail to comply with existing enterprise security policies upon first submission. As many as eight out of ten initial submissions will fail initial compliance audits. As SOUP is increasingly utilized among today’s enterprises, precautions such as vendor application security testing are an integral part of effective security.
Software developers build upon previous work and open-source code
Many of today’s developers make use of previously developed work that can be defined as SOUP. It’s more efficient to combine open-source, commercial software and previous code, adding new code and creative work to create the features and functionality needed to speed up development time and lower costs.
But when you’re using externally developed applications, especially a combination of software from multiple vendors, it’s difficult to know exactly what’s in the code. It’s important to be aware of the rules and licenses surrounding permitted use and alteration of third-party software, as well as have a thorough understanding of what’s in the code base.
Enterprises used to rely heavily on provenance
The main problem with SOUP—and one of the primary reasons some companies have been hesitant to utilize it--is that it can introduce security vulnerabilities. The Office of the Director of National Intelligence released a report in 2011, Securely Taking on New Executable Software of Uncertain Provenance (STONESOUP), outlining necessary steps for successfully incorporating SOUP while minimizing increasing inherent security risks across an existing software infrastructure.
Most software vulnerabilities originate in a program’s source or object code. But without using vendor application security testing, enterprises rely primarily on provenance to determine the validity and security reliability of third-party applications:
- Software that comes from a trusted company.
- Software developed using established and proven processes.
- Software developed by vendors with which the enterprise has a solid relationship.
While provenance provides a basis for determining which programs to consider, it fails to provide an adequate assessment of the true security of an application. Third-party developers, even if they conduct thorough application testing before releasing a product to customers, can miss inherent vulnerabilities as well as those that wouldn’t pass an enterprise’s strict security protocols. Using vendor application security testing is necessary to reduce the potential vulnerabilities introduced by SOUP and ensure that third-party applications meet at least the minimum security rules set forth by your enterprise.
Cross-site scripting and other vulnerabilities reduced through adequate security measures
About two-thirds of government applications have cross-site scripting (XSS) vulnerabilities, one of the major security risks with both third-party and internally developed applications today. Cross-site scripting allows hackers to insert malicious code through a web page, making it possible to obtain login credentials, financial information and other otherwise secured data—and once the initial data is obtained, sophisticated cybercriminals can use a single piece of information to gain access to vast amounts of an individual’s or enterprise’s proprietary data.
While XSS is just one example of the security risks associated with SOUP, XSS and other vulnerabilities can be reduced using vendor application security testing. Even if your company doesn’t have a full understanding of the source code used in third-party applications, vendor application security testing can analyze these applications against your enterprise’s existing security rules and protocols.
Eliminating the use of SOUP altogether is one way to avoid introducing inherent security risks and vulnerabilities that could be disastrous for an enterprise. But companies who want to continue to capitalize on reduced development costs and faster time-to-market by using SOUP see an increase in compliance of third-party applications when vendor security application testing is used as a standard.
About the Author
Fergal Glynn is the Director of Product Marketing at Veracode, http://www.veracode.com/security/web-security, an award-winning application security company specializing in spoofing attack guide from Veracode and other security breaches with effective risk assessment tools
Mitigating Inherent Security Risks Of Software Of Unknown Pedigree (SOUP) Reviewed by Ethical Hacking on 11:35 AM Rating: