Should Companies Audit Their Software Stacks for Critical Open Source Dependencies? (technologyreview.com) 52
Thoughtworks is a technology consultancy/distributed agile software design company. The principle technologist in its CTO's office warns that managers of IT assets "need to keep up" with the changing economics of open source:
Early 2022 has brought with it an unusually high level of commotion in the open-source community, largely focused on the economics of who — and how we — should pay for "free" software. But this isn't just some geeky flame war. What's at stake is critical for vast swaths of the business world....
We know of many open-source enthusiasts who maintain their software personally while leading busy professional lives — the last thing they want is the responsibility of a service-level agreement because someone paid them for their creation. So, is this the end of the road for the open-source dream? Certainly, many of the open-source naysayers will view the recent upheavals as proof of a failed approach. They couldn't be more wrong. What we're seeing today is a direct result of the success of open-source software. That success means there isn't a one-size-fits-all description to define open-source software, nor one economic model for how it can succeed.
For internet giants like Facebook or Netflix, the popularity, or otherwise, of their respective JavaScript library and software tool — React and Chaos Monkey — is beside the point. For such companies, open-source releases are almost a matter of employer branding — a way to show off their engineering chops to potential employees. The likelihood of them altering licensing models to create new revenue streams is small enough that most enterprises need not lose sleep over it. Nonetheless, if these open-source tools form a critical part of your software stack or development process, you might want some form of contingency plan — you're likely to have very little sway over future developments, so understanding your risks helps.
For companies that have built platforms containing open-source software, the risks are more uncertain. This is in line with Thoughtworks' view that all businesses can benefit from a greater awareness of what software is running in their various systems. In such cases, we advise companies to consider the extent to which they're reliant on that piece of software: are there viable alternatives? In extreme circumstances, could you fork the code and maintain it internally?
Once you start looking at crucial parts of your software stack where you're reliant on hobbyists, your choices begin to dwindle. But if Log4J's case has taught us anything, it's this: auditing what goes into the software that runs your business puts you in a better place than being completely caught by surprise.
We know of many open-source enthusiasts who maintain their software personally while leading busy professional lives — the last thing they want is the responsibility of a service-level agreement because someone paid them for their creation. So, is this the end of the road for the open-source dream? Certainly, many of the open-source naysayers will view the recent upheavals as proof of a failed approach. They couldn't be more wrong. What we're seeing today is a direct result of the success of open-source software. That success means there isn't a one-size-fits-all description to define open-source software, nor one economic model for how it can succeed.
For internet giants like Facebook or Netflix, the popularity, or otherwise, of their respective JavaScript library and software tool — React and Chaos Monkey — is beside the point. For such companies, open-source releases are almost a matter of employer branding — a way to show off their engineering chops to potential employees. The likelihood of them altering licensing models to create new revenue streams is small enough that most enterprises need not lose sleep over it. Nonetheless, if these open-source tools form a critical part of your software stack or development process, you might want some form of contingency plan — you're likely to have very little sway over future developments, so understanding your risks helps.
For companies that have built platforms containing open-source software, the risks are more uncertain. This is in line with Thoughtworks' view that all businesses can benefit from a greater awareness of what software is running in their various systems. In such cases, we advise companies to consider the extent to which they're reliant on that piece of software: are there viable alternatives? In extreme circumstances, could you fork the code and maintain it internally?
Once you start looking at crucial parts of your software stack where you're reliant on hobbyists, your choices begin to dwindle. But if Log4J's case has taught us anything, it's this: auditing what goes into the software that runs your business puts you in a better place than being completely caught by surprise.
Yes. (Score:3)
Re:Yes. (Score:5, Insightful)
Re:Yes. (Score:4, Insightful)
And when they find issues [when auditing their software stacks for critical open source dependencies], they can submit patches. Viola! The brilliance of open source. Nothing about the dream is dead. This is how it is supposed to work. Collective improvement.
I don't think auditing their software stack means what you think it means. It doesn't mean a code review with the goal of detecting security vulnerabilities to patch. It is cataloguing a list of the open source applications and modules used. This is then used for two primary purposes: evaluate each module to determine if the company is comfortable with its use, and provide means to identify all applications which need to be modified / patched if a vulnerability is reported in that module (like with the Log4j incident).
The summary even mentions the two most common courses of action when reviewing these open source applications:
1. Find an alternative
2. Fork the application and maintain it internally
While assigning internal developers to help maintain an open source project does happen, that is not the most likely scenario when a company does this kind of audit. Any work companies are doing to contribute to open source for the most part will be done on their more critical modules, which they didn't need an audit to notice its use.
Re: Yes. (Score:2)
Re: Yes. (Score:5, Insightful)
Re: (Score:2)
It's incredibly difficult to do at times. Ie, most of the third party libraries incorporated have years of tweaks added to them. This means you can't just plop a newer copy down in its place. And the original people who did this are long gone, with not enough people remaining to devote 6 to 12 months to update them all. The source is scanned for updated libraries and "vulnerabilities" (some of which seem dubious), so if the company insists they be updated then we'll insist that they hire someone to do i
Re: (Score:1)
I'm under the strong opinion that they look and internally acknowledge. Since to do any more? Will trigger a mass contribution event downstream(feeders). All kinds of vectors. In other words many, many highjackings.
Re: (Score:2)
Dang, Every little application and repository at our company is being constantly hit with violations if there are known issues with dependencies.
Releases will get blocked in the pipelines if the scans show dependency issues.
Is this not a thing everywhere?
Re: (Score:3)
A lot of companies aren't even aware of it. Someone needs something to do X, finds an open-source tool or library somewhere that does the job, and it gets slotted temporarily into place with the intention of sorting it out later on.
Ten years later the company discovers it's got two dozen OSS libraries permanently wired into various places they didn't even know existed, no-one involved in the work is still at the company, and they don't know how to handle the situation.
This is why you hire MBAs (Score:2)
An MBA always knows what to do in situations like this. He develops a plan that will take 2 years to fully implement, and transitions to a new company in 18 months.
Sometimes the hardest part of programming is the realization that you're in this situation because your company did not do long term planning in the first place, and won't ever do long term planning. You can play code-janitor for a while, but eventually you'll have to move on to another company.
Re: (Score:2)
Sorry, but you're not allowed to contradict Betteridge. Please turn in your geek card at the door.
Re: Yes. (Score:2)
Re: (Score:2)
And not only this, these Companies should donate funds to the projects they steal^H^H^H^H^H download the software from.
For an example, look a OpenSSH, due to the number of large companies using OpenSSH, OpenBSD should have enough funds to develop they own chip fab.
Re: (Score:2)
Actually, they should have been doing it all along. Those not doing it need to fix their incompetence right away.
Re: (Score:2)
You should know where all the code in your applications comes from.
1. code your company wrote
2. code your company did not write
If your company did not write the code, there is a license for it and you must comply with its terms.
If it's commercial/closed source, you probably have to pay $$ and track it.
If it's open source, you usually need to publish its inclusion and its license.
Some open source may require you to distribute your code as well.
If you don't know what is in there, how do you:
comply wit
Re: (Score:1)
No (Score:2, Funny)
What a stupid question.
Re: (Score:2)
Re: (Score:2)
Ok, hope you don't mind the IT infra going down at 3AM on Friday night
More job security for me.
I'm a nerd. It's not like I have anything better to do on a Friday night.
Re: (Score:2)
Re: (Score:2)
I was being sarcastic. Whoosh not included.
Re: (Score:2)
Re: (Score:2)
I might have to revoke your nerd card.
Yes, and that's a stupid question. (Score:2)
https://www.youtube.com/watch?... [youtube.com]
How is this different from commercial software? (Score:5, Insightful)
This reads like FUD. Commercial software providers can and do change the terms of their licenses, too. With open source, the worst that can happen is they go closed and you won't get new features or updates until you find a good fork. If Oracle changes their terms on you, good luck.
Re:How is this different from commercial software? (Score:4, Interesting)
No, the worst that can happen is that they purposely push a version with a bug. Or an incompatibility. This is why you need to audit them- depend only on well known libraries (not random github projects). Depend on a specific version and update regularly, but not automatically. Audit the code of any library you use, to make sure it does what it says, the code is decent quality, and that it doesn't have malware or obvious security flaws in it.
You should do that with closed source as well. It's not about closed vs open, its about being smart in what you trust.
Re: How is this different from commercial software (Score:2)
And how exactly are we supposed to do the same thing with closed source code? Watch the system calls in the tracer? Or are we supposed to disassemble every closed source platform/app thats part of the chain and check for spurious ports being bound? Or hidden time bombs that might kick off ransomware? In hundreds of thousands of pages of op codes?
Re: (Score:2)
This reads like FUD. Commercial software providers can and do change the terms of their licenses, too. With open source, the worst that can happen is they go closed and you won't get new features or updates until you find a good fork. If Oracle changes their terms on you, good luck.
The licensing part is even mentioned in the summary as not the primary concern. It is maintenance of applications. I believe the latest round of open source concerns stem from the Log4j incident and when Marak brought down the "faker" and "colors" libraries which were used in over 20,000 other open source projects. Log4j reminded company leadership how pervasive (and easily unnoticed) open source libraries can be in their software stacks. And Marak's vandalism (of his own libraries) reminded them that there
Re: (Score:2)
As far as liability goes, the push would need to be very blatantly malicious to incur liability. Generally speaking, the plaintiff has to prove that either you knew the change would cause the damage (not just in a general sense, but that you knew about that specific case) or that you acted recklessly (you had good reason to know it'd inevitably cause damage to someone and you went ahead with it anyway). Even in the Marak case that might be a difficult bar to clear.
Commercial code is actually worse in that r
Re: (Score:2)
Generally speaking, the plaintiff has to prove that [...] you acted recklessly (you had good reason to know it'd inevitably cause damage to someone and you went ahead with it anyway). Even in the Marak case that might be a difficult bar to clear.
That shouldn't be too hard of a bar to clear for Marak (although I assume I don't understand the legal nuance). Even something as minor as the cost of a few developers patching code would be financial damage. Marak would have known with 100% certainty that someone somewhere was going to incur financial damages when over 20,000 open source projects had dependencies to his libraries.
Re: (Score:2)
Just patching things wouldn't count as damages in the legal sense. Marak has every legal right to make changes to his code that would result in people using that code to have to do work to accommodate those changes. That same thing makes it hard to clear the recklessness bar because breaking changes are always a possibility users are expected to be prepared for and his changes were obvious enough that even the simplest test would've detected them.
Re: (Score:2)
Re: (Score:2)
"No, the worst that can happen is that they purposely push a version with a bug. Or an incompatibility." ....
Or malware, or a worm, a virus, a ransomer, a
Re: (Score:2)
I guess you have never had any dealings with Sun or Oracle or Microsoft, or any other purveyor of hideous crap.
If your company depends on it, you SHOULD ALWAYS USE OPEN SOURCE IF IT WILL DO THE JOB. Anything else is like putting a noose over your own head. The closed source supplier will change the licencing agreement and/or multiply the price by 10 when you can least afford it. As for support - well, you can be on hold for several day
So, a payment means SLA? That's news to me. (Score:3)
Then the software creator wouldn't agree to a SLA for that payment. Pretty sure the latter doesn't require offering the former -- and the former isn't guaranteed by the latter. It's negotiated in the licensing and purchase agreement. To think otherwise requires a pretty big leap. At least *I* don't remember a SLA offered on my receipt for [insert name of purchased software] ... anyone get an SLA with your consumer purchase of, say, Windows?
Perform proper risk management. (Score:3)
What they need to be doing is investing in proper risk management. It doesn't matter who wrote your software, if the source code hasn't had a full security audit then you are running a big risk.
Furthermore, companies should be looking to modify monolithic software packages (*cough*Apache*cough*) to be vulnerability tolerant. This means that instead of having a monolithic software stack where a single vulnerability can result in a root level compromise, the software should be divided into a pipeline of programs/daemons running in total isolation. In addition to enabling easier testing/fuzzing, faster total throughput, and easier ability to scale, doing so allows you to restricts the possible communication routes to just the programs that it was given sockets for communication and the specific system calls each requires. What this means is if one of those isolated processes is compromised (e.g. bad parser) then it is much more difficult to exploit the flaw.
Open source shouldn't be considered a total solution for your company, it should be considered a very large head start toward having secure software for your business. Open source software is a diamond in the rough and not having ironclad security is a failing of the people who choose to use it.
Re: (Score:1)
Bugs can be just a situation you fix at the point of contact, until something else upstream, downstream, looking familiar, i don't know,...is addressed. If the off library is touched for the found bug in the first then ANOTHER bug is almost sure to be added if not an outright breakage. So monolithic tends to be a result of doing most things in one shop with limited time and personnel. Things get pulled closer and closer together until it all looks like one big bag of nuts, bolts and screws to the outside ob
You should audit ALL dependencies (Score:3)
You should do a risk evaluation on any upstream project. You should have a contingency plan for losing any upstream dependency, or for bugs in it, or for its development direction changing, or for its licensing changing, or whatever...
"Open source" is not a particularly useful category. Commercial projects can also be buggy and unreliable. ... and you should start by not having so much third party shit in the first place...
Re: (Score:2)
"Open source" is not a particularly useful category. Commercial projects can also be buggy and unreliable.
It is a VERY useful category.
When you rely on a proprietary software, your risk assessment must include the possibility that it disappears over night. Either the owners shut it down, or it goes bancrupt, or it cancels your contract or it sells out / is bought out - whatever. If and when it goes away, that's it, you're done. No more updates, not more fixes, no more nothing.
With an Open Source software, you always have the option of forking it and keeping it updated yourself, or hiring someone to do so. It wi
Let me guess! (Score:3)
so ... (Score:3)
Thoughtworks is a technology consultancy/distributed agile software design company.
bullshit company that sells bullshit also publishes free bullshit articles. how interesting. lets see:
yes, if you produce software you are responsible for each and every dependency you introduce, opensource or not.
no, this has nothing to do with opensource.
What's at stake is critical for vast swaths of the business world....
again, no, this is just bullshit. leave opensource alone. do your job and try to do something useful.
Open Source and Racketeering (Score:1)
SBOMs (Score:2)
This is a big reason why SBOMs (Software Bill of Materials) is going to become mandatory for all major firms. Get a piece of software, the SBOM that describes the software in the package. SBOMs are a mandatory part of EO 14028. We've already had a few customers ask for SBOMs and more will follow.
No. (Score:2)
They should make strategic decisions about their IT technologies and manage those dependencies.
But that off course would require management to meet the requirements of basic brain functions. That's the tricky part. If you're to dumb to be aware of the strategic significance of IT tech decisions and the commitment they demand and entail to add true value to a business, auditing external dependencies and any usefulness that night have in fringe cases is most definitely out of their league.
software development (Score:1)
dedicated resource hiring (Score:1)