Live data from Hacker News

'Securing Open Source Software Act' introduced to US Senate

hsgac.senate.gov

141–150 of 187 posts

Re: 'Securing Open Source Software Act' introduced to US Senate

#141
post #136

LF 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…

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.

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

Re: 'Securing Open Source Software Act' introduced to US Senate

#142

Earlier quoted context omitted.

It’s “the same” in a really broad hand-wavy sort of way. It’s not the same practically speaking. FOSS usually does not have warrantees, SLAs, or developers in particular locations with particular credentials. The government has processes that they must follow for paying contractors, so “just pay them” is not something that can easily be done last minute, (and sometimes, not at all without a literal act of Congress.)…

You seem to be reading me as implying any use of FOSS is equivalent to having a support contract; it's not. I was claiming that having a support contract for FOSS is equivalent to having a support contract for proprietary software. If you need "support contract" level support you should probably be paying for a support contract. At least with FOSS that can be competitive for the same piece of software (although that…

I said the issues are different and you disagreed, so I detailed what I meant.

It’s also not reasonable to require the government to just get 10,000 support contracts just to implement a single application.

What makes the most sense is what they’re doing here:

1. come up with a strategy for managing these risks

2. Collectively work with OSS developers instead of treating every one of the governments 10 bazillion projects like it needs a separate support contract for a component that is shared

Re: 'Securing Open Source Software Act' introduced to US Senate

#143
post #95

Earlier quoted context omitted.

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 gove…

FIPS validation does not have a self certify path

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

Re: 'Securing Open Source Software Act' introduced to US Senate

#144

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 legislatio…

This will result in "we can't use open source because the boss doesn't want to deal with the paperwork. We'll get John from X massive company on the phone and license their version."

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.

Re: 'Securing Open Source Software Act' introduced to US Senate

#145
post #136

Earlier quoted context omitted.

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.

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

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

Re: 'Securing Open Source Software Act' introduced to US Senate

#147
post #97

Earlier quoted context omitted.

You ditched all java over a single bug? That seems extreme..... Did you ditch ssl over heartbleed?

Did they ditch CPUs after spectre?

Finally! I can go outside! : ' )

Re: 'Securing Open Source Software Act' introduced to US Senate

#148
post #74

Earlier quoted context omitted.

If they were really trying to secure the code, shouldn't the bill be called the "Securing Software Act"? It's not like closed source software is magically immune to vulnerabilities

This isn't about fixing anyone's code, it's about securing the software stack that the government is running. They already have well developed processes for addressing closed source software.

Can you provide a reference to the processes you are referring to? I'm only familiar with EAL and FIPS which require theories that there is maintenance where they apply in the lower part of the stack. They are applied to open source like OpenSSL and SeLinux, probably with better quality than a lot of niche closed source government procures.

Re: 'Securing Open Source Software Act' introduced to US Senate

#149
post #60

Earlier quoted context omitted.

Do you demand that every screwmaker make aircraft-grade screws? Aircraft makers need screws and it would be very convenient to them to be able to go down to any hardware store and just buy whatever screw they want since they are all up to spec. No need to evaluate their suppliers since everybody is required to make things up to their demanding standards. The problem with this is that not everybody needs expensive air…

I'm quite sure that screws are indeed something that, if made in a shoddy way, would have legal repercussions for those producing them. That's the norm - it's software that's weird for not having that. I would actually expect screws are even rated for specific work. Also, people sell screws, so the analogy really makes no sense. I'm not suggesting that software developers be required to do anything if they're just wr…

no.

Re: 'Securing Open Source Software Act' introduced to US Senate

#150

Earlier 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 in inherently risky."

The problem is that they don't need to do this. In the open source community we're doing a great job all by ourselves. I've written open source libraries and platforms, I've also written proprietary software that uses open source. Log4j, Heartbleed, half of NPM etc weren't the work of Oracle lobbyists, they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained.

I'd actually go further and say you overestimate the power of lobbying and underestimate the possibility of lobbyist's having a point. The primary argument these firms made against relying on OSS was that it's often just a bunch of random people with no incentive to do the un-fun work like security audits or patch backports. There's nobody who takes responsibility for things. That's true and is pretty much the core of Red Hat's business model so it's not like anyone can really dispute this.

The software industry does need new approaches to how we use open source stuff, IMO. Sandboxing of libraries would go a long way. But we can't just pretend there's no problem here and it's all the work of shadowy corporations, it's naive ideological stuff.

Post reply on HN