2 ms·

How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful f

How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful feedback at a fraction of the cost of a full on audit.

Alupis 10y ago
I agree with the sentiment of your post, however I believe it is based on an ideal world, which we don't live in. > How many of the people that do review your code would exploit it vs reporting it to you By nature, attackers would be reviewing your code as well. > Combine it with a bounty program The overwhelming majority of Open Source software was created-by and is curated-by a single person who makes negative profit by working on the software for free in their spare time. Even some of the most popular projects are still total losses for their curators. You're not going to get bug bounty programs here. For example, take a look at Crosstool-ng[1] (a popular project used to build cross-compilers for various architectures). Companies and individuals are all using this project to build cross-compilers that they trust to build other software with. A bug in Crosstool-ng could propagate into bugs in the compiled software it produces. Bryan Hundven does most of the heavy lifting on this project by himself, and as far as I know, he's paid nothing for it. You're not going to get a bug bounty program here either. Heck, it's doubtful even a project as large as the Linux Kernel would be able to afford an ongoing bug bounty program. They're trying with the Linux Foundation and the Core Infrastructure program, but how many years before did it have none of that? Essentially, these programs only work for commercially-backed software, which is only a small sliver of open source software. [1] https://github.com/crosstool-ng/crosstool-ng https://github.com/crosstool-ng/crosstool-ng
- IgorPartola 10y ago
  But I am specifically talking about companies with closed source apps and services open sourcing them, not tools that are already open. Examples are Uber, AirBnB, and Groupon, not gpg or OpenSSL.
  - Alupis 10y ago
    > But I am specifically talking about companies with closed source apps and services open sourcing them Ah, I see. I misunderstood. Yes, I think we are in agreement then, although I have my doubts most companies want their "secret sauce" or code-indiscretions flapping in the wild.
    - IgorPartola 10y ago
      I think it depends. The exact PageRank algorithm, or the process that Uber uses to route drivers: probably not. The UI to any of that: why not? I think there is very little secret sauce out there and most of the stuff is just bog standard code that would do no harm being in the open.
      - Alupis 10y ago
        Couldn't agree more. I think the largest hurdle for getting more stuff open sourced is two-fold. 1) A large amount of software is sub-par, and likely commits many atrocities including having business logic in the UI. 2) Companies are afraid they'll be embarrassed by their code, and would rather not take the risk of being branded as a company that doesn't do things right. For number 1, there are potential solutions by hiring better engineers etc... but number 2 is always a (perceived) risk, even if their codebase is "perfect".

Alupis 10y ago

I agree with the sentiment of your post, however I believe it is based on an ideal world, which we don't live in. > How many of the people that do review your code would exploit it vs reporting it to you By nature, attackers would be reviewing your code as well. > Combine it with a bounty program The overwhelming majority of Open Source software was created-by and is curated-by a single person who makes negative profit by working on the software for free in their spare time. Even some of the most popular projects are still total losses for their curators. You're not going to get bug bounty programs here. For example, take a look at Crosstool-ng[1] (a popular project used to build cross-compilers for various architectures). Companies and individuals are all using this project to build cross-compilers that they trust to build other software with. A bug in Crosstool-ng could propagate into bugs in the compiled software it produces. Bryan Hundven does most of the heavy lifting on this project by himself, and as far as I know, he's paid nothing for it. You're not going to get a bug bounty program here either. Heck, it's doubtful even a project as large as the Linux Kernel would be able to afford an ongoing bug bounty program. They're trying with the Linux Foundation and the Core Infrastructure program, but how many years before did it have none of that? Essentially, these programs only work for commercially-backed software, which is only a small sliver of open source software. [1] https://github.com/crosstool-ng/crosstool-ng https://github.com/crosstool-ng/crosstool-ng

IgorPartola 10y ago
But I am specifically talking about companies with closed source apps and services open sourcing them, not tools that are already open. Examples are Uber, AirBnB, and Groupon, not gpg or OpenSSL.
- Alupis 10y ago
  > But I am specifically talking about companies with closed source apps and services open sourcing them Ah, I see. I misunderstood. Yes, I think we are in agreement then, although I have my doubts most companies want their "secret sauce" or code-indiscretions flapping in the wild.
  - IgorPartola 10y ago
    I think it depends. The exact PageRank algorithm, or the process that Uber uses to route drivers: probably not. The UI to any of that: why not? I think there is very little secret sauce out there and most of the stuff is just bog standard code that would do no harm being in the open.
    - Alupis 10y ago
      Couldn't agree more. I think the largest hurdle for getting more stuff open sourced is two-fold. 1) A large amount of software is sub-par, and likely commits many atrocities including having business logic in the UI. 2) Companies are afraid they'll be embarrassed by their code, and would rather not take the risk of being branded as a company that doesn't do things right. For number 1, there are potential solutions by hiring better engineers etc... but number 2 is always a (perceived) risk, even if their codebase is "perfect".