# Using Heartbleed as a starting point

DevFeed: [Using Heartbleed as a starting point](<https://devfeed.tech/articles/using-heartbleed-as-a-starting-point-20667.md>)

Original publisher: [Read original article](<http://antirez.com/news/76>)

Published: 2014-04-10T09:06:18Z

Content type: opinion

Language: en

Sources: [Antirez](<https://devfeed.tech/sources/antirez.md>)

Topics: [openssl](<https://devfeed.tech/topics/openssl.md>), [Security](<https://devfeed.tech/topics/security.md>), [code security](<https://devfeed.tech/topics/code-security.md>), [Static code analysis](<https://devfeed.tech/topics/static-code-analysis.md>), [C](<https://devfeed.tech/topics/c.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [code-analysis](<https://devfeed.tech/tags/code-analysis.md>), [code-security](<https://devfeed.tech/tags/code-security.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [openssl](<https://devfeed.tech/tags/openssl.md>), [security](<https://devfeed.tech/tags/security.md>)

## AI overview

The article uses the Heartbleed vulnerability in OpenSSL as a starting point for discussing how to improve system software security. It argues for greater investment in security audits, open-source software development, and static and dynamic checks, while noting that changing languages or specifications is unlikely in the near term.

## Source excerpt

The strong reactions about the recent OpenSSL bug are understandable: it is not fun when suddenly all the internet needs to be patched. Moreover for me personally how trivial the bug is, is disturbing. I don't want to point the finger to the OpenSSL developers, but you just usually think at those class of issues as a bit more subtle, in the case of a software like OpenSSL. Usually you fail to do sanity checks *correctly*, as opposed to this bug where there is a total *lack* of bound checks in the memcpy() call. However sometimes in the morning I read the code I wrote the night before and I'm deeply embarrassed. Programmers sometimes fail, I for sure do often, so my guess is that what is needed is a different process, and not a different OpenSSL team. There is who proposes a different language safer than C, and who proposes that the specification is broken because it is too complex. Probably there is some truth in both arguments, however it is unlikely that we move to a different specification or system language soon, so the real question is, what we can do now to improve system software security? 1) Throw money at it. Making system code safer is simple if there are investments. If different companies hire security experts to do code auditings in the OpenSSL code base, what happens is that the probability of discovering a bug like heartbleed is greater. I've seen very complex bugs that are triggered by a set of non-trivial conditions being discovered by serious code auditing efforts. A memcpy() without bound checks is something that if you analyze the code security-wise, will stand out in the first read. And guess how heartbleed was discovered? Via security auditings performed at Google. Probably the time to consider open source something that mostly we take from is over. Many companies should follow the example of Google and other companies, using workforce for OSS software development and security. 2) Static and dynamic checks. Static code analysis is, as a side ef