back to article Sneaky Python package security fixes help no one – except miscreants

Python security fixes often happen through "silent" code commits, without an associated Common Vulnerabilities and Exposures (CVE) identifier, according to a group of computer security researchers. That's not ideal, they say, because attackers love to exploit undisclosed vulnerabilities in unpatched systems and because …

  1. Charlie Clark Silver badge

    Who does the work?

    From the article I understand that the authors are proprosing yet another vulnerability database that authors are supposed to pay attention. So more work with no payoff. Seems like they don't understand open source development. Furthermore, it signs like it's based heavily on static code analyses and could, therefore, simply be part of any CI if it isn't already. And it's yet another Github-based project, meaning it will miss a lot of quite important open source libraries and all the proprietary ones.

    At least Google's OSS Fuzz actively tests for exploits.

    1. Version 1.0 Silver badge

      Re: Who does the work?

      A vulnerability database will help all Python users, even those who are writing malware ... this situation is universal not an anti-Python issue, for example while VirusTotal is a very good way to check your suspect email deliveries, if you are writing malware then it's a good way to test that your code is going to "work" if it isn't detected. Basically databases are not bad things, they just help everyone.

      1. Clausewitz4.0 Bronze badge
        Black Helicopters

        Re: Who does the work?

        "VirusTotal is a very good way to check ... writing malware then it's a good way to test that your code is going to "work" if it isn't detected

        No, VT is NOT a good place to check offensive code. There are other commercial solutions to check your offensive code against antivirus, that won't share your product with AV world+dog.

        Some will share with Intel agencies, but thats the price.

      2. Charlie Clark Silver badge

        Re: Who does the work?

        There are already countless scanners that list packages. The CVE approach is aimed at developers and I repeat: anything that makes means more work for the developer is unlikely to be done.

      3. Snake Silver badge

        Re: Who does the work?

        And not a single, sarcastic reference to "Security through Obscurity". Which would have been screamed out if this had occurred on any other project / system.

  2. heyrick Silver badge

    Perhaps if serious work went into not having breaking changes, people might be more willing to keep up to date. My personal experience is PHP that I don't think I've ever actually updated that something hasn't subsequently died. In one case because a bunch of minor functions (like string to number) appeared to be renamed...? When updating causes problems, people will be reluctant to upgrade and, well, that's when the cracks appear.

  3. Claptrap314 Silver badge

    Wrong end of the stick (for us, the profitable one for these folks)?

    It seems to me that the identified problem is that OS devs find opening a CVE to be cumbersome. The obvious fix would be to simplify opening a CVE, not attempting to generate a new solution that (surprise!) the "researchers" just happen to have ready.

    But CVE or know, I'm pretty certain that there is already a way (release notes / change log) to rather unambiguously mark a patch version as a security fix. Full points if the note also says how long the problem has been around.

    So this really looks like a solution chasing a problem.

    1. Michael Wojcik Silver badge

      Re: Wrong end of the stick (for us, the profitable one for these folks)?

      The CVE ID allocation process is ... infelicitous (at least it was back when I was a sub-CNA), but CVEs won't scale if we allocate CVE IDs for every security-relevant fix. CVE IDs is the wrong fix here. In practice, CVEs work well for significant vulnerabilities, and in particular for how they're actually most often used: to credit outside researchers and provide them with reputational compensation for notifying the product/component owner rather than selling or exploiting a vulnerability.

      Non-trivial software products often get a lot of small potential-vulnerability fixes as part of routine maintenance. Code inspection, refactoring, static or dynamic analysis, or testing catches the odd UAF or BOF here and there, and it more-or-less silently gets fixed metastatically within some other development effort. If developers have to allocate a CVE for each of those (or even one for each batch of them), we'll run through a lot more CVE identifiers, to the point where they're unusable, and increase the cost of making these small fixes.

  4. Anonymous Coward
    Anonymous Coward


    Does anyone doing serious programming use it?

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