back to article 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 …

  1. b0llchit Silver badge

    More problems and no magic

    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.

  2. Mike 137 Silver badge

    "daily software updates"

    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.

  3. tiggity Silver badge

    always the same

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

  4. that one in the corner Silver badge

    So the problem is *really* just lack of professionalism?

    > 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

    1. TheMeerkat

      Re: So the problem is *really* just lack of professionalism?

      Nobody does, as you pull one library but it pulls multiple dependencies. Unfortunately most of the stuff at least in Java world are not just small independent libraries.

    2. Lil Endian Silver badge

      Re: So the problem is *really* just lack of professionalism?

      I totally agree with you That One.

      You're identifying proximal causality, correctly so. The ultimate causality, a huge part of what I see in the article is "We (a $corp) shed all of our talent, got in noobs to replace them, coz cheaper, and relied on them while we figured out how many yachts we could buy with our next bonuses."

  5. Charlie Clark Silver badge

    Haven't we read this article before? More problems than this

    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!

    1. HereIAmJH

      Re: Haven't we read this article before? More problems than this

      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.

  6. JassMan

    Perhaps this is a business opportunity for the OSF

    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

    1. Claptrap314 Silver badge

      Re: Perhaps this is a business opportunity for the OSF

      The fact that you mention using md5 as a cryptographic guarantee in 2023 means that you don't really understand the threat landscape. Please do more studying.

    2. Lil Endian Silver badge

      Re: Perhaps this is a business opportunity for the OSF

      Just pointing out that the article is not about FOSS, doesn't mention it, but OSS.

    3. Charlie Clark Silver badge

      Re: Perhaps this is a business opportunity for the OSF

      I don't want any self-appointed QUANGO doing anything in my name! And I certainly don't want something like the Musicians Union collecting and distributing money for my work!

  7. Anonymous Coward
    Anonymous Coward

    Audit Away......But...... there always a way to know that software has been compromised? depends on exactly how the compromise has been implemented!!


    (1) The Ken Thomson Hack:

    (2) The effort needed to identify item #1:

  8. ecofeco Silver badge

    Brand name software is safer?

    Is this satire? Parody? A bad joke? Brand name software is safer?

    LOL WUT?!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like