Mitigate Risk by Securing Third Party Software And Environments

Software Security Requires Ongoing Vigilance Against New and Evolving Vulnerabilities

By Tim Kenney, Chief Operating Officer, SOOS

Businesses Need Software and Today’s Software is Built with Open Source.

Modern businesses need specialized software to run their organizations. Today, more than 90% of new software is built on open source components called packages.  Developers have access to an almost limitless array of open source packages to build their products, which has been transformational for the industry. Nearly every organization has adopted open source development; even the largest like Google, Microsoft and IBM. It makes development faster, easier and economical. The software needs of a business can get large: accounting, payroll, database management, asset management, communication systems, websites, payments, and sales management to name only a subset few.  Some verticals require specialty software that interface with devices (IoT) and those devices contain software. You and your clients need these systems up and running to deliver your products and services.

Attack Vectors May Be Lurking Inside Your Software

Unfortunately, each of these systems represents a security risk to an organization.  Often, within the open source components used to build custom software, vulnerabilities are lurking. This is the downside of modern development. Ransomware attacks, fraudulent financial transactions, and leaked confidential personal data all represent a reputational and financial risk for your business. Bad actors are waiting for mistakes, by your business, or by your vendors. Many businesses have focused on hardening their networks against attack and securing their users from phishing attacks and password hacking.  While these are good practices, they skip what has been a repeated root cause of some of the largest attacks, vulnerabilities in the software that businesses run or the software that runs on devices, unwittingly leaving their systems and data at risk

The consequences of these hidden vulnerabilities can be very expensive.  Equifax has said the data breach that started with an unpatched open source module has cost the company nearly 2 billion dollars since hackers gained access to their servers in mid July 2017.  Developers had used Apache Struts open source package. A vulnerability for this package was patched in the open source library on March 7, 2017, but developers at Equifax didn’t apply the patch for months, inadvertently leaving them open to an attack.

Unpatched systems represent a problem for even the largest software companies.  In 2021, Facebook had 533 million user data compromised and Linkedin had 500 million user profiles compromised due to open source vulnerabilities.  Recently, a very serious vulnerability was found in the Log4J package, a utility many software packages use for logging.  Apple’s Icloud service was vulnerable as was Microsoft’s Minecraft.  But the problem isn’t limited to just software running on servers or PCS, it impacts devices too.  Another vulnerability, NAME:WRECK, is believed to be in more than 100M devices.  Many companies have stepped forward with advisories including companies like Siemens, GE and  Lockheed Martin. These are all high-profile examples, but incidents like this are happening at companies of all sizes, across the country, every day.

Check during development & keep checking

The risks are significant, but not insurmountable. The good news is that open source packages mean more people working with them and vulnerabilities are found quickly and reported. When a vulnerability is found in these packages it is shared via some public databases like National Vulnerabilities Database (NVD), the Common Vulnerabilities and Exposures (CVE) or others like GitHub Issues usually with accompanying fix information.  New vulnerabilities can be posted at any time.  What was safe yesterday might not be safe today.  The vulnerabilities can be as severe as letting a bad actor take complete control of your system, capable of installing their own software for future use. There are automated tools for developers to make certain they are using packages that are secure.  These tools are called Software Composition Analysis Tools (SCA).  These tools can generate a Software Bill of Materials (SBOM) which contains all the components and may also contain the known vulnerabilities.

Additionally, care needs to be taken with another type of vulnerability, typo-squatting.  Typosquatting is when a malicious actor tries to place an open source package in a repository that is similar to a popular package but has vulnerabilities. Maybe a version number is changed or a single letter. These packages can run just like the legitimate package. Some SCA tools can highlight these potential vulnerabilities.

Developers can make mistakes in their own code that may not be caught by your quality assurance team. These mistakes / bugs can lead to security issues and they can be easy to overlook. Simply not checking a single input field can lead to a flaw that exposes a database through a vulnerability known as SQL injection.  Browser based applications are susceptible to another common form of attack known as cross site scripting where a website uses the input from the user within the output it generates at a later time without checking it.  APIs are also susceptible to these attacks.   These types of attacks can be reduced by running modern Dynamic Application Security Testing (DAST).  OWASP Zap is an open source version of such a tool.

There are additional tools for developer security during the build practice such as Interactive Application Security Testing (IAST),  Static Application Security Testing (SAST) and Runtime Application Self Protection (RASP).  These are tools your developers should be interested in but you wouldn’t be able to run without access to the underlying source code.

For IT professionals and software engineers, SCA and DAST should be considered a minimum security measure for software systems prior to bringing any software live.  Additionally, these tests should be redone on a periodic basis as new vulnerabilities are discovered at any time.  It’s a continuous process. If you can get the software bill of materials from your vendors, whether for software or devices, you can and should perform an open source vulnerability test on those components and versions. You should always request this, to hold your vendors accountable. Similarly, it would be best practice to run a DAST test against your delivered software and against any IoT devices that have an API or internal Web endpoint so you can be aware of vulnerabilities.

In summary: build securely, verify, deliver, test, and continue to test periodically to mitigate risk.

About the Author

Tim Kenney, Chief Operating Officer, SOOS. Tim Kenney is on a mission to democratize software security. As President and COO of SOOS, Tim and his team are dedicated to ensuring all developers have the tools they need to identify and remediate code vulnerabilities, making software safer for everyone. Prior to leading SOOS, Tim was President and CTO of MyWebGrocer, a pioneer in the online grocery and big data space. He also has deep roots in healthcare tech, as a former VP of R&D at GE Healthcare Information Systems and at IDX. He is a lifelong Vermonter and frequently shares his expertise with the Vermont State Government in a wide range of areas and has been a board member of Vermont Information Technology Leaders. Find him online at Twitter: @soostech, www.SOOS.io, https://www.linkedin.com/in/tim-kenney-vt/