If they really wanted to make open source more secure they would just pay people to audit & submit fixes to widely used open source software. Of course the reality today is that the opposite occurs -- when federal intelligence agencies find out about vulnerabilities they prefer to keep the exploits for themselves.
'Securing Open Source Software Act' introduced to US Senate
81–90 of 187 posts
Re: 'Securing Open Source Software Act' introduced to US Senate
#82Why can't they treat this like academic / scientific work and create a funding body around grants that support OSS devs so they have more time and money to protect the software?
Re: 'Securing Open Source Software Act' introduced to US Senate
#83Why limit it to open source? You wouldn't let an engineer build a bridge with car-sized holes just because the blueprint is not open.
There are different questions that should be asked when choosing open source software vs proprietary software. If you're using proprietary software, you might ask things like, "what's your SLA?", "can we review the source code?", or "how much is a license?" If you're using open source software you might ask things like "is the project maintained?", "who developed it?", or "do we have anyone on payroll who knows how t…
For the sorts of purposes described in bill-blurb, the questions would be essentially identical.
Re: 'Securing Open Source Software Act' introduced to US Senate
#84Earlier quoted context omitted.
Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, t…
Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion. The primary factor driving the decision making process is not cost but risk. Many fail to remember the lengths to which companies like Microsoft, Oracle, Sun and others went to create FUD around the adoption of OSS in the public sector. It involved lobbyists, ma…
>Companies with expensive tools have an obvious interest in convincing their best customers that the competition is inherently risky
Honestly I’m embarrassed at how revelatory this line is.
Re: 'Securing Open Source Software Act' introduced to US Senate
#85DHS (Dept. of Homeland Security) CISA (Cybersecurity and Infrastructure Security Agency) CSAC (Cybersecurity Advisory Committee) TAC (Technical Advisory Council) subcommittee report, June 2022, https://www.cisa.gov/sites/default/files/publications/June%2... > The Technical Advisory Council Subcommittee was established to leverage the imagination, ingenuity, and talents of technical experts from diverse background and…
one of those is a political liberal turned spy-for-hire .. this does not look like a list of Fortune 500 shills from here
Re: 'Securing Open Source Software Act' introduced to US Senate
#86Reading the comments so far, I'm genuinely surprised that more folks haven't applied a "follow the money" lens to their analysis. To me, it reads as a bald-faced attempt to discourage public sector entities from using OSS solutions, when in fact there are perfectly good and definitely >100% secure proprietary offerings that cost a reasonable amount when purchased from the sorts of vendors that pay lobbyists to "help"…
While skepticism is fair that should be motivation to do research to possibly find evidence of an ulterior motive.
However just saying that all legislation is some scam without evidence doesn't make sense.
For example, and I don't know the exact name, but the health care transparency act where pricing for treatments or whatever must be published. Who is that helping if you follow the money?
Edit: I should have been more clear but ulterior motive to benefit large companies who sell software, or something that harms OSS.
Re: 'Securing Open Source Software Act' introduced to US Senate
#87Earlier quoted context omitted.
> Federal contractors don't need to sell proprietary software to make money -- they make more money selling FOSS software. tech companies in general are making billions using FOSS.
Of course, which is why I think viewing this as a push for proprietary software is not a fair assessment. Increasing your company's development costs is not a way to make more profit. The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, t…
> process and governance model that proprietary software does.
except that a lot of proprietary software doesn't has anything like that either
there is nothing in common proprietary dev practices which would have e.g. prevented log4j
the main difference is that you can hold someone financially responsible in one case and not in the other (but in turn you can always fix any problem yourself, good luck fixing any proprietary software after it's support runs out).
Re: 'Securing Open Source Software Act' introduced to US Senate
#88Earlier quoted context omitted.
Ehh, I don't disagree with where you start but I do with where you end. If it is a money thing then it probably has more to do setting up "standards" and "compliance" requirements that you must me to use FOSS software in the government. Then federal contractors and other big FOSS organizations repackage their existing solution as "Government ISO-MITRE, PCI, Whatever-BS-Acronym-we-can-come-up-with" compliant and charg…
These corporate sponsored legislators are really good at writing policy that sounds good to the public but really helps their corporate sponsor's bottom lines in practice. This bill wouldn't exist if it wasn't designed by large corporate software firms looking to taint, or profit from, FOSS in some way.
100% sure? Why not find out if that's true because I'm sure there are exceptions.
Re: 'Securing Open Source Software Act' introduced to US Senate
#89Earlier quoted context omitted.
Additionally, “The legislation also requires CISA to hire professionals with experience developing open source software to ensure that government and the community work hand-in-hand and are prepared to address incidents like the Log4j vulnerability.” So we should definitely expect at least some minute changes to the open source economy, itself.
This is the worst part. "Experience developing open source software" is both entirely vague and specific at the same time, likely conjuring up an image of some developer with green boxes on a GitHub repo or something, which is terrible. This is going to force the creation of some sort of silly criteria for what constitutes that experience, of which suits in federal agencies, and the political pressure and politicians…
You are focusing on the hiring requirements which is very vague. What would be a better way to define hiring requirements?
Re: 'Securing Open Source Software Act' introduced to US Senate
#90LF OpenSSF "criticality score" for 100K Github repos, https://github.com/ossf/criticality_score & https://docs.google.com/spreadsheets/d/1uahUIUa82J6WetAqtxCM...
> Generate a criticality score for every open source project. Create a list of critical projects that the open source community depends on. Use this data to proactively improve the security posture of these critical projects ... A project's criticality score defines the influence and importance of a project. It is a number between 0 (least-critical) and 1 (most-critical). It is based on the following algorithm by Rob Pike..
Top 20 projects, based on "criticality score" algo output, you can run the script on your favorite OSS project:
> node, kubernetes, rust, spark, nixpkgs, cmsSW, tensorflow, symfony, DefinitelyTyped, git, azure-docs, magento2, rails, ansible, pytorch, PrestaShop, framework, ceph, php-src, linux