Open source software has its perks, but supply chain risks can't be ignored Open source components play an increasingly central role in the software development scene, proving to be a boon in a time of continuous integration and deployment, DevOps, and daily software updates. In a report last year, silicon design automation outfit Synopsys found that 97 percent of codebases in 2021 contained open …
The supply-chain risk is about just as high or higher for proprietary software. The vendor gets "hacked" and you, the downstream, pay handsomely for a backdoored piece of software. The problem starts when you want to do some auditing, either you yourself or hired auditing. The proprietary system is much harder to look into. There is the open version much more accessible.
True, the centralisation of repositories and wideband of contributors is a substantial risk too. However, if you really want to be sure, then you always have been following all the libraries and applications you use more or very closely anyway.
When you blindly accept anything you have already lost. And here we are again... software is hard work and no magic method exists to make it cheap, fast and secure. You have to choose from the limited set and it always will be compromises in one or the other way.
The last bloody thing we need if we want to be reasonably secure. One of the most important contributions to robustness and resilience is good knowledge of the state of our systems so vulnerabilities can be allowed for and countermeasures applied (which is why we spend a lot of dosh on pen tests). If that state changes daily, we haven't a hope in hell of protecting said systems, all the more as "updates" can be as bug ridden as the software they're updating.
"effectively outsourced 90 percent of your development to people you don't know and can't trust.
.. which equally applies to proprietary software - at least with open source if an issue arises you can (if you have the abilities, fix the code yourself)
I have frequently used open source code - however never gone the auto pull stuff in approach.
Downloaded the open source components, audited for vulnerabilities and licence compliance, (plenty of tools to help be it commercial stuff such as Mend (AKA whitesource) through to open source free stuff) and tested them and added to source control.
That way you know what you are including - none of this randomly pulling the latest & greatest version from online & hoping for the best.
It has its drawbacks - when there is zero day you cannot just rely on your software picking up the latest & greatest fix when its available, instead you have to wait and incorporate it into your software (after testing it).
But, so long as your own software has ability to auto update (though ideally with user approval) then its not that much of an extra delay (just the time for you pull new version of open source component, audit and test it and update your source control repo).
Though the upside is that testing makes sure the fix does not break your software or have other issues (as with "emergency" bug fixes do sometimes see situations where initial "fix" is sub optimal and further fixes soon get rolled out)
Other drawback is, have to regularly do pull, audit and incorporate periodically anyway - be it for new versions for less critical bugs, improved performance etc. - but in "mature" open source components, you fortunately don't have to update that often as depends on your usage of that code and what has changed in the open source component: Scenarios where it's quite OK to run an older version without any issues tend to be common.
More hard work with this approach, but you're insulating yourselves from random code poisoning via the internet .
> But he added that developers and executives are often surprised by how much of their applications' code comes from OSS
Developers don't know what is in their s/w? For pity's sake, go and LOOK!
Executives don't know? You're letting your devs get away with not telling you? I thought you lot thrived on making everyone write reports[1]
> The trend toward using OSS packages isn't new. Developers have been doing it for a dozen years or more
A dozen or more? Try 30 or more! Or is he just reporting from when anyone admitted they were doing it (in which case, see above).
[1] TPS cover sheets notwithstanding
This post has been deleted by its author
As the maintainer of a popular open source library I'll admit to having recently made a release that caused some problems with downstream software because it contained breaking changes that were difficult to test.
Cue much wailing and gnashing of teeth but also a couple of useful pointers about the problem. TBH I've stopped giving a shit about reports from downstream software because they're no use to me, and the more sanctimonious the report the less of a shit I give. Sorry, for the breakages but workarounds were fairly straightforward (pin to the previous version), but at the end of the day: but, without a support contract, I'll get round to fixing it when I feel like it.
The same risk exists for commercial software, of course, but you've got even less of a chance of picking up problems in CI. As every Windows sysadmin knows!
I'll get round to fixing it when I feel like it.
And this is one of the risks that businesses should be accounting for. There is a difference between management deciding "we're going to standardize on open source", where they are looking at it's free licensing, and the reality that they should be adding in the cost of support contracts. As an open source maintainer your decisions don't affect your revenue. Because you aren't getting any now. Commercial software has to take reputation into account to make sure licensing continues. You, OTOH, earn the same whether you fix, ignore, or abandon.
Businesses need to get past the "Open Source is cheap or free", because quite often it is neither.
Since they are a trusted authority and protector of authors rights, they could offer a paid for service to firms wanting to use FOSS. They wouldn't need to certify that software is bug free (since virtually no software is), but they could certify that software is not malicious. To make it fair they could charge a fixed (small) percentage of the requesting company's turnover for the check. This would work well where many companies request a check on the same piece of software. Obs they would need a large database to save the MD5 sigs of all checked software to avoid duplication. They could even act as intermediaries if said company wanted improvements to a piece of software but the author wants to remain reasonably anonymous (eg they create FOSS in their spare time but their Windows based employer insists that ALL code produced is the property of that employer).
If they make a reasonable profit they could distribute a percentage of it back the original authors although I suspect in many cases this would cost more to make sure the value of the authorship was proportionate where several coders have contributed features to a piece of software. This would encourage better quality authorship.
Obviously a lot of details would need to worked out such as
can this be done under their charter,
how do they fund the startup of the service,
where they are going to get enough checkers,
do members of OSF get checks for free or just discounted
This post has been deleted by its author
.....is there always a way to know that software has been compromised? Well.....it depends on exactly how the compromise has been implemented!!
See:
(1) The Ken Thomson Hack: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html
(2) The effort needed to identify item #1: https://www.schneier.com/blog/archives/2006/01/countering_trus.html
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
