Maybe this because of personal historical perspective but I think I have an idea as to why. PHP7 wasn't released yet and FB was the creator of it. I think those two decisions influenced using Hack (as the staff may have been big PHP users) instead of waiting for PHP7 and how it would be adopted/grow. Also, it supports typing arguments which was probably the idea to handle complexity.
I'm interested in knowing how many vulnerabilities in production code were actually detected. In my former companies, we used Fortify and Zalewski's old tool (seems to have dropped off the grid) with little benefit. The False Positive Rate was just too high for anything beneficial to come out of the so-called automated approach. We had engineers parse through tens of thousands of hits with no real vulnerabilities being found; this made the whole process a drudgery and a financial blunder in terms of work hours and licensing fees. On the dark side of the security industry, some people were making a lot of commission money on million dollars a year inert tools, because the business folks wouldn't get it.
To the best of my knowledge this is still a very open problem in the industry, and if any mention is made of it, in compliance standards or in implementations, it just serves as security theater.
4 comments
[ 2.4 ms ] story [ 24.2 ms ] threadIt must be incredibly hard to have rudimentary tooling to work on such a huge and complex system...
Static will catch things if their own fuzzing is worse than the bad actors.
It will be interesting to see how it compares to fuzzing. Logically and the practical outcomes.
( The treehouse is from here - https://cabane-et-vallee.fr/ )
To the best of my knowledge this is still a very open problem in the industry, and if any mention is made of it, in compliance standards or in implementations, it just serves as security theater.