5 ms·

There was a previous discussion [1] around a former Tesla employee discussing some of the "wtf" aspects of the software on Tesla vehicles. I'm willing to bet th

by mikejb 8y ago

There was a previous discussion [1] around a former Tesla employee discussing some of the "wtf" aspects of the software on Tesla vehicles. I'm willing to bet that some critical flaws will be found, as "fast development" and "secure development" are hard to get together, and it's safe to assume that Tesla ticks the "fast development" checkbox. [1] https://news.ycombinator.com/item?id=17835760 https://news.ycombinator.com/item?id=17835760

walrus01 8y ago
If even 30% of what that guy is claiming is true, the Model S has a huge attack surface. Hopefully things have improved since those claims were made.
friedman23 8y ago
> as "fast development" and "secure development" are hard to get together This is just not true. Software that often goes unupdated is the most insecure software of all. If Teslas are more insecure than other vehicles it will simply be because their software is more complex than the competition.
- mikejb 8y ago
  > This is just not true. Software that often goes unupdated is the most insecure software of all. You'll note that I never made comparisons on how secure Tesla software is in comparison to other vehicles, or that Tesla's software would be the "most insecure software of all". What I said is that Tesla's development is fast-paced, and this is difficult to do whilst maintaining software security. I agree with you that outdated software is a huge security risk, but I don't see how that contradicts with my statement on Tesla's software.
- Karunamon 8y ago
  You're both right in a way. Not having stuff up to date will definitely leave you vulnerable, but if the stories about Tesla's internals are valid, they are not expending the time necessary to ensure they don't write a boatload of security bugs in the first place.
- ygjb 8y ago
  yeah, except that in practice, alot of "fast development" happens on platforms where engineers ignore updates that aren't explicitly flagged as security because the want a stable environment, then when the security bug hits, they push back on deploying the security fix because of breaking functional and API changes in the dependency. I have worked in a broad range of orgs from start-ups with 4 people to government, fin-tech, and bay area tech companies and every single one has had the same stumbling block that has been a pain in my ass as a person responsible for assessing and helping engineers ship secure software.

by mikejb 8y ago

walrus01 8y ago

If even 30% of what that guy is claiming is true, the Model S has a huge attack surface. Hopefully things have improved since those claims were made.

friedman23 8y ago

> as "fast development" and "secure development" are hard to get together This is just not true. Software that often goes unupdated is the most insecure software of all. If Teslas are more insecure than other vehicles it will simply be because their software is more complex than the competition.

mikejb 8y ago
> This is just not true. Software that often goes unupdated is the most insecure software of all. You'll note that I never made comparisons on how secure Tesla software is in comparison to other vehicles, or that Tesla's software would be the "most insecure software of all". What I said is that Tesla's development is fast-paced, and this is difficult to do whilst maintaining software security. I agree with you that outdated software is a huge security risk, but I don't see how that contradicts with my statement on Tesla's software.
Karunamon 8y ago
You're both right in a way. Not having stuff up to date will definitely leave you vulnerable, but if the stories about Tesla's internals are valid, they are not expending the time necessary to ensure they don't write a boatload of security bugs in the first place.
ygjb 8y ago
yeah, except that in practice, alot of "fast development" happens on platforms where engineers ignore updates that aren't explicitly flagged as security because the want a stable environment, then when the security bug hits, they push back on deploying the security fix because of breaking functional and API changes in the dependency. I have worked in a broad range of orgs from start-ups with 4 people to government, fin-tech, and bay area tech companies and every single one has had the same stumbling block that has been a pain in my ass as a person responsible for assessing and helping engineers ship secure software.