Thoughts On The NTIA Software Component Transparency Meeting

NTIA National Telecommunications & Information AdministrationI was able to attend the NTIA meeting on Software Component Transparency on July 19th, 2018 hosted in Washington, D.C. at the American Institute of Architects. The meeting was webcast and might eventually be published for others to watch in the future.

This was our first time attending (though we really should have been at the previous meetings), and the meeting was well done from our perspective. Allan Friedman, who was the moderator/facilitator, was quick to point out how these meetings can be chaotic and have their moments, but I really didn’t see that in this session. Perhaps it was a sign of people playing well in the sandbox together. There were a lot of different perspectives due to having security vendors, software vendors, end consumers, and government agencies in attendance.

As a new attendee, I went into the meeting intentionally focused on listening and learning as much as possible, rather than expressing my opinions or having my comments viewed as pushing our VulnDB product. This was really challenging at times. I’d encourage other outspoken security practitioners in our industry to give it a try! When focused only on listening, one tends to hear all that is said rather than concentrating on what to say next. So, while I was biting my lip a lot to make sure I was hearing everything, I decided to take my own extensive notes. Here are my thoughts and observations from the meeting.

Almost all participants’ comments kept coming back to vulnerabilities.

  • This makes sense as the main use case for everyone is to understand if they are using vulnerable libraries in their own software, but the meeting wasn’t intended to focus much on the vulnerabilities themselves. Rather, the purpose was to focus on the “SBoM” topic (Software Bill of Materials), so many times it was stated: “Let us focus on the SBoM.” However, the SBoM is so closely tied to the vulnerability aspect that it repeatedly came up in conversation. This validates the critical relationship between the SBoM and vulnerability interaction.

CVE is incomplete.

  • This isn’t news and has been the case for a decade. We should collectively just agree that this will not change dramatically or sufficiently enough to provide a service for proper vulnerability management in the next decade. Either way, it was refreshing to hear so many people acknowledge that CVE/NVD is incomplete.
  • Despite a general consensus that it’s inadequate, many vendors in the room still stated that they only use CVE! This is pretty horrible for the security ecosystem. At what point are there potential legal implications for a company that knowingly relies solely on incomplete vulnerability data?

It is important to know that libraries are often not researched properly.

  • Just because there isn’t a known or published vulnerability doesn’t mean the library is secure. As an example, one new Risk Based Security (RBS) client couldn’t find 40 products in VulnDB that they wanted to monitor and wasn’t sure if it meant that there were no known vulnerabilities in those products or if we weren’t monitoring them. We have support plans that allow our customers to ask for products and libraries to be researched. In this case, 20 of those products (50%) then investigated by the RBS research team were found to have vulnerabilities in them! So, it is important to recognize that unless someone is incentivized to spend the time to find the vulnerabilities and disclose them, then it isn’t happening.

Make sure you are using the “right” libraries.

  • This is another reason why an SBoM is so important from a strategic standpoint. Organizations need to implement more problem management/root cause analysis on the products and libraries that they are using in their software. Too many companies play whack-a-mole with vulnerabilities, and are only using data from CVE, which makes it an even bigger problem
  • There are some libraries or components that are not going anywhere for many organizations. Even if they wanted to get rid of one, they would find it difficult or even impossible. However, it is important to know more details when there are options and most definitely prior to selecting a new library.
  • Reviewing an SBoM and then seeing which libraries are most likely to put you at risk for a compromise is essential these days. Vendor and product ratings can help accomplish this: these ratings let you understand the code maturity of the libraries, and the history of how long it takes for a vendor to get fixes published etc.

Library upgrades can often introduce breaking changes.

  • This makes it extremely challenging to rush these fixes into your own codebases. For this reason, libraries that are built with security in mind, and don’t have a lot of vulnerabilities to begin with are, obviously, preferred.  We publish Code Maturity metrics among others in VulnDB to give clients perspective on how many vulnerabilities and work they can expect to maintain security for each library.
  • Furthermore, there are a lot of vendors (and even security vendors), who believe that most vulnerabilities don’t need to be fixed; they reason that if it isn’t exploitable by their analysis, then it is not worth addressing.

Some vendors in attendance focus only on fixing vulnerabilities that have public/known exploits.

  • While this is a valid criteria to help prioritize, only fixing these vulnerabilities is a very concerning approach. For the most part, the exploitability of a vulnerability is not fully known until it actually happens and at that point it is too late for people to scramble to apply fixes.
  • To further complicate this approach, there are often times when there are disagreements on what is considered exploitable by different vendors and researchers. Discussions around a vulnerability that can be exploited versus likely to be exploited can be highly contentious. Some vulnerabilities seem straight-forward while others seem theoretical, but history has proven many times that “theoretical” may be the infamous “famous last words”. One person’s “theoretical” issue is another person’s working exploit.
  • Year over year, we see approximately 30% of vulnerabilities with a public exploit or sufficient details available to trivially create one.  Here were some quick statistics I pulled right after the NTIA meeting:
    • 2017 (6892) – 21,834 total vulnerabilities – 31%
    • 2018 (3566) – 11,674 total vulnerabilities – 30%

Mapping of packages/components to common standard is going to become even more important.

  • CPE is painful to work with as it is. For tracking vulnerabilities in libraries it is even less useful, and no one is generally suggesting that this be the standard moving forward. There are quite a few other standards including SWID, SPDX, CycloneDX, Package URL, and others.
  • There was a lot of discussion at the meetings on naming standards and which one is the best. The truth is that currently none of them really meet the needs of everyone. While each standard seems to have its supporters and people lobbying that it be used, we hope that one will ultimately be picked as the recommended approach. PackageURL appears to solve most of the mapping issues alone, but from the meeting it looks like some form of SPDX combined with PackageURL might be the best approach forward.

Security Through Obscurity is still important to many vendors.

  • This concept is still a big issue for a lot of vendors and was on people’s minds during the meeting. Most vendors don’t want anyone to know their attack surface as it could be used against them. Many also don’t want attackers to know any vulnerabilities as well, but that is simply impossible.
  • While a lot of people believe that security through obscurity isn’t a valid approach, in some ways knowing this information does help focus researchers or motivated/funded attackers to research the software that they need to use to accomplish their goals/attacks.
  • Many vendors and companies just do not want to provide a SBoM at all. Everyone has some skeletons in the closet from old libraries or things that have not been done quite as they should have along the way, such as:
    • Using libraries without honoring the license
    • Using outdated and vulnerable libraries

Make sure others outside of IT security are involved in the SBoM conversations.

  • There are many other departments at an organization outside of security that are interested in an SBoM. This includes procurement and legal as they need this information as well. Instead of trying to push this solely as a cyber security issue, it is important that each organization engage other departments including those involved with ITIL processes, and hopefully they will be included in future NTIA meetings as well.

The meeting went over a lot of topics and was very productive overall. Solving the SBoM situation is complicated but needs to be done sooner rather than later. It appears the issue for some organizations is largely already done and just needs some additional aspects pulled together to make it more effective, and for other organizations to get on board with a single standard. Too many forks, too many disparate things, leads to more problems as we have seen with prior ‘standards’.

Based on the first NTIA meeting, it was encouraging to see that more attendees appeared to agree on this topic than do not. It will be interesting to see what additional material and accomplishments can be produced via subsequent working groups, and we at RBS are excited to continue to be part of the process.