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" senators write OSS bills.
Do you honestly think Rob fucking Portman woke up one day with strong opinions about FOSS?
Make no mistake: this is a thinly veiled late-stage attempt to displace the growing dominance of OSS-based solutions to the sorts of problems that the government and military used to pay 8 and 9 figures a year to EDS to solve.
An actual, good-faith bill that seeks to address these issues would attempt to incentivize/punish orgs that use FOSS without making meaningful contributions to it.
I don't buy it. More like, log4j was an actual real big issue for government agencies because they use rely on tons of open source projects and haven't previously done much to make sure that that supply chain is robust. This would help to change that.
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.
I'm doubtful that anything short of requiring thorough security/pen testing on everything in the dependency tree would have prevented log4shell. And if that is the goal here, who is going to pay for that? Most open source projects don't have that kind of funding.
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 charge a premium over something they already sale.
I don't think this will hurt FOSS, at the end of the day FOSS is nothing more than someone saying "here's something I wrote or whatever." and sharing it, anything that tries to make more than that isn't talking about FOSS anymore.
The reality is, the greatest vulnerability here isn't in government-procured software that uses OSS libraries directly. The DoD's own critical custom applications are largely as secure as secure gets. The much bigger problem is in proprietary software, like the Atlassian suite, that uses OSS libraries in its own supply chain.
In fact, the DoD has had mandates from the highest level for years to use FOSS everywhere it is available, and to require all new contractors to open source anything they create for government use that isn't classified. The only reason something like the Atlassian suite is still used is a combination of institutional inertia and the lack of comparably feature-complete FOSS alternatives (the vast majority of this kind of space going to SaaS companies that don't allow you to self-host).
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.
Holy shit this is a terrible idea. I can’t think of a better way to discourage people from using open source than to punish organizations for “not making meaningful contributions” to it. As a heavy open source user, contributor, and author, I’m begging you to stay the fuck away from regulating users. That’s the fastest way to destroy open source.
It's not like closed source software is magically immune to vulnerabilities
Seems a bit contradictory to the license terms. Gonna be a trick to get legislation to enforce something that isn’t in established contractual language.
Edit: on the positive incentive approach, getting double-funded with discretionary budget for every FOSS developer they hire might be a viable strategy.
how is that even possible
Did you mean <100%?
That part confused me too - I believe it's meant to be sarcastic. There's a kind of humor that I often don't get until further reflection, which is a way of saying things that are so overboard and absurd that the speaker cannot possibly believe what they're saying. Or rather, the speaker is saying the opposite of what they mean, in order to make their point. Might be a cultural thing.
This kind of humor is even harder to recognize these days, when people honestly do believe the absurd things that they're saying.
> The Securing Open Source Software Act would direct CISA to develop a risk framework to evaluate how open source code is used by the federal government. CISA would also evaluate how the same framework could be voluntarily used by critical infrastructure owners and operators. This will identify ways to mitigate risks in systems that use open source software. 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. Additionally, the legislation requires the Office of Management and Budget (OMB) to issue guidance to federal agencies on the secure usage of open source software and establishes a software security subcommittee on the CISA Cybersecurity Advisory Committee.
So basically just another framework to evaluate risk for use by the Federal Government. A nothing burger as it were. Which I am on one hand glad about, because I don't like the government starting to get involved in Open Source which is at it's core "Here's some code I wrote or whatever", but it also isn't doing anything for security.
“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 a genuine question, I'm honestly not sure what the consequences, intended or otherwise, could be?)
IBM will offer quotes for whatever is required within 2 quarters or less.
https://en.wikipedia.org/wiki/Security_Technical_Implementat...
Open source doesnt need a special response process, and the only reason you'd want one is if youre old guard like Symantec, F5, VMWare, or Veritas and starting to become alarmed at the amount of business you're losing to open source now that "devops" is starting to catch on and a recession is in effect.
Imagine a job where all you do is meetings, and never have to deliver anything. That dream is a reality in government. There's a problem with something? Let's make a committee. Let's create paperwork. But now we're managing more things, so we get bumped up to a more prestigious position. - this goes on and on.
It operates despite inefficiency. Because it's artificially propped up by tax dollars. No one is responsible, it's free money.
This kind of feels like doing something for the sake of doing something about log4shell, without actually solving any problems. And will undoubtedly result in the government paying more taxpayer dollars for software that complies with this new framework.
“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.”
There's no way to actually know. Everything not based on the text of the bill is pure speculation.
States are where you need to worry. Occasionally a state decides to pass a law[0] saying they can't be sued for certain copyright violations. Because of how the US constitution is set up, states (and nothing smaller than them) are allowed to just say they can't be sued, which lets them crime with impunity.
[0] https://www.npr.org/2020/03/24/820381016/in-blackbeard-pirat...
If you want to avoid having to pass tests, having to maintain insurance, having to do a bunch of bullshit, all just to be a software engineer, get started on fixing things now.
It is absurd that anyone can anonymously provide open source code, with no assurances whatsoever, and that can end up in critical software. And you might be saying "well, it's up to people to audit their dependencies" - and maybe you're right. But I would challenge that everyone has the right to publish code for distribution purposes with zero responsibility.
Publishing code to Github? Sure, go for it, anyone can do it. Publishing packages to package distributors ? No, that crosses a line. I don't want legal requirements, I don't want identification requirements, just to publish and distribute code.
If we want to avoid that we're going to need to step it up - that means, yeah, basic measures like strong 2FA to distribute packages should be a requirement. Signing packages should be a requirement. Acknowledging and triaging vulnerabilities should be a requirement. If you aren't willing to do the above, which is frankly trivial, you shouldn't be allowed to publish software for distribution purposes.
I think we need to start taking a bit more responsibility for the work we do. "NO WARRANTY" doesn't mean "No obligations", it just means no one has a legal right to pursue damages due to your software, you should still do some things.
edit: K I'm rate limited so I can't have this conversation with all of you, thanks again Dang
Consumer protection laws tend to expect that consumer products should be safe by default. Products intended for professionals and businesses often have fewer requirements, but they should also be safe with reasonable precautions. Someone in the supply chain must take responsibility for that.
As is common in legal matters, this is more about intentions and reasonable expectations than exact definitions. GitHub can probably avoid responsibility by arguing that it's just a platform that allows developers to share their code. If you are hosting a popular package repository for some programming language, you must take some responsibility as the distributor, even if your users can be reasonably expected to be sophisticated. And if you are hosting a package repository for a consumer OS, you should probably take consumer protection laws into account.
> pull that code in without looking at it
Is no longer reasonable. The dependency chains are too vast to expect the end-user to be able to audit the whole thing.
There are a couple of options:
1) Don't use open-source code, and make sure that commercial code that you use doesn't have it.
2) Have some kind of "regulated middleman" auditors, or certification authorities, that can certify (and probably hash) "approved" open-source chains.
They both suck. I worked for a company that did #1. They hired a company (can't remember the name, but it started with "P") that scanned our entire codebase, looking for open source.
#2 is likely to result in either corruption, or "roadblocks," where we can't use new fixed libraries, because the chain hasn't been audited, yet.
> The problem is that somewhere someone who is supposed to be held to some standard decided to pull that code in without looking at it
Why is it that there is no standard applied to those who publish code for distribution purposes? Why do we want that to be the case? Again, publishing to Github or some source repository is fine, that should never ever be restricted, but publishing with the express intent for others to use it? I don't get why we're trying to ensure that that's something that shouldn't at least imply the bare minimum of assurances.
> if people share their code for free, they don't owe anyone anything
My point is that they don't legally owe anyone anything but we should impose a moral standard in lieu of a legal one. If you are saying "here's this code, I've packaged it up and sent it out for distribution" I think it should be perfectly fine for us to say "did you do the bare minimum to make this code acceptable for others to use?".
I don't get why we say "you have no ethical obligations in open source", why do we do that? Who benefits? I get not having legal obligations, but once you're distributing code for use it seems absurd to say that you have no ethical obligations. You chose to do that, you chose to distribute it, you didn't have to do that.
And while I do think that the obligation exists regardless, I also feel that if we don't step it up here, these things are going to be forced on us. I'd rather we do it ourselves.
While you're welcome your position and your ideas on how to solve these problems, I believe that the logic you're applying punishes the provider and not the consumer. Nobody is forcing anyone to use OSS without auditing every damn line, if that's their requirement.
Telling people that share their hard work with strangers for free that they have an ethical responsibility to accept vague "obligations" - as defined by lobbyists and politicians - is not an idea with wings.
There is no analogy. The only reason why other engineering disciplines are not adopting software practices is because the other engineering fields are not easy to iterate. You build a bridge. And then you could maybe get some funding to improve one part of it a decade afterwards. Because it is too expensive and cumbersome to do it.
When IoT, AI, nanomachines, 3D printing proliferate, you will see how that will change. Devices and buildings will be possible to iterate, and they will have versions that get incremented as they are improved.
...
As for obligations, the existing law already covers it. From GDPR to payments compliance, everything is there. And a lot of the best practices are invented and standardized by Open Source, actually.
...
What Open Source still lacks is the mindset to approach end-users and consumers and be able to get them on board. Open Source needs to take the route of 'no backwards compatible changes', and even 'add, never deprecate' (like JSON project) along with the habit of hiding complexity from end users and making things easy.
Then we can create a truly Open Source world in which there will be infinite new possibilities.
We killed 100% of our Java usage over this. We simply don't have enough in-house talent to make sure things are safe in that bucket. Our customers thought this was a glorious plan as well.
I do think most of the pain should fall to the vendors of the end product, not their oss suppliers. If your shop doesn't have enough resources to validate all vendors are safe, maybe figure out how to do it with fewer vendors.
At a certain level, if you are selling deficient products to sensitive customers, you really need to be stopped. Anything impacting finance, PII, safety, infrastructure, defense, etc. Some extra regulations could go a long way in these areas.
Did you ditch ssl over heartbleed?
Joking aside, they do actually have a github: https://github.com/cisagov
Risk frameworks are important, but they're not something you need the NSA to help you accomplish.
It doesn't take the NSA to do things like:
"Make a list of dependencies"
"Make sure that they have active developers"
"Check the list of dependencies for vulnerabilities"
"Look in the commit history to make sure one doesn't say 'People's Liberation Army -- implementing backdoor'"
To not disclose them is an opportunity to legit spy whatever using scapegoats (ie. North Korea hackers did that, etc.) and to legit sue or accuse enemies of using them (if they fix it, attackers won't attack).
It's going to be like electrical contracting. You get someone cheap to do the wiring and then a union guy comes in to sign the papers and take a pound of flesh.
> 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
They can check out the Securing Critical Projects working group, https://github.com/ossf/wg-securing-critical-projects
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 thing works?"
So yeah, it makes sense to treat them differently, at least in some respects.
> The Technical Advisory Council Subcommittee was established to leverage the imagination, ingenuity, and talents of technical experts from diverse background and experiences for the good of the nation. The subcommittee was asked to evaluate and make recommendations tactical and strategic in nature. These Cybersecurity Advisory Committee (CSAC) recommendations for the June Quarterly Meeting focus on vulnerability discovery and disclosure.
Mr. Jeff Moss, Subcommittee Chair, DEF CON Communications
Mr. Dino Dai Zovi, Security Researcher
Mr. Luiz Eduardo, Aruba Threat Labs
Mr. Isiah Jones, National Resilience Inc.
Mr. Kurt Opsahl, Electronic Frontier Foundation
Ms. Runa Sandvik, Security Researcher
Mr. Yan Shoshitaishvili, Arizona State University
Ms. Rachel Tobac, SocialProof Security
Mr. David Weston, Microsoft
Mr. Bill Woodcock, Packet Clearing House
Ms. Yan Zhu, Brave SoftwareI see nothing new or useful here, what am I missing?
"The Securing Open Source Software Act would direct CISA to develop a risk framework to evaluate how open source code is used by the federal government. CISA would also evaluate how the same framework could be voluntarily used by critical infrastructure owners and operators. This will identify ways to mitigate risks in systems that use open source software. 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. Additionally, the legislation requires the Office of Management and Budget (OMB) to issue guidance to federal agencies on the secure usage of open source software and establishes a software security subcommittee on the CISA Cybersecurity Advisory Committee."
[1] https://insights.sei.cmu.edu/blog/taking-up-the-challenge-of...
Looks to me like it will wind up making more money available for developers, mainly outside government, to audit and improve important free software that the feds are currently using. Unfortunately because of the way that government contracts work, companies that are already experienced at doing government contracts might wind up with the bulk of the money. But it isn't going to make things worse and might actually make things better.
The reason log4shell had such a big impact is because of how ubiquitous it was. Sure being free gives OSS a bit of an advantage in becoming ubiquitous, especially as a library.
But there's also plenty of proprietary software that is ubiquitous as well. And proprietary software has plenty of bad security bugs too.
> FWIW, while this specific act may not be enforcing significant regulation, software developers need to understand that there's a ticking clock.
There are several initiatives from LF's OpenSSF and startup Chainguard.
Sept 2022, "Concise Guide for Evaluating Open-Source Software", https://github.com/ossf/wg-best-practices-os-developers/blob...
Sept 2022, "Show off your Security Score: Announcing Scorecards Badges", https://openssf.org/blog/2022/09/08/show-off-your-security-s...
Apparently they never changed one character in a query string in the late-90s.
>“This important legislation will, for the first time ever, codify open source software as public infrastructure,” said Trey Herr
Open source software is no more "public infrastructure" than the efforts of volunteer organizations. The government should have no say over this matter IMO.
The gov has a large culture of tapping integrators who do not give back to OSS, just use, basically the middle man, and leave behind fragile one-offs. Such abandonware should overwhelm recieving depts within 6-12mo, and bringing back integrators for the treadmill of patching superfluous npm CVEs would break their budgets.
So that means pressure to, well, not do that. Either the integrators get more involved, or part of the budgets finally goes to people who are.
TFA has no bill number so lets see if we can find it. Actually no, I'm not seeing it. Someone send me an HR? I'll update my comment if you do.
I believe that most of the assessment stuff is covered by many NIST recommendations anyways.