Skip Navigation
security Security @lemmy.ml
Seirdy @lemmy.ml

The right thing for the wrong reasons: FLOSS doesn't imply security

I find people who agree with me for the wrong reasons to be more problematic than people who simply disagree with me. After writing a lot about why free software is important, I needed to clarify that there are good and bad reasons for supporting it.

You can audit the security of proprietary software quite thoroughly; source code isn't a necessary or sufficient precondition for a particular software implementation to be considered secure.

5 comments

  • Good article. Thank you. You make some excellent points.

    I agree that source access is not sufficient to get a secure software and that the many-eyes argument is often wrong. However, I am convinced that transparency is a requirement for secure software. As a consequence, I disagree with some points and especially that one:

    It is certainly possible to notice a vulnerability in source code. Excluding low-hanging fruit, it’s just not the main way they’re found nowadays.

    In my experience as a developer, the vast majority of vulnerabilities are caught by linters, source code static analysis, source-wise fuzzers and peer reviews. What is caught by blackbox (dynamic, static, and negative) testing, and scanners is the remaining bugs/vulnerabilities that were not caught during the development process. When using a closed source software, you have no idea if the developers did use these tools (software and internal validation) and so yeah: you may get excellent results with the blackbox testing. But that may just be the sign that they did not accomplish their due diligence during the development phase.

    As an ex-pentester, I can assure you that having a blackbox security tools returning no findings is not a sign that the software is secure at all. Those may fail to spot a flawed logic leading to a disaster, for instance.

    And yeah, I agree that static analysis has its limits, and that running the damn code is necessarry because UT, integrations tests and load tests can only get you so far. That's why big companies also do blue/green deployments etc.

    But I believe this is not an argument for saying that a closed-source software may be secure if tested that way. Dynamic analysis is just one tool in the defense-in-depth strategy. It is a required one, but certainly not a sufficient one.

    Again, great article, but I believe that you may not be paranoid enough 😁 Which might be a good thing for you 😆 Working in security is bad for one's mental health 😂

      • I am tired of people acting like blackbox analysis is same as whitebox analysis.

        I was very explicit that the two types of analysis are not the same. I repeatedly explained the merits of source code, and the limitations of black-box analysis. I also devoted an entire section to make an example of Intel ME because it showed both the strengths and the limitations of dynamic analysis and binary analysis.

        My point was only that people can study proprietary software, and vulnerability discovery (beyond low-hanging fruit typically caught by e.g. static code analysis) is slanted towards black-box approaches. We should conclude that software is secure through study, not by checking the source model.

        Edit: I liked that last sentence I wrote so I added it to the conclusion. Diff.

        Lots of FLOSS is less secure than proprietary counterparts, and vice versa. The difference is that proprietary counterparts make us entirely dependent on the vendor for most things, including security. I wrote two articles exploring that issue, both of which I linked near the top. I think you might like them ;).

        Now, if a piece of proprietary software doesn't document its architecture, makes heavy use of obfuscation techniques in critical places, and is very large/complex: I'd be very unlikely to consider it secure enough for most purposes.