Rust, Python, Apache Foundations and Others Announce Big Collaboration on Cybersecurity Process Specifications (eclipse-foundation.blog) 42
The foundations behind Rust, Python, Apache, Eclipse, PHP, OpenSSL, and Blender announced plans to create "common specifications for secure software development," based on "existing open source best practices."
From the Eclipse Foundation: This collaborative effort will be hosted at the Brussels-based Eclipse Foundation [an international non-profit association] under the auspices of the Eclipse Foundation Specification Process and a new working group... Other code-hosting open source foundations, SMEs, industry players, and researchers are invited to join in as well.
The starting point for this highly technical standardisation effort will be today's existing security policies and procedures of the respective open source foundations, and similar documents describing best practices.
The governance of the working group will follow the Eclipse Foundation's usual member-led model but will be augmented by explicit representation from the open source community to ensure diversity and balance in decision-making. The deliverables will consist of one or more process specifications made available under a liberal specification copyright licence and a royalty-free patent licence... While open source communities and foundations generally adhere to and have historically established industry best practices around security, their approaches often lack alignment and comprehensive documentation.
The open source community and the broader software industry now share a common challenge: legislation has introduced an urgent need for cybersecurity process standards.
The Apache Foundation notes the working group is forming partly "to demonstrate our commitment to cooperation with and implementation of" the EU's Cyber Resilience Act. But the Eclipse Foundation adds that even before it goes into effect in 2027, they're recognizing open source software's "increasingly vital role in modern society" and an increasing need for reliability, safety, and security, so new regulations like the CRA "underscore the urgency for secure by design and robust supply chain security standards."
Their announcement adds that "It is also important to note that it is similarly necessary that these standards be developed in a manner that also includes the requirements of proprietary software development, large enterprises, vertical industries, and small and medium enterprises." But at the same time, "Today's global software infrastructure is over 80% open source... [W]hen we discuss the 'software supply chain,' we are primarily, but not exclusively, referring to open source."
"We invite you to join our collaborative effort to create specifications for secure open source development," their announcement concludes," promising initiative updates on a new mailing list. "Contribute your ideas and participate in the magic that unfolds when open source foundations, SMEs, industry leaders, and researchers combine forces to tackle big challenges."
The Python Foundation's announcement calls it a "community-driven initiative" that will have "a lasting impact on the future of cybersecurity and our shared open source communities."
From the Eclipse Foundation: This collaborative effort will be hosted at the Brussels-based Eclipse Foundation [an international non-profit association] under the auspices of the Eclipse Foundation Specification Process and a new working group... Other code-hosting open source foundations, SMEs, industry players, and researchers are invited to join in as well.
The starting point for this highly technical standardisation effort will be today's existing security policies and procedures of the respective open source foundations, and similar documents describing best practices.
The governance of the working group will follow the Eclipse Foundation's usual member-led model but will be augmented by explicit representation from the open source community to ensure diversity and balance in decision-making. The deliverables will consist of one or more process specifications made available under a liberal specification copyright licence and a royalty-free patent licence... While open source communities and foundations generally adhere to and have historically established industry best practices around security, their approaches often lack alignment and comprehensive documentation.
The open source community and the broader software industry now share a common challenge: legislation has introduced an urgent need for cybersecurity process standards.
The Apache Foundation notes the working group is forming partly "to demonstrate our commitment to cooperation with and implementation of" the EU's Cyber Resilience Act. But the Eclipse Foundation adds that even before it goes into effect in 2027, they're recognizing open source software's "increasingly vital role in modern society" and an increasing need for reliability, safety, and security, so new regulations like the CRA "underscore the urgency for secure by design and robust supply chain security standards."
Their announcement adds that "It is also important to note that it is similarly necessary that these standards be developed in a manner that also includes the requirements of proprietary software development, large enterprises, vertical industries, and small and medium enterprises." But at the same time, "Today's global software infrastructure is over 80% open source... [W]hen we discuss the 'software supply chain,' we are primarily, but not exclusively, referring to open source."
"We invite you to join our collaborative effort to create specifications for secure open source development," their announcement concludes," promising initiative updates on a new mailing list. "Contribute your ideas and participate in the magic that unfolds when open source foundations, SMEs, industry leaders, and researchers combine forces to tackle big challenges."
The Python Foundation's announcement calls it a "community-driven initiative" that will have "a lasting impact on the future of cybersecurity and our shared open source communities."
the Eclipse Foundation (Score:2)
Really?
Anyway its going to be cloudy here 8-(
Real reason for this (Score:3, Interesting)
The real reason is that the EU Cyber Resilience Act requires companies and open source project to 1) audit any source code they rely on or require packages / libraries they depend on to be audited and 2) provide timely update/security fixes for up to 10 years.
Consider Angular or React, two very widely used web frameworks. They have hundreds (thousands?) of packages of JavaScript source code and tools they depend on. Does anyone expect the Angular / React team to ever be able to audit the dependent package
Some background (Score:2)
I was 'volunteered' in the 2010s to be part of a team auditing every single piece of software and hardware used by large multinational company.
We discovered that there ware more than 600 applications, home grown/commercial, being used by the company with several hundred small commercial applications bought at the department level, outside of any IT procurement process, and put in place by business department staff/consultants without IT checks and balances.
There were in daily use dozens of applications with
Re: Some background (Score:3, Informative)
This whole thing sounds absolutely awful, what kind of business is this?
In my line of work having a bunch of IT people breathing down your neck is not very well received at all. Industrial controls requires a lot of software, often poorly written, buggy, and full of security problems, typically also requiring the controls Engineer to have admin on the machine (also the software is almost always exclusively Windows-based.)
In every business (as well as Universities) I've worked at there is a real tension betw
More detail (Score:1)
The CIO was in as a turnaround person to fix what the prior CIO failed to fix.
He had the company's executive leadership approval to drastically cut costs and complexity for IT, its software and hardware 'portfolio' (his word) and cut headcount.
It's common for company departments to purchase a much larger solution via a smaller purchase, below the threshold requiring a full business plan and IT SterCo (Steering Committee) approval. The department then purchases 'add-on' customization from the vendor over ti
Good luck with that (Score:3, Insightful)
The only thing that can make software secure is getting developers, designers and architects that understand software security and then giving them the time to do things right. No amount of "process" will help if you do not have these people or do not let them work. If, on the other hand, you have these people and let them do their thing, process is not needed and may even be harmful.
Some things cannot be solved with bureaucracy. For these things, actual insight can only be replaced with more actual insight.
The whole thing is a smokescreen, will provide fake security and is essentially a lie by misdirection.
Re:Good luck with that (Score:5, Insightful)
Your solution requires "better people" and, even less realistically, "better managers". That's not gonna happen.
Standard libraries, frameworks, and design patterns are a step in the right direction, and it is good that all of these organizations are working together.
Re:Good luck with that (Score:5, Informative)
Your solution requires "better people" and, even less realistically, "better managers". That's not gonna happen.
Standard libraries, frameworks, and design patterns are a step in the right direction, and it is good that all of these organizations are working together.
Submission to and imposition of endless regulatory process demands will be the death of open source.
Re:Good luck with that (Score:4)
Submission to and imposition of endless regulatory process demands will be the death of open source.
Yes. And it will not fix anything a tiny bit more complicated. You cannot create insight bu regulation. Well, you could regulate that anybody working on software actually needs to be qualified for their work, but the IT field is _really_ not ready for that. FOSS would survive though.
Re: (Score:2)
Submission to and imposition of endless regulatory process demands will be the death of open source.
Did you RTFA? These are open source organizations working together on open source solutions.
Re: (Score:2)
These are people working on process specifications. Regulation, when it happens (and it will, the currently typical crapware is just causing wayyyy too much damage), will start from what these people do. As they will not address their own incompetence, that starting point will not be good.
Re: (Score:2)
Did you RTFA? These are open source organizations working together on open source solutions.
What I understood from following a couple of the links was this is just a collaboration to develop and document procedures.
While I don't think CRA is itself going to kill open source I believe similar regulatory regimes could very well have that effect. Once you have requirements that go down the typical security rabbit holes compliance becomes prohibitive amongst groups of randos scratching itches. I prefer open source not collaborate to help organizations check their boxes for them because this will onl
Re: (Score:2)
Other engineering disciplines have managed it. Other engineering disciplines also teach us that there is no alternative. Yes, projects may get delayed and less important projects may never get done. But doing them with unqualified people is _worse_.
All this stupidity does is delay IT reaching maturity even further, to the detriment of everybody. On the plus side, we already had a few near misses for really spectacular catastrophes (MS cloud master key 2023, for example, or the recent XZ attack). Continuing
Re: (Score:3)
Other engineering disciplines have managed it.
Other engineering disciplines don't do it with "better managers." They do it with standardized products and procedures, which is what the organizations listed in TFA are proposing we should do with security software.
When civil engineers are tasked with designing a bridge, they don't design it based on first principles from a physics textbook but from a CE handbook using standardized i-beams, standardized concrete mixtures, and standardized construction procedures.
Re: (Score:2, Interesting)
ProTip: To "manage something" also has the meaning of "to reach some goal". "Managers" do not need to be involved. I guess English is not your first language.
As to "standardized products and procedures", that is only part of the game and pretty irrelevant in some parts of some established engineering disciplines. What other engineering disciplines _require_ is that you are qualified to do your job and, more important, that you understand the limits of your qualification and DO NOT go beyond them. Design tha
Re: (Score:2)
Infact you have 3 senarios in your question.
1: the truck is below the weight limit, and explodes while on the bridge
2: the truck is below the weight limit, and does not explode on the bridge
3: the truck exceeds the weight limit ( do we need any more details here?)
In scenario 1 I guess that would depend on
Re: (Score:2)
Essentially it is really simple: Was the spec kept? If not -> engineer goes to prison unless they can prove it was an accident and no negligence was involved. That can happen. If yes -> engineer did their job right, no legal fallout for engineer. We need pretty much the same for software.
But some idiots (like this AC) just have to invent bogus scenarios and hallucinate bogus facts, because they cannot get over themselves and always _have_ to be right, no matter how stupid they sound.
Re: (Score:2)
ProTip: To "manage something" also has the meaning of "to reach some goal". "Managers" do not need to be involved. I guess English is not your first language.
I hope he manages to figure it out.
Re: (Score:2)
ProTip: To "manage something" also has the meaning of "to reach some goal". "Managers" do not need to be involved. I guess English is not your first language.
I hope he manages to figure it out.
Well, maybe he needs a manager to help him.
Re: Good luck with that (Score:1)
You only think that because you donâ(TM)t see into other branches of engineering. IT does actually do a lot better because there are many automated ways of checking your work. That is slowly changing as other branches are realizing they are just IT shops and also should âlearn to codeâ(TM) (things like file version management and diffs) but most of the government mandated process does not require good practice and thus is just a waste of time.
Re: (Score:2)
Your invalid AdHominem is just that: Invalid. IT does much, much worse. For example, in regular engineering, even simple negligence makes you liable. In IT, gross negligence (as observable in the daily news) does nothing.
Re: (Score:3)
Re: (Score:2)
Indeed. And that is the level we need go get IT to or it cannot be taken seriously as an engineering discipline.
Re: (Score:2)
Gross negligence is pursued by contract law. I have never seen a claim of gross negligence being pursued against an IT company on the basis of bad code, people make mistakes, that is not negligence, negligence is if you intentionally don't do the right thing and process doesn't help that, because there are ways to avoid process. What Boeing did is gross negligence and that is one the most regulated companies in the world.
Re: (Score:2)
Actually, you need to look up your definitions.
Intentionally not doing the right thing is called "intent" and often comes with personal criminal penalties.
Simple negligence is when somebody was careless and did not pay attention when they should have.
Gross negligence is when somebody grossly did not pay attention, but did not really intent the outcome. It is a massive level of carelessness, but still no intent. Somebody driving while drunk and then killing somebody is guilty if gross negligence for example.
Re: (Score:1)
Intent with regards to individual persons, perhaps not, but everything a company and government does is intentional. The fact you do not follow procedure leading to Boeing recent disastrous quality is a composition of intentional decisions to do or not to do certain things.
It is not intent on the part of the employee, they are just following the rules set forward, it is the fact that eg. all federal spending comes with the stipulation you must select the lowest bidder, which applies to employees as well. So
Re: (Score:2)
No idea why you try to defend Boeing. It is not working though because your "argument" is obviously bogus.
Re: (Score:3)
Re: (Score:1)
Yes, that's why IT companies have tools like git blame, I am involved in a number of large renovation projects right now, not a single engineering firm or architect (we're talking datacenter-level design here) has anything resembling git blame. At best you can ask the PM if he remembers who brought up the change, but if he quit and there is someone else in charge, all they have is who signed off on it, which is often not the culprit of the mistake that was made but just someone shoveling papers around.
I wis
Re: (Score:2)
Standard libraries, frameworks, and design patterns are a step in the right direction,
I don't know why you think that is what's happening.
Re: (Score:3)
Until you fix that nonsense going on in boardrooms and C-Suites around the world, all of these announcements and calls to action are
Resourcing (Score:3)
xz was a compression tool maintained by one guy in his spare time.
If you're wanting to include something as a core library in a major software release such as Fedora or Ubuntu, maybe remunerating the project admin and bringing essential software under an umbrella or foundation is the best course of action to ensure rogue actors don't hijack it.
Re: Resourcing (Score:1)
Re: (Score:2)
If you're wanting to include something as a core library in a major software release such as Fedora or Ubuntu, maybe remunerating the project admin and bringing essential software under an umbrella or foundation is the best course of action to ensure rogue actors don't hijack it.
Problem is, people don't like to do the "boring" parts of work, even if it's part of their paid job. If given a choice, they'll put off the boring parts and go do something they find fun and exciting.
It's probably part of the reason we have 1,453,807 different Linux distributions. Creating something new is fun! Doing grunt work to maintain a twenty-year-old standard library, on the other hand, is the definition of tedious.
Re: Resourcing (Score:1)
Really? How exactly would you have caught this specific attack with process? If anything it would make it harder to root out âoeuntrustedâ devs because the process cleared them and thus provides a level of trust. And once you have to go through âprocessâ(TM) to make changes, it will make any response slower or even impossible.
Re: Resourcing (Score:4, Insightful)
It has been mentioned that the maintainer was struggling to cope with processing requests, hence he appointed a helper as co-maintainer - some random guy on the internet he had never met in person with a random email address.
Had the project been managed by, say, Red Hat then any last minute pull request - particularly something that interfaces ssh with systemd I would expect to be better scrutinized. That's not to say that a hostile actor couldn't become an employee a big vendor but you'd have a consistent process across multiple libraries.
Re: (Score:1)
Most code is developed by some random guy on the Internet. Especially these days with all the AI code assistants, you can already see engineered responses to prompts and they are going in the direction of making SQL injection more viable through potential obscurity, not less.
Totally moot and amateurish (Score:2)
This seems to make an opening for closed source so (Score:1)