What We Can Learn From Automotive Recalls

What We Can Learn From Automotive Recalls

People in the software industry tend to think of themselves as pretty sophisticated from a technical perspective. We have plenty of “smart” devices (and know how to use them), are active on social media and are developing some very cool technology. In contrast to software, a lot of manufacturing companies may appear “old school” on the surface. In truth, manufacturing is highly sophisticated. It’s not easy getting all of that technology into the smart phone, not to mention building a machine that can fill 55,000 bottles of beer per hour.

What strikes me, however, is how far advanced many industries are compared to the software industry.

Automotive Recalls

Take product recalls in cars, for example.

In the automotive market, automotive recalls occur when a defect is discovered in a component. Once notified of the defective component by the vendor, car manufacturers issue recall notices to owners of affected vehicles as shown below:

Step 1 – Identify vulnerability in component version(s)

Step 2 – Vehicle manufacturer identifies affect vehicles by VIN number

Step 3 – Notify vehicle owners and schedule repair

Learn the 4 Risks in Connected Cars

Pretty simple, no?

The equivalent in the software world would be a vulnerability in an open source component. Here, the process is not so smooth. First, there is usually no notification process. Users of open source elect to include a component in their software, and are responsible for monitoring the component for updates. Next, nobody knows who has used the component, which versions, or in which applications. This means that all applications and systems need to be tested for the presence of the vulnerability, typically by using a vulnerability assessment tool like Nessus or Metasploit.

Step 1 – Identify vulnerability in affected versions

Step 2 – Issue fixed version and disclose vulnerability via National Vulnerability Database

Step 3 – For major vulnerabilities, a 3rd party generates a rule to identify presence of exploitable version

Step 4 – If an organization is aware of the vulnerability, use tool to test every application and system in your organization to confirm presence of exploitable version

Step 5 – Schedule update

Groundhog Day

Not a great process, but not terrible the first time you do it. The problem is, NVD has published over 6,000 new vulnerabilities in open source since 2014. To protect yourself, you need to go through this process, and scan every application and system, every day.

If the automotive industry followed this practice, for every product defect, every vehicle from a manufacturer that ever used a part from the component’s manufacturer would need to be scanned.

Why does the automotive industry have it easier? Quite simply, they track the components they use.

Every vehicle is built from a collection of components (similar to an application). Each vehicle includes a bill of materials that is unique to the vehicle’s VIN number. Since the component manufacturer knows which “version” contains the defect, and the automobile manufacturer knows which bills of material include affected versions, the process is straightforward.

Know Your Code

We can do something similar in the software world, simply by maintaining an accurate list, or bill of material, of the open source we use in an application, then monitoring threat feeds for information on new vulnerabilities. This allows us to know quickly when a “defect” is disclosed, be confident in declaring which applications are affected, and conduct efficient remediation.

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Now It’s Personal – 4 Takeaways From the Equifax Breach

| Sep 18, 2017

If you’re reading this, you have no doubt heard that personal information, including social security numbers, was stolen from Equifax – one of the Big 3 credit reporting agencies. From an industry standpoint, here’s a quick takeaway. Wait – For Once It Could Affect Me? For a lot of breaches, the

| MORE >

Critical Vulnerability CVE-2017-5638 Attacks Escalating

| Sep 14, 2017

 Attacks on Apache Struts 2 have escalated over the past couple of days as hackers exploit this critical vulnerability (CVE-2017-5638), which allows attackers to exploit a code-execution bug in the web application framework. Although a patch was available on Monday, hackers have been exploiting it

| MORE >

"Easy" to Hack Apache Struts Vulnerability CVE-2017-9805

| Sep 7, 2017

"This is as serious as it gets; if remote attackers are allowed to exploit the newly identified vulnerability it can critically damage thousands of enterprises." Oege de Moor, CEO and founder of Semmle. Dozens of Fortune 100 companies are at risk after security researchers at lgtm.com discovered a

| MORE >