14 ms·

'Securing Open Source Software Act' introduced to US Senate

243 points by di 4y ago

yazzku 4y ago
So will they help fund the projects now, or will they just express their opinions on how your unpaid work should be done?
- rtev 4y ago
  That’s really the question, isn’t it? The article makes it sound like hiring “open source devs” may be part of the strategy, which essentially amounts to anyone with a public GitHub repo.
  - adastra22 4y ago
    No the people hired will be IBM consultants and such with long lists of meaningless qualifications and no GitHub profile.
    - verisimilitudes 4y ago
      No the people hired will be IBM consultants and such with long lists of meaningless qualifications and no MicroSoft profile.
      - adastra22 4y ago
        Oh no, they’ll have all the Microsoft certifications too.
- Schroedingersat 4y ago
  Don't worry about it. It's just code for 'government departments only get to use software from giant corps with well known and unpatched bugs now'.
- RobotToaster 4y ago
  Do licenses like the GPL even apply to TLA like the NSA and CIA? Or could they just make patches for themselves and not release them?
  - Rebelgecko 4y ago
    Anyone can make open source code changes and be license compliant as long as you don't release the binary (YMMV depending on specific license). However as soon as you give someone binaries they're entitled to request the source. I'd love to see a future with goofy situations like Iran suing for the stuxnet source code because it statically linked a GPL library.
    - xxpor 4y ago
      where it gets really goofy is the US gov work doesn't have copyright itself, so wouldn't any work done by them be PD, regardless of the underlying license?
      - not2b 4y ago
        If they extend an existing GPL work, the work as a whole is GPL, even if their added code is PD.
      - kmeisthax 4y ago
        My gut feeling is no, because the work is still a derivative work of a privately-owned copyrighted work, and private copyright does not dissolve when the government touches it. If you could separate the governments' code from the GPL code, then it would be automatically public domain, but the combination is still GPL. However I'm not aware of any case law proving this.
    - SllX 4y ago
      My first instinct is that sovereign immunity applies. GPL is a license designed to protect the copyrights of the creator or copyright owner, but copyright itself is a privilege granted by the Federal government and protected by law. So if you sued them for violating the GPL, I’m fairly certain they could just claim sovereign immunity in court.
- 9wzYQbTYsAIc 4y ago
  There is this little nugget: “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.”
  - encryptluks2 4y ago
    Unless it specifies who this just means they'll throw a few billion to Teksystems, CGI or whoever and then say that it was a failure like HealthCare.gov
    - deleted 4y ago
      [deleted]
    - tomrod 4y ago
      That spawned a lot of good things. Check out 18F and USDS.
      - encryptluks2 4y ago
        There are special exceptions, but definitely not the norm.
        tomrod 4y ago
        Except for the change in acquisition and contracting behind the scenes that was driven by that colossal failure. Have you noticed that the IRS website is accessible and searchable? That SBA is functional? Conpare that to, say, Department of Commerce, where things are a mess (currently). The US realized it needed to pick things up a bit and, while it's still a hard space to work in, started to shift to a better playbook. https://playbook.cio.gov/ https://playbook.cio.gov/
- NaturalPhallacy 4y ago
  Without the text of the bill should show up here eventually: https://www.congress.gov/bill/117th-congress/senate-bill/4913/titles https://www.congress.gov/bill/117th-congress/senate-bill/491... There's no way to actually know. Everything not based on the text of the bill is pure speculation.
buscoquadnary 4y ago
For those curious about what it actually is: > 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.
- RobotToaster 4y ago
  It sounds innocuous enough, but could the real motivation be to make open source software so expensive to use that all government agencies "choose" to use closed source software? (This is a genuine question, I'm honestly not sure what the consequences, intended or otherwise, could be?)
  - thomaslangston 4y ago
    Nah. You'd just need to use the old versions that had gone through a security audit and had some enterprise level Long Term Support contracts available. IBM will offer quotes for whatever is required within 2 quarters or less.
- sullivanmatt 4y ago
  Not a complete nothing burger; a lot of people here work for companies that sell to the Feds or host FedRAMP-authorized SaaS solutions. There will definitely be private-sector impact from that risk framework, though I'm not saying that's necessarily a good or a bad thing.
ananonymoususer 4y ago
Seems like they are taking the right approach. Instead of trying to regulate OSS, they're funding CISA to help make it more secure.
- beambot 4y ago
  What will the CISA actually do?
  - encryptluks2 4y ago
    Lol.. they'll pay contractors from big companies to come in and tell them why they shouldn't use open source.
  - mistrial9 4y ago
    get funded
  - NaturalPhallacy 4y ago
    It turns taxpayer money into individually owned Teslas. Joking aside, they do actually have a github: https://github.com/cisagov https://github.com/cisagov
staticassertion 4y ago
FWIW, while this specific act may not be enforcing significant regulation, software developers need to understand that there's a ticking clock. Modern civic engineers went without any significant regulation, and then that changed. Software is young, it's in the phase where people aren't dying too often for the public to care. But breaches are leading to massive privacy problems, real wars and conflicts are increasingly leveraging software defects, and the impact and scrutiny will only grow. 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
- yjftsjthsd-h 4y ago
  I'm going to disagree, I think. The problem isn't on the push side, it's on the pull side. People throwing random-quality code in github is fine. People deciding to amalgamate that into distributions and publish it is fine. 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, and that is the problem. NO WARRANTY is partially about legal issues, but not exclusively - if people share their code for free, they don't owe anyone anything. If you don't like that, you're free to offer them enough money to actually accept your standards.
smm11 4y ago
"This led top cybersecurity experts to call it one of the most severe and widespread cybersecurity vulnerabilities ever seen." Apparently they never changed one character in a query string in the late-90s.
mkl95 4y ago
Why 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.
- deleted 4y ago
  [deleted]
- kube-system 4y ago
  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 thing works?" So yeah, it makes sense to treat them differently, at least in some respects.
  - PaulDavisThe1st 4y ago
    For the sorts of purposes described in bill-blurb, the questions would be essentially identical.
    - kube-system 4y ago
      Not really. The managerial process for fixing a vulnerability or mitigating supply chain attacks in an open source project is functionally different than for a proprietary product. So much so that it’s often the subject of memes (and frustration) in the FOSS community when people don’t understand the difference. Stuff like this: https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/ https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/ Or this: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquiry-response-required/ https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir... … is exactly why you can’t treat them the same in these types of situations.
peteforde 4y ago
Reading 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" 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.
- kube-system 4y ago
  They're trying to destroy FOSS ...by hiring FOSS developers? 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.
  - throwbigdata 4y ago
    More or less of a big issue than the revolving door of Microsoft bugs?
    - kube-system 4y ago
      Different types of issues with different solutions. When you have a support contract with the original developer of a piece of code, you can demand the original developer fix the code.
      - dllthomas 4y ago
torstenvl 4y ago
Text not available on Congress.gov yet, but keep your eyes on this space: https://www.congress.gov/bill/117th-congress/senate-bill/4913/text https://www.congress.gov/bill/117th-congress/senate-bill/491...
not2b 4y ago
It seems most commenters want to interpret this as a threat, or as a way to discourage use of FOSS by government. I don't think it is either one. The US government isn't a monolith, it's thousands of semi-independent fiefdoms all doing different things, and some know what they are doing and others have horrible security practices. This seems to be one of several efforts to fix that. 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.
transpute 4y ago
https://news.ycombinator.com/item?id=32956218#32957137 https://news.ycombinator.com/item?id=32956218#32957137 > 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/main/docs/Concise-Guide-for-Evaluating-Open-Source-Software.md#readme 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-score-announcing-scorecards-badges/ https://openssf.org/blog/2022/09/08/show-off-your-security-s...
danbmil99 4y ago
This is not a push for proprietary software. It's a prelude to regulatory capture where a bunch of highly paid consultants will need to bless your open source solution for big money. 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.
- transpute 4y ago
  Maybe, if electrical contracting used blockchains like sigstore, https://www.sigstore.dev/ https://www.sigstore.dev/ from OpenSSF, https://openssf.org https://openssf.org.
- jeffbee 4y ago
  We already have this. You hire some idiot to sign off on your FIPS-140. They are getting paid under the table by IBM. They swear that the only way to comply with FIPS-140 is to use RHEL. The only company I ever worked at that hasn't fallen for this scam is Google, who self-certify everything including their crypto stack. But every other smaller company (i.e. all other companies) are just terrified of not getting government contracts and are in thrall to these consultants.
  - grosswait 4y ago
    FIPS validation does not have a self certify path
    - transpute 4y ago
      > Google, who self-certify everything including their crypto stack. This probably means paying for an independent lab's FIPS validation of Google's crypto stack, rather than using one from RHEL (where RH/IBM paid for the FIPS validation).
yawnxyz 4y ago
Why 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?
transpute 4y ago
DHS (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%202022%20CSAC%20Recommendations%20–%20TAC.pdf 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 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 Software
- mistrial9 4y ago
  one of those is a political liberal turned spy-for-hire .. this does not look like a list of Fortune 500 shills from here
jrsj 4y ago
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.
transpute 4y ago
LF OpenSSF "criticality score" for 100K Github repos, https://github.com/ossf/criticality_score https://github.com/ossf/criticality_score & https://docs.google.com/spreadsheets/d/1uahUIUa82J6WetAqtxCM_qgH-YJOagH84AFniIhlAbg/edit 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
- Tomte 4y ago
  Oh fun! At my employer the "security team" misunderstands that criticality score and takes it as a "vulnerability score". Everything scoring high is a security risk, everything scoring low is secure.
  - transpute 4y ago
    OMG :) OpenSSF will love that story! Straight into the documentation Hall of Fame. They can check out the Securing Critical Projects working group, https://github.com/ossf/wg-securing-critical-projects https://github.com/ossf/wg-securing-critical-projects
    - Tomte 4y ago
      They link to that page in their documentation. I can only assume that they misunderstand this: > 1. Identify critical open source software (OSS) projects. > 2. Secure those projects. Not as "those projects are widely in use, we should really make sure that they are looked at", but as "we have identified those projects as insecure and will secure them".
bob1029 4y ago
We do B2B software in banking and this is something we've been anticipating for quite some time now. We were implicated in that log4j exploit via a (very) transitive, cross-language dependency. 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.
- malfist 4y ago
  You ditched all java over a single bug? That seems extreme..... Did you ditch ssl over heartbleed?
  - richbell 4y ago
    > You ditched all java over a single bug? A bug in a third-party dependency, no less.
  - bob1029 4y ago
    At the time, Java accounted for <1% of our codebase/product, so it made sense to do so.
  - javajosh 4y ago
    Did they ditch CPUs after spectre?
    - wilsonjholmes 4y ago
      Finally! I can go outside! : ' )
stevenalowe 4y ago
5 paragraphs of Silver Bullet Magical Thinking nonsense to get to the actual bill, which is basically calling for a study and recommended guidelines for OSS security - of which there are several already, including one from the DoD [1]. I 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-open-source-software-security-in-the-dod/ https://insights.sei.cmu.edu/blog/taking-up-the-challenge-of...
swiley-gin 4y ago
Well I've just had the weekly "why can't you come here" call with my forign gf, failed to deliver on the couple tickets I have open at work, and posted my daily "barf into ~/stuff/*.c" to /prog/ so lets go through and read this instead of going and being with people. 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.
jrochkind1 4y ago
"securing open source software act" would rationally mean funding the NSA or similar experts to help harden open source software, right? Or, hey, telling the NSA to disclose vulnerabilities they find in open source software so they can be patched, instead of sitting on them hoping nobody else notices. Right? No? Wait, what? It's just about telling the federal government to use less open source software? How does that make open source software more secure?
- transpute 4y ago
  A good move would be increasing funding for defensive security teams at NSA, especially those working on open-source software, and restoring the separation of governance/leadership between defensive and offensive security teams.
- kube-system 4y ago
  You're just attacking the title. The description doesn't demonize OSS at all, it praises it. 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'"
  - jrochkind1 4y ago
    Right, but it's focused on helping the government decide what open source not to use, rather than on actually making open source more secure.
    - kube-system 4y ago
      The risk framework isn’t written yet, this just directs CISA to write one. While evaluating dependencies is often a part of what you’d do in a risk framework, it’s typically just one part.
- frozencell 4y ago
pGuitar 4y ago
Any laws regulating OSS is potentially a big problem... why is it even needed? Reminds me of the "PATRIOT" Act authored by Joe Biden in 1994.
thayne 4y ago
Why the focus on open source? 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.
lmeyerov 4y ago
There's a funny bite here that seems long-term good. 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.
eyelidlessness 4y ago
So… I’m reading this from the perspective of working 100% professionally on open source software and I don’t understand at all what implications this has for my work being declared public infrastructure. I don’t think it’s being funded, which I guess isn’t surprising because not funding infrastructure is literally a meme which has been going for years. I don’t think anything is being offered to help secure the software I work on. It kind of reads like a vague threat? I don’t mean to be glib at all, but if you’re declaring something public infrastructure and you’re ostensibly a public servant, maybe making me feel scared of you isn’t a great look?
mffap 4y ago
a radical thought: how about hiring some engineers to contribute to oss that's being used in critical infrastructure? I believe that most of the assessment stuff is covered by many NIST recommendations anyways.
Meph504 4y ago
I won't get into the reason behind this, but I will say I found this statement horrible, and could not disagree more. >“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.

243 points by di 4y ago

So will they help fund the projects now, or will they just express their opinions on how your unpaid work should be done?

rtev 4y ago
That’s really the question, isn’t it? The article makes it sound like hiring “open source devs” may be part of the strategy, which essentially amounts to anyone with a public GitHub repo.
- adastra22 4y ago
  No the people hired will be IBM consultants and such with long lists of meaningless qualifications and no GitHub profile.
  - verisimilitudes 4y ago
    No the people hired will be IBM consultants and such with long lists of meaningless qualifications and no MicroSoft profile.
    - adastra22 4y ago
      Oh no, they’ll have all the Microsoft certifications too.
Schroedingersat 4y ago
Don't worry about it. It's just code for 'government departments only get to use software from giant corps with well known and unpatched bugs now'.
RobotToaster 4y ago
Do licenses like the GPL even apply to TLA like the NSA and CIA? Or could they just make patches for themselves and not release them?
- Rebelgecko 4y ago
  Anyone can make open source code changes and be license compliant as long as you don't release the binary (YMMV depending on specific license). However as soon as you give someone binaries they're entitled to request the source. I'd love to see a future with goofy situations like Iran suing for the stuxnet source code because it statically linked a GPL library.
  - xxpor 4y ago
    where it gets really goofy is the US gov work doesn't have copyright itself, so wouldn't any work done by them be PD, regardless of the underlying license?
    - not2b 4y ago
      If they extend an existing GPL work, the work as a whole is GPL, even if their added code is PD.
    - kmeisthax 4y ago
      My gut feeling is no, because the work is still a derivative work of a privately-owned copyrighted work, and private copyright does not dissolve when the government touches it. If you could separate the governments' code from the GPL code, then it would be automatically public domain, but the combination is still GPL. However I'm not aware of any case law proving this.
  - SllX 4y ago
    My first instinct is that sovereign immunity applies. GPL is a license designed to protect the copyrights of the creator or copyright owner, but copyright itself is a privilege granted by the Federal government and protected by law. So if you sued them for violating the GPL, I’m fairly certain they could just claim sovereign immunity in court.
9wzYQbTYsAIc 4y ago
There is this little nugget: “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.”
- encryptluks2 4y ago
  Unless it specifies who this just means they'll throw a few billion to Teksystems, CGI or whoever and then say that it was a failure like HealthCare.gov
  - deleted 4y ago
    [deleted]
  - tomrod 4y ago
    That spawned a lot of good things. Check out 18F and USDS.
    - encryptluks2 4y ago
      There are special exceptions, but definitely not the norm.
      - tomrod 4y ago
        Except for the change in acquisition and contracting behind the scenes that was driven by that colossal failure. Have you noticed that the IRS website is accessible and searchable? That SBA is functional? Conpare that to, say, Department of Commerce, where things are a mess (currently). The US realized it needed to pick things up a bit and, while it's still a hard space to work in, started to shift to a better playbook. https://playbook.cio.gov/ https://playbook.cio.gov/
NaturalPhallacy 4y ago
Without the text of the bill should show up here eventually: https://www.congress.gov/bill/117th-congress/senate-bill/4913/titles https://www.congress.gov/bill/117th-congress/senate-bill/491... There's no way to actually know. Everything not based on the text of the bill is pure speculation.

buscoquadnary 4y ago

For those curious about what it actually is: > 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.

RobotToaster 4y ago
It sounds innocuous enough, but could the real motivation be to make open source software so expensive to use that all government agencies "choose" to use closed source software? (This is a genuine question, I'm honestly not sure what the consequences, intended or otherwise, could be?)
- thomaslangston 4y ago
  Nah. You'd just need to use the old versions that had gone through a security audit and had some enterprise level Long Term Support contracts available. IBM will offer quotes for whatever is required within 2 quarters or less.
sullivanmatt 4y ago
Not a complete nothing burger; a lot of people here work for companies that sell to the Feds or host FedRAMP-authorized SaaS solutions. There will definitely be private-sector impact from that risk framework, though I'm not saying that's necessarily a good or a bad thing.

ananonymoususer 4y ago

Seems like they are taking the right approach. Instead of trying to regulate OSS, they're funding CISA to help make it more secure.

beambot 4y ago
What will the CISA actually do?
- encryptluks2 4y ago
  Lol.. they'll pay contractors from big companies to come in and tell them why they shouldn't use open source.
- mistrial9 4y ago
  get funded
- NaturalPhallacy 4y ago
  It turns taxpayer money into individually owned Teslas. Joking aside, they do actually have a github: https://github.com/cisagov https://github.com/cisagov

staticassertion 4y ago

FWIW, while this specific act may not be enforcing significant regulation, software developers need to understand that there's a ticking clock. Modern civic engineers went without any significant regulation, and then that changed. Software is young, it's in the phase where people aren't dying too often for the public to care. But breaches are leading to massive privacy problems, real wars and conflicts are increasingly leveraging software defects, and the impact and scrutiny will only grow. 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

yjftsjthsd-h 4y ago
I'm going to disagree, I think. The problem isn't on the push side, it's on the pull side. People throwing random-quality code in github is fine. People deciding to amalgamate that into distributions and publish it is fine. 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, and that is the problem. NO WARRANTY is partially about legal issues, but not exclusively - if people share their code for free, they don't owe anyone anything. If you don't like that, you're free to offer them enough money to actually accept your standards.

smm11 4y ago

"This led top cybersecurity experts to call it one of the most severe and widespread cybersecurity vulnerabilities ever seen." Apparently they never changed one character in a query string in the late-90s.

mkl95 4y ago

Why 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.

deleted 4y ago
[deleted]
kube-system 4y ago
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 thing works?" So yeah, it makes sense to treat them differently, at least in some respects.
- PaulDavisThe1st 4y ago
  For the sorts of purposes described in bill-blurb, the questions would be essentially identical.
  - kube-system 4y ago
    Not really. The managerial process for fixing a vulnerability or mitigating supply chain attacks in an open source project is functionally different than for a proprietary product. So much so that it’s often the subject of memes (and frustration) in the FOSS community when people don’t understand the difference. Stuff like this: https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/ https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/ Or this: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquiry-response-required/ https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir... … is exactly why you can’t treat them the same in these types of situations.

peteforde 4y ago

Reading 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" 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.

kube-system 4y ago
They're trying to destroy FOSS ...by hiring FOSS developers? 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.
- throwbigdata 4y ago
  More or less of a big issue than the revolving door of Microsoft bugs?
  - kube-system 4y ago
    Different types of issues with different solutions. When you have a support contract with the original developer of a piece of code, you can demand the original developer fix the code.
    - dllthomas 4y ago

torstenvl 4y ago

Text not available on Congress.gov yet, but keep your eyes on this space: https://www.congress.gov/bill/117th-congress/senate-bill/4913/text https://www.congress.gov/bill/117th-congress/senate-bill/491...

not2b 4y ago

It seems most commenters want to interpret this as a threat, or as a way to discourage use of FOSS by government. I don't think it is either one. The US government isn't a monolith, it's thousands of semi-independent fiefdoms all doing different things, and some know what they are doing and others have horrible security practices. This seems to be one of several efforts to fix that. 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.

transpute 4y ago

https://news.ycombinator.com/item?id=32956218#32957137 https://news.ycombinator.com/item?id=32956218#32957137 > 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/main/docs/Concise-Guide-for-Evaluating-Open-Source-Software.md#readme 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-score-announcing-scorecards-badges/ https://openssf.org/blog/2022/09/08/show-off-your-security-s...

danbmil99 4y ago

This is not a push for proprietary software. It's a prelude to regulatory capture where a bunch of highly paid consultants will need to bless your open source solution for big money. 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.

transpute 4y ago
Maybe, if electrical contracting used blockchains like sigstore, https://www.sigstore.dev/ https://www.sigstore.dev/ from OpenSSF, https://openssf.org https://openssf.org.
jeffbee 4y ago
We already have this. You hire some idiot to sign off on your FIPS-140. They are getting paid under the table by IBM. They swear that the only way to comply with FIPS-140 is to use RHEL. The only company I ever worked at that hasn't fallen for this scam is Google, who self-certify everything including their crypto stack. But every other smaller company (i.e. all other companies) are just terrified of not getting government contracts and are in thrall to these consultants.
- grosswait 4y ago
  FIPS validation does not have a self certify path
  - transpute 4y ago
    > Google, who self-certify everything including their crypto stack. This probably means paying for an independent lab's FIPS validation of Google's crypto stack, rather than using one from RHEL (where RH/IBM paid for the FIPS validation).

yawnxyz 4y ago

Why 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?

transpute 4y ago

DHS (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%202022%20CSAC%20Recommendations%20–%20TAC.pdf 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 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 Software

mistrial9 4y ago
one of those is a political liberal turned spy-for-hire .. this does not look like a list of Fortune 500 shills from here

jrsj 4y ago

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.

transpute 4y ago

LF OpenSSF "criticality score" for 100K Github repos, https://github.com/ossf/criticality_score https://github.com/ossf/criticality_score & https://docs.google.com/spreadsheets/d/1uahUIUa82J6WetAqtxCM_qgH-YJOagH84AFniIhlAbg/edit 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

Tomte 4y ago
Oh fun! At my employer the "security team" misunderstands that criticality score and takes it as a "vulnerability score". Everything scoring high is a security risk, everything scoring low is secure.
- transpute 4y ago
  OMG :) OpenSSF will love that story! Straight into the documentation Hall of Fame. They can check out the Securing Critical Projects working group, https://github.com/ossf/wg-securing-critical-projects https://github.com/ossf/wg-securing-critical-projects
  - Tomte 4y ago
    They link to that page in their documentation. I can only assume that they misunderstand this: > 1. Identify critical open source software (OSS) projects. > 2. Secure those projects. Not as "those projects are widely in use, we should really make sure that they are looked at", but as "we have identified those projects as insecure and will secure them".

bob1029 4y ago

We do B2B software in banking and this is something we've been anticipating for quite some time now. We were implicated in that log4j exploit via a (very) transitive, cross-language dependency. 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.

malfist 4y ago
You ditched all java over a single bug? That seems extreme..... Did you ditch ssl over heartbleed?
- richbell 4y ago
  > You ditched all java over a single bug? A bug in a third-party dependency, no less.
- bob1029 4y ago
  At the time, Java accounted for <1% of our codebase/product, so it made sense to do so.
- javajosh 4y ago
  Did they ditch CPUs after spectre?
  - wilsonjholmes 4y ago
    Finally! I can go outside! : ' )

stevenalowe 4y ago

5 paragraphs of Silver Bullet Magical Thinking nonsense to get to the actual bill, which is basically calling for a study and recommended guidelines for OSS security - of which there are several already, including one from the DoD [1]. I 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-open-source-software-security-in-the-dod/ https://insights.sei.cmu.edu/blog/taking-up-the-challenge-of...

swiley-gin 4y ago

Well I've just had the weekly "why can't you come here" call with my forign gf, failed to deliver on the couple tickets I have open at work, and posted my daily "barf into ~/stuff/*.c" to /prog/ so lets go through and read this instead of going and being with people. 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.

jrochkind1 4y ago

"securing open source software act" would rationally mean funding the NSA or similar experts to help harden open source software, right? Or, hey, telling the NSA to disclose vulnerabilities they find in open source software so they can be patched, instead of sitting on them hoping nobody else notices. Right? No? Wait, what? It's just about telling the federal government to use less open source software? How does that make open source software more secure?

transpute 4y ago
A good move would be increasing funding for defensive security teams at NSA, especially those working on open-source software, and restoring the separation of governance/leadership between defensive and offensive security teams.
kube-system 4y ago
You're just attacking the title. The description doesn't demonize OSS at all, it praises it. 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'"
- jrochkind1 4y ago
  Right, but it's focused on helping the government decide what open source not to use, rather than on actually making open source more secure.
  - kube-system 4y ago
    The risk framework isn’t written yet, this just directs CISA to write one. While evaluating dependencies is often a part of what you’d do in a risk framework, it’s typically just one part.
frozencell 4y ago

pGuitar 4y ago

Any laws regulating OSS is potentially a big problem... why is it even needed? Reminds me of the "PATRIOT" Act authored by Joe Biden in 1994.

thayne 4y ago

Why the focus on open source? 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.

lmeyerov 4y ago

There's a funny bite here that seems long-term good. 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.

eyelidlessness 4y ago

So… I’m reading this from the perspective of working 100% professionally on open source software and I don’t understand at all what implications this has for my work being declared public infrastructure. I don’t think it’s being funded, which I guess isn’t surprising because not funding infrastructure is literally a meme which has been going for years. I don’t think anything is being offered to help secure the software I work on. It kind of reads like a vague threat? I don’t mean to be glib at all, but if you’re declaring something public infrastructure and you’re ostensibly a public servant, maybe making me feel scared of you isn’t a great look?

mffap 4y ago

a radical thought: how about hiring some engineers to contribute to oss that's being used in critical infrastructure? I believe that most of the assessment stuff is covered by many NIST recommendations anyways.

Meph504 4y ago

I won't get into the reason behind this, but I will say I found this statement horrible, and could not disagree more. >“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.